2.5 P2P applications

pure P2P architecture

• P2P는 always-on 서버가 없다.
  -> 서버 사용하는 P2P도 있긴 한데 서버의 역할이 서보와 클라이언트 사이의 통신이 아닌 peer들을 관리하기 위한 서버이다.
• 임의의 end system(클라이언트들, peer들) 끼리 직접적으로 소통한다.
• peer들은 항상 켜져있지 않고, IP주소가 고정되어 있지 않다.
• bitTorrent, KanKan, Skype 등

File distributuion : client-server vs P2P

F 사이즈의 파일을 한 서버로 부터 N개의 peer들에게 distribute 하는데 얼마나 시간이 걸릴까?
-> peer의 업로드/다운로드 용량은 정해져 있다.

• us : 서버의 파일을 네트워크로 업로드 하는데 걸리는 전송 속도(업로드 속도)
• di : 네트워크에서 클라이언트로 파일을 보내는 속도(다운로드 속도)

-> 전송속도가 더 낮은 쪽(bottleneck이 걸리는 쪽)이 파일을 다운받는 전송 속도를 결정한다.

File distribution time : client-server

• 서버 전송 시간 : N개의 파일 복사본들을 순차적으로 send(upload) 해야 한다.
  -> 한 카피당 서버에서 네트워크로 업로드 하는데 걸리는 시간 : F/us
  -> N 개의 카피들을 보내기 위해서는 N번 업로드 해야한다 : NF/us
• 클라이언트 다운받는 시간
  -> 클라이언트들이 동시에 다운받으려 할 때 가장 다운 속도가 느린 곳에서 bottleneck이 발생하기 때문에 다운로드 속도가 가장 느린 곳이 전체 속도를 결정한다. : F/dmin
• 전체시간
  -> 파일 업로드 시간과 파일 다운로드 시간 중 오래 걸리는 시간이 파일을 distribute 할 때 걸리는 시간
  
  -> 클라이언트의 수가 늘어나면 N이 증가한다. -> N에 따라 linear 하게 속도 증가

File distribution time : P2P

• 서버 전송 시간
  -> 처음에는 서버에만 파일이 존재하고 네트워크 상에는 파일이 없다.(파일을 가지고 있는 서버일 뿐).
  -> 클라이언트들이 파일을 요청하는 상황에서 일단 한번은 서버에서 업로드를 해야 한다.
  -> F/us
• 클라이언트 다운받는 시간
  -> 모든 클라이언트들이 다운받아야 하므로 가장 다운속도가 느린곳에 의해 결정
  -> F/dmin
• 한번 파일을 다운로드 한 후로는 클라이언트들의 업로드 bandwidth를 사용 가능하다.
  -> 클라이언트가 서버 역할을 하는 것.
  -> 한 파일을 다 다운로드 한 후 전달이 가능한 것이 아니라 어느 정도(chunk) 다운로드 하면 그때부터는 다운받은 부분들을 전달 할 수 있게 된다.
  -> 즉 원래 서버의 업로드 속도 + 클라이언트들의 업로드 속도의 합 = 전체 업로드 속도
  -> 이 때 N개의 클라이언트가 모두 파일을 다운받아야 하므로 총 필요한 비트 수는 NF 비트
  -> 이 때 걸리는 시간 = NF/(서버 업로드 속도 + 클라이언트들의 업로드 속도의 합)
• 전체 시간
  -> (한 파일에 대한)서버 업로드 시간, 클라이언트 다운받는 시간, 전체 파일에 대한 업로드 시간 중 가장 큰 시간이 파일을 distribute 하는데 걸리는 시간이다.
  
  -> 클라이언트가 늘어나면 N이 커지지만, 그만큼 업로드 해주는 클라이언트 역시 많아지므로 linear 하게 증가가 아닌 낮은 속도로 증가한다.

client-server vs P2P : example

• 클라이언트가 많을수록 P2P가 효율적이다.
• 단점
  -> 안정성 문제 : 서버는 24시간 열려 있기 때문에 시간이 좀 걸리더라도 안정적이지만, P2P의 경우 파일을 제공하는 클라이언트들이 꺼져 있으면 파일을 다운받지 못한다.

P2P file distribution : BitTorrent

• 파일이 256kb의 청크로 나누어 진다.(크기는 설정에 따라 달라질 수 있음)
• 토렌트(torrent) : 파일을 주고받는 peer들
  -> 토렌트의 peer들이 파일 chunk들을 주고받는다.
• 트래커(tracker) : 일종의 서버 역할 - 어떤 피어들이 파일 distribution에 참여하고 있는지 트래킹(추적) 한다.
  -> 트래커를 통해 peer들의 리스트를 받고, 토렌트의 peer들과 파일을 주고 받는다.
