2.5 P2P 파일 분배

P2P구조는 항상 켜져 있는 기반 구조 서버에 최소한으로 의존한다.
간헐적으로 연결되는 호스트 쌍(피어)들이 서로 직접 통신한다.
피어는 서비스 제공자가 소유하는 것이 아니라 사용자가 제어하는 데스크톱과 랩톱이 소유한다.

클라이언트 - 서버 관계에서는 각각의 파일 본사본을 각 피어들에게 보내야 해서 큰 부하를 주고 많은 양의 서버 대역폭을 소비한다.
P2P 파일 분배에서 각 피어는 수신한 파일의 임의의 부분을 다른 피어들에게 재분배 할 수 있어 서버의 분배 프로세스를 돕는다.

• bittorrent
  가장 인기있는 p2p 분배 프로토콜
  특정 파일의 분배에 참여하는 모든 피어들의 모임을 토렌트라고 한다.
  토렌트에 참여하는 피어들은 서로에게서 같은 크기의 청크를 다운로드한다.
  청크의 일반적 크기는 256kb

피어가 처음 토렌트에 접속하면 청크가 없지만 점점 많은 청크를 쌓을 수 있다.
피어가 청크를 다운로드 할 때 피어는 청크를 다른 피어들에게 업로드한다.

토렌트는 트랙커라고 부르는 기반구조 노드를 갖고 있다
한 피어가 토렌트에 가입 할 때 트랙커에 자신을 등록하고 주기적으로 자신이 아직 토렌트에 있음을 알린다.
이러한 방식으로 트랙커는 토렌트에 참여하는 피어를 추적한다.

피어에 접속했을 때 아무것도 없으면 파일을 요청하고
피어들의 리스트를 서버에서 받아온다.

청크를 요청하면 이웃 가운데 가장 드문 청크를 먼저 요구하게 되어 더 빨리 재분배 될 수 있다.
또, 가장 빠른 데이터를 제공하는 이웃이 우선순위를 가지게 된다.
속도가 가장 빠른 4개의 피어들을 결정하고 매 10초마다 속도를 재계산하고 피어 집합을 수정한다.
이들 4개의 피어를 활성화되었다고 한다.
30초마다 임의의 피어를 선택하여 청크를 보내는데 이를 낙관적으로 활성화 되었다 한다.

이러한 교역을 위한 보상 방식을 TFT(tit-for-tat)이라 한다.

P2P 구조의 확장성

한 파일을 고정 된 수의 피어들에게 분배하는 양적 모델

서버와 피어들은 접속 링크로 인터넷에 연결되어 있다.

2.6 비디오 스트리밍과 컨텐츠 분배 네트워크

이 절에서는 오늘날 인터넷에서 널리 사용되는 비디오 스트리밍 서비스가 어떻게 구현되는지에 대한 개요를 제공한다.

2.6.1 인터넷 비디오

유튜브, 네ㅅ플릭스, 유쿠, 아마존 등.. 많은 비디오 스트리밍 회사가 존재한다.

• 비디오
  이미지의 연속으로서 일반적으로 초당 24개 또는 30개의 이미지로 일정한 속도로 표시되는 것.
  압축되지 않는 디지털 인코딩된 이미지는 픽셀 단위로 구성되며 각 픽셀은 휘도와 색상을 나타내는 여러 비트들로 인코딩된다.
  비디오의 중요한 특징은 압축될 수 있다는 것
  비디오의 품질과 비트 전송률은 서로 반비례한다.(비디오 품질이 높을 수록 비트 전송률이 낮아짐)
  물론! 비트 전송률이 높을 수록 이미지 품질이 좋아진다.

2.6.2 HTTP 스트리밍 및 대쉬

HTTP 스트리밍에서 비디오는 HTTP 서버 내의 특정 URL을 갖는 일반적인 파일로 저장된다.
사용자가 비디오 시청을 원하면 클라이언트는 서버에게 TCP 연결을 설립하고 해당 URL에 대한 HTTP GET요청을 발생시킨다.
그러면 서버가 기본 네트워크 프로토콜 및 트래픽 조건이 허용되는 대로 HTTP 응답 메시지 내에서 비디오 파일을 전송한다.
클라이언트 쪽에서는 애플리케이션 버퍼에 전송된 바이트가 저장된다.
이 버퍼의 바이트 수가 미리 정해진 임계값을 초과하면 클라이언트 애플리케이션이 재생을 시작한다.

DASH

