Reference - Computer Networking: a Top Down Approach
P2P(Peer to Peer)
P2P 구조는 변동 IP주소를 갖는, 간헐적으로 연결된 host 쌍인 peer가 서로 직접 통신한다.
그 예로 file distribution, Streaming, VoIP가 있다.
서버가 N개의 피어에게 파일을 각각 전송해야 할 때, client-server 구조와 P2P의 분배 시간은 아래만큼 차이난다.
위 그래프를 통해 P2P 구조가 더 분배 시간이 적다는 것을 알 수 있고, 따라서 P2P 구조는 자가 확장성을 갖는다고 한다.
Torrent
특정 파일의 분배에 참여하는 모든 피어의 모임을 토렌트라 한다.
파일은 256kb의 chunk로 나뉘며, 토렌트에 참여하는 피어들은 서로에게서 같은 크기의 chunk를 다운한다.
처음 join하면 chunk가 없지만 시간이 지나면 점점 축적된다.
피어가 chunk를 다운할 때도 chunk를 다른 피어에게 upload한다. 피어가 전체 파일을 얻으면 토렌트를 떠나거나, 토렌트에 남아 다른 피어들로 chunk를 계속 upload할 수 있다.
Torrent 진행 과정
토렌트는 tracker라 부르는 Infrastructure node를 갖고 있고, 이를 통해 토렌트에 있는 피어를 추적할 수 있다.
새로운 피어를 앨리스라 하자.
앨리스가 토렌트에 가입하면, 트래커는 참여하고 있는 피어 집합에서 임의로 50개의 피어들의 IP 주소를 앨리스에게 보낸다. 앨리스는 이 피어들과 TCP 연결을 맺고, 이 피어들을 neighbors라 한다.
churn : 피어들 중 일부가 떠나면 다른 피어들이 앨리스와 TCP 연결을 시도하고, 따라서 neighbors는 시간에 따라 변한다.
Requesing chunks: rarest first - 임의의 시간에 앨리스는 청크의 일부를 갖고, 이웃들이 어느 청크를 가지는지 알게 될 것이다. 이를 바탕으로, 이떤 피어에게, 어느 청크를 먼저 요구할지 결정하게 된다. 이때, rarest first(가장 드문 것 먼저)로 결정한다. 갖고 있지 않은 청크 중, 이웃 중 가장 드문 청크를 결정하고 이를 먼저 요구한다. 이를 통해 가장 드문 청크가 빨리 재분배되어 청크 복사본 수가 균형을 맞춰간다.
Sending chunks: tit-for-tat - 어느 요청에 응답할지 결정할 때 앨리스가 가장 빠른 속도로 데이터를 제공하는 이웃에게 우선순위를 준다. 수신속도가 빠른 4개의 피어를 정하고, 이 피어들에게 청크를 보낸다. 이는 10초마다 계산하여 집합을 수정한다. 또한 40초마다 위 피어를 제외한 임의의 피어에게 청크를 보낸다. 이 피어를 optimistically unchoked라 한다.
이러한 5개의 피어 외의 모든 이웃 피어는 비활성화되어 어떤 청크도 교역하지 않는다.
Video Streaming and CDN(Contents Delivery Network)
비디오 트래픽은 Internet bandwidth의 major consumer다. 또한 높은 비트 전송률로 크게 두 Challenge가 있다.
Scalability와 heterogeneity가 그것이다.
Video streaming의 사용자는 10억명이 넘고, 각 사용자별 capabilities가 너무 다르다는 문제를 해결해야 하는데,
그 해결책이 distributed, application-level infrastructure다.
비디오는 일반적으로 초당 24개의 image로 구성되는데, 이때 압축(encoding)을 통해 bits를 감소시킨다.
HTTP 스트리밍은 트래픽이 허용되는 대로 HTTP 응답 메시지 내에 비디오 파일을 전송하여, 어플리케이션 버퍼에 전송된 바이트가 저장되고 버퍼의 바이트 수가 정해진 임계값을 초과하면 재생하는 방식이다. 버퍼에서 주기적으로 비디오 프레임을 가져와 프레임을 압축 해제한 다음 사용자의 화면에 표시한다.
문제는 가용 대역폭이 달라도 똑같이 인코딩된 비디오를 전송받는다는 것이고, 이를 해결하기 위해 DASH가 개발되었다.
DASH(Dynamic, Adaptive Streaming over HTTP)
DASH에서 비디오는 여러가지 버전으로 인코딩되며, 각 버전은 비트율과 품질 수준이 다르다. 클라이언트는 동적으로 서로 다른 버전의 비디오를 몇초 분량의 비디오 chunk로 요청한다. 각 비디오 버전은 HTTP 서버에 서로 다른 URL로 저장되며, HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 manifest 파일을 갖고 있다. 클라이언트는 manifest 파일을 제공받고, 매번 원하는 버전의 비디오 조각 단위를 선택하여 HTTP GET 요청 메시지에 URL과 byte-range를 지정하여 요청한다.
CDN
수천명의 사용자에게 동시에 비디오를 제공하려면?
=> 단일 거대 데이터 센터를 구축하고 사용자에게 직접 전송한다?
문제점 => 1. 한번의 실패로 전체 서비스가 중단된다. 2. 과도한 네트워크 트래픽
3. 먼 거리의 클라이언트는 더 깊은 병목현상 4. 동일한 인기있는 비디오에 대한 반복 비용
이러한 문제를 해결하기 위해 비디오 스트리밍 회사가 CDN을 사용한다. CDN은 다수의 지점에 분산된 서버들을 운영해 비디오 등의 컨텐츠 복사본을 분산 서버에 저장하고, 사용자를 최적의 CDN 서버로 연결되게 하는 방식이다.
CDN은 일반적으로 서버 위치에 대해 두가지 철학 중 하나를 채용한다.
- Enter Deep : 최대한 서버를 사용자 근처에 위치시켜 링크 및 라우터의 횟수를 줄려 delay와 throughput을 개선.
- Bring Home : 좀 더 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축하여 ISP를 Home으로 가져오는 개념.
Enter deep보다 delay와 throughput이 안좋겠지만 유지 보수 및 비용적 이익이 있다.
CDN은 클러스터에 모든 복사본을 유지하지는 않으며, 실제로 사용자의 요청이 오면 중앙 서버나 다른 클러스터로부터 전송받아 사용자에게 서비스하는 동시에 복사본을 만드는 pull 방식을 사용한다. 저장공간이 가득 차게 되면 자주 사용하지 않는 비디오 데이터는 삭제된다.
CDN 동작 및 컨텐츠 접근
1. 사용자가 URL을 지정하여 비디오를 요청하면
2. CDN이 그 요청을 가로채 클라이언트에게 가장 적당한 CDN 클러스터를 선택한다
=> 이때 클러스터 선택 정책으로 Geographically Closest(a closer look)을 사용한다. 얻은 IP 주소를 지리적으로 매핑해 가까운 클러스터를 선택하는 방식이다. 요청을 가로챌 때 CDN은 DNS를 활용하는데, 이를 DNS redirection이라 한다.
3. 클라이언트의 요청을 해당 클러스터의 서버로 연결한다.