• 토렌트에 peer들이 참여하는 과정
  -> 처음에는 chunk가 없다. 하지만 시간이 지나면서 다른 peer들로부터 축적된다.
  -> 트래커에 등록 되고 주변 peer들(neighbor)과 커넥션을 맺어서 파일을 다운로드 한다.
• 다운로드 받는 동안에도 chunk들을 다른 Peer들에게 업로드 해 줄 수 있다.
• 파일을 다운로드 하는 중에 다운받는 peer를 바꿀 수도 있다.
  -> churn : 다이나믹하게 peer가 바뀌는것.
• peer가 파일 전체를 갖게 되면 떠나거나(이기적, 받을거 받고 안준다는 마인드) 토렌트에 남아(남아서 파일 제공)있을 수 있다.

BitTorrent : requesting, sending file chunks

• chunk 요청
  -> peer들이 가지고 있는 chunk들이 다를 수 있다.
  -> 주기적으로 각각의 peer들에게 어떤 chunk를 가지고 있는지 물어본다.(chunk list 요청)
  -> 요청 방식 : rarest first -> 희귀한 chunk 부터 먼저 요청한다. (가지고 있는 peer가 적은 chunk 먼저 요청, peer들이 떠날수도 있으니까)
• chunk 보내기(tit-for-tat)
  -> 요청 받으면 보내줘야 한다.(우선순위를 갖고 보내줌)
  -> 자기한테 가장 높은 속도로 chunk를 보내주고 있는 peer들(많은 데이터를 주는 peer들)이 우선순위가 높다.
  -> 그 중 상위 네명의 peer에게 보내준다.
  -> 다른 peer들은 자신으로 부터 데이터를 못받는다.(choked 상태)
  -> 10초 마다 상위 네 peer를 갱신한다.
  -> 30초 마다 랜덤으로 peer를 고르고 chunk를 보내준다.(ooptimistically unchoked - 상위 네명 말고 다른 애를 랜덤으로 골라줌)
  -> 새롭게 선택된 peer가 상위 네 peer에 들어올 수도 있다.
  -> 자신도 랜덤으로 받아서 누군가의 상위 네 peer가 될 수도 있다.

BitTorrent : tit-for-tat

1. Alice와 Bob은 서로에게 탑 4가 아니다.
2. Alice가 Bob을 optimistically unchoke한다.
3. Bob에게 chunk를 보내준다.
4. Alice가 보내주는 속도가 생각보다 빨라서 Bob의 탑 4가 된다.
5. Bob은 이것에 대해 보답한다.(Alice에게 chunk를 보내주게 됨)
6. 근데 이것도 생각보다 빨라서 Bob 역시 Alice의 탑 4가 된다.

-> 계속해서 더 나은 파트너를 고르게 된다.
-> 파일을 더 빠르게 전송받도록 노력한다.

2.6 video streaming and content distribution networks

Video Streaming and CDNs: context

• Internet bandwidth의 주 소비자는 video traffic이다.
  -> 넷플릭스, 유튜브는 각각 ISP 트래픽의 37%, 16% 를 사용함
• 문제점 : 양이 매우 많아서 한 서버로는 불가능하다
• 문제점 : heterogeneity -> 사용자들의 밴드위드가 다 다르다.
• 해결책 : 분산됨, 애플리케이션 레벨에서의 조직화

multimedia: video

• 비디오 : 일정한 비율로 보여지는 이미지들의 sequence
• 디지털 이미지 : 픽셀 array
  -> 각각의 픽셀들은 비트로 표현된다.
• 코딩(coding) : redundancy(중복)을 사용해 이미지의 비트수를 줄인다.
  -> spatial : 한 이미지 내의 같은(비슷한) 부분에 대한 정보를 줄임(압축)
  -> temporal : 이전 이미지와 달라지지 않은 부분을 줄임(압축)
  
• CBR(constant bit rate) : 처음부터 끝까지 예를들어 1mbps의 rate로 인코딩 한다.(비트 레이트 일관되게 유지)
• VBR(variable bit rate) : 하나의 동영상 내에서도 시간에 따라 어떤 파트는 비트 레이트가 높게 어떤 파트는 비트 레이트가 낮게 한다.(다이나믹한 씬에서는 비트레이트 높임)

Streaming stored video

-> 비디오 스트리밍 상황

streaming multimedia : DASH

• DASH : Dynamic, Adaptive, Streaming over HTTP
  -> 멀티미디어 스트리밍을 http 위에서 함