그러나!! 큰 문제점..
모든 사용자들이 가용 대역폭이 다른데 똑같은 인코딩 비디오를 받고 있다!!!..
사용자마다 시간과 성능의 차이가 생긴다
이를 해결하기 위해 HTTP 기반 프로토콜 DASH(Dynamic Adaptive Streaming over HTTP) 가 개발되었다.
DASH에서는 여러 비디오가 서로 다른 버전으로 인코딩 ㄷ히며 각 버전은 서로 다른 비트율과 품질 수준을 갖는다.
클라이언트는 동적으로 서로 다른 버전의 비디오를 몇 초 분량의 길이를 가지는 비디오 조각(청크) 단위로 요청한다.
가용 대역폭이 충분하면 높은 비트율의 비디오 버전을 요청하고 가용 대역폭이 적으면 낮은 비트율의 비디오 버전을 요청한다.

DASH 를 사용할 때 각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다.
HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 매니페스트 파일을 가진다.

2.6.3 콘텐츠 분배 네트워크(CDN)

Content distribution network

원래는 단일한 데이터 센터를 구축하고 모든 비디오 자료를 저장 후 전 세계에 보냈다.
그러나 이 방식은..
1. 먼 지점에 있으면 상당히 속도가 느려진다.
2. 인기 있는 비디오는 같은 통신 링크를 통해 여러 번 반복 전송된다. 이는 대역폭의 낭비!!
3. 한번 장애가 일어나면 모든게 터진다 ! ! !

그래서 다들 CDN을 쓴다..

CDN

CDN은 다수의 지점에 분산된 서버들을 운영하며 비디오 및 다른 형태의 웹 컨텐츠 데이터의 복사본을 이들 분산 서버에 저장한다.
사용자는 최선의 서비스를 제공할 수 있는 CDN과 연결 된다.

CDN의 철학
1. Enter Deep
서버 클러스터를 세계 곳곳의 접속 네트워크에 구축함으로써 ISP의 접속 네트워크로 깊숙이 들어가는 것.
서버를 최대한 사용자 가까이 위치시켜 사용자와 CDN 서버 사이의 링크 및 라우터 수를 줄인다!!
문제는 너무 분산되어서 유지보수가 힘들다..
2. Bring Home
핵심 지점에 큰 규모의 서버 클러스터를 구축하여 ISP를 Hom으로 가져온다.
유지보수는 좋지만 사용자가 불편해진다..

서버 클러스터 위치가 정해지면 CDN은 콘텐츠의 복사본을 이들 클러스터에 저장한다. 각 지역마다 인기 비디오가 다르기 때문에 CDN은 각 클러스터마다 모든 비디오의 복사본을 전부 유지할 필요는 없다.
CDN은 PULL방식을 사용한다.
어떤 사용자가 지역 클러스터에 없는 비디오를 요청하면 해당 비디오를 중앙 서버나 다른 클러스터로부터 전송 받아 사용자에게 서비스하는 동시에 복사본을 만들어 저장한다.

CDN 동작

1. 사용자가 NetCinema에 방문한다
2. 사용자가 영상 링크를 클릭하면 사용자의 호스트는 해당 영상에 대한 DNS Query를 보낸다.
3. 사용자의 지역 DNS 서버는 호스트 이름의 video문자열을 감지하고 해당 쿼리를 넷시네마의 책임 DNS서버로 전달한다.
넷시네마 책임 서버는 해당 DNS 쿼리를 KingCDN 으로 연결하기 위해 IP주소 대신에 KINGCDN의 호스트 이름을 LDNS에게 알려준다.
4. 사용자의 LDNS 는 KINGCDN의 호스트에 대한 두번 째 쿼리를 보내고 이는 kingcdn의 dns에 의해 KingCDN의 사설 DNS 구조로 들어가게 된다.
5. LDNS 는 콘텐츠를 제공할 CDN 서버의 IP주소를 사용자 호스트에게 알려준다.
6. 클라이언트는 IP주소를 얻고나면 해당 IP주소로 직접 TCP연결을 설정하고 비디오에 대한 HTTP Get 요청을 전송한다.

클러스터 선택 정책

지리적으로 가장 가까운 클러스터 할당
그러나 이 방법은 인터넷의 경로의 지연이나 가용 대역폭 변화는 무시하고 항상 같은 클러스터를 할당하게된다.
현재는 주기적으로 클러스터와 클라이언트 간의 지연 및 손실 성능에 대한 실시간 측정을 수행한다.

2.6.4 사례

• 넷플릭스
• 유튜브
• kankan