• 서버
  -> 비디오 파일을 여러 chunk로 나눈다.
  -> 각각의 chunk들을 저장하고 다른 rate로 인코딩한다.(높은 rate면 화질이 좋음 등)
  -> manifest file : 관리하기 위한 파일 -> 다른 chunk들을 URL에 저장하여 제공(어느 시간 부터 어느 시간 까지는 특정 url에 chunk 저장)
• 클라이언트
  -> 주기적으로 bandwidth를 측정한다. (클라이언트는 manifest를 이용해 서버에 특정 chunk를 달라고 요청하는데, chunk마다 rate가 다르기 때문에 전송속도가 좋으면 화질 좋은것을 요청하고, 안좋으면 화질 낮은것을 요청한다. 이것을 하기 위해 bandwidth를 주기적으로 측정한다.)
  -> 상황에 따라 화질 바꾸면서 chunk들을 서버에 요청(= DASH)
• intelligence at client
  -> 클라이언트가 언제 어떤 청크를 요청할지, 요청할 때 어떤 화질의 청크를 요청할지, 요청하는 청크가 여러 군데 분산되어 있을 때 어떤 서버로 부터 다운 받을 것인지 판단한다.
  -> 클라이언트가 세가지 모두 판단

Content distribution networks

문제점 : 수많은 시청자가 있으면 어떻게 서비스 할 것인가?

해결책
1. 서버 하나를 엄청 크게
-> 서버 터지면 문제.(single point of failure)
-> 트래픽이 커지면 congestion 발생.
-> 서버가 멀리 있으면 딜레이 걸림.
-> 한 영화를 여러 사람이 다운받는 상황.
-> scalability 적으로 안좋음
2. 서버를 분산시킴(CDN)
-> enter deep : 엑세스 망 안쪽에 CDN 서버를 놓음(더 유저에 가깝게)
-> bring home : 엑세스 망 바깥족에 CDN서버를 놓음(개수는 적고 딜레이는 크지만 더 넓은 지역 커버 가능)

content distribution networks(CDNs)
CDN : 컨텐츼의 복사본들을 CDN 노드들에 저장한다.

예를 들어 넷플릭스가 매드맨이라는 영화를 여러 군데 분산 시켜 저장한다.
-> 구독자가 넷플릭스서버에 접속해서 영화 어딨는지 물어보면 넷플릭스에서 manifest 파일을 보내준다.
-> Manifest 파일은 각각의 chunk가 어떤 url에 있는지 list를 준다.
-> 이 파일을 보고 클라이언트가 url로 요청하여 chunk 받는다.
-> Near by copy(가까운데서 받아오는거) 선호하지만 network path가 congested의 경우 다른데서 받아오기도 한다.

CDN content access : a closer look

-> netcinema.com은 어떤 영화가 있는지 보여준다.(클라이언트는 여기에 비디오 요청)
-> CDN 전문 회사로 부터 서비스를 받을 수 있다.(실제 비디오는 kingCDN.com의 CDN에 저장되어 있음, 실제 스트리밍 하는 사이트)

동작과정
1. 사용자가 netcinema.com에서 동영상을 고름 -> 동영상의 url을 얻음
2. 이 url을 가져오기 위해 local dns서버에 url의 ip주소가 뭔지 물어봄
3. local dns 서버가 netcinema의 dns서버를 알려줌 -> netcinema는 어떤 url을 반환해 줘서 이쪽으로 가라고 알려줌
4. 그 url을 찾기 위해 kingCDN의 DNS 서버에 어디있는지 물어봄 -> 해당 url의 컨텐츠가 있는 서버를 반환해서 알려줌
5. 알게된 서버에서 http를 통해 스트리밍함

정리하자면 웹사이트 따로, 스트리밍하는 서버가 따로 있어서 Dns 서버를 이용하여 다른쪽 url을 돌려 줌으로써 거기로 가서 사용자가 거기의 서비스를 활용할 수 있도록 해 준다.

예시 Netflix

넷플릭스 - 계정관리, 영화관리
아마존 클라우드 - 실제 데이터 스트리밍
-> 넷플릭스에 로그인 하고
-> 아마존 클라우드에서 영화 고르고 manifest 파일을 받고
-> 아마존 클라우드의 CDN 서버로 가서
-> 그쪽으로 부터 스트리밍을 받는다.

정리
유저가 많으면 한 서버로 부터 데이터 서비스가 불가능하니까 여러 군데 서비스를 분산 시켜 놓고 사용자가 매니패스트 파일을 통해 그 url에서 데이터를 다운받을 수 있도록 한다.

출처 및 참고
Computer Networking A Top-Down Approach 7-th Edition / Kurose, Ross / Pearson
서강대학교 기초컴퓨터네트워크 강의자료