P2P, CDN

P2P Architencture

P2P 아키텍쳐에서 항상 켜져있는 서버는 없다. 

End system 끼리 직접적인 연결을 한다

Peer들 끼리는 일시적으로 연결되어 있으며 동적으로 할당된 IP 주소가 바뀔 수 있다.

ex) BitTorrent, Skype

 

File Distribution: C-S vs P2P

Client-Server

C-S 구조에서 서버는 순차적으로 N개의 파일을 보내야 한다.

• 하나의 파일을 보내는데 걸리는 시간: F/Us
• 총 N(F/Us) 의 시간

각 클라이언트는 각자 파일을 다운로드 해야 한다

• dmin = 클라이언트 최소 다운로드 속도
• 클라이언트 최소 다운로드 시간 = F/dmin

파일 F를 N개의 클라이언트에게 보내는데 걸리는 시간 c-s 구조

 

P2P

P2P 구조에서 서버는 최소 하나의 파일을 올려야 한다

• 파일 하나 올리는데 걸리는 시간 = F/Us

각 클라이언트는 각자 파일을 다운로드 해야 한다

• 클라이언트 최소 다운로드 시간 = F/dmin
• 클라이언트가 파일의 모든 조각을 다운로드하면, 이들 조각을 모아서 전체 파일을 구성할 수 있다
• 예를 들어, P2P 네트워크에서 파일의 크기가 100MB이고, 클라이언트 수가 10명인 경우, 각각의 클라이언트는 파일의 10MB씩의 조각을 가지고 있다. 이 경우, 모든 클라이언트가 파일 전체를 보유하기 위해서는 모든 조각들을 합산한 총 100MB를 다운로드해야 한다.

파일 F를 N개의 클라이언트에게 보내는데 걸리는 시간 p2p 구조

 

BitTorrent

Requesting Chunk

• 각 다른 peer가 파일의 각 다른 부분을 보유하고 있다
• 요청이 들어왔을때, 각 peer에게 chunk 요청
• 요청시, 가장 희귀한 chunk 부터 요청한다

Sending Chunk

• Chunk를 보내는 4명을 제외한 나머지는 choke 시킨다. (가장 빨리 보낼 수 있는 peer에게)
• 30초마다 무작위로 다른 peer 선택/ 전송

 

CDN: Content Distribution Network

현 인터넷 대역폭은 대부분이 영상트레픽이다. 

그렇다면 이렇게 사용량이 많은 유튜브, 넷플릭스 등은 어떻게 그렇게 많은 사용자들을 수용할까?

각 사용자마다 조건이 다르다

• wired vs mobile
• bandwidth etc..

해결책: 분산된 애플리케이션 레벨 구조

 

Multimedia: Video

• 비디오는 연속된 이미지를 일정한 속도로 연속적으로 보여주는 것이다.
• 두 연속된 이미지 사이에 일치하는 부분은 두고 차이가 있는 부분만 변경시켜 효율성을 높인다
• CBR(Constant Bit Rate): 인코딩 속도가 일정하다
• VBR(Variable Bit Rate): 인코딩 속도가 얼마만큼의 변경이 필요한지에 따라 변화된다

Multimedia: DASH

• Dynamic, Adaptive Streaming over HTTP
• Server
  • 비디오 파일을 여러개의 chunk로 나눈다
  • 각 chunk들은 다른 속도로 인코딩 된다
  • Manifest File: 각 chunk에 대한 URL 제공
• Client
  • 주기적으로 서버-클라이언트 대역폭을 측정한다
  • Manifest를 참조하여 한번에 한 chunk씩 요청, 최대 코딩 속도를 고려하여 요청

Progressive

DASH

Content Distribution Network

문제: 동시에 수많은 클라이언트들에게 어떻게 stream 할 수 있을까?

Option1: 하나의 큰 서버

• 서버에 문제가 생기면 전체가 down
• Network Congestion
• 멀리있는 클라이언트는 불이익을 받는다
• 즉... 문제점이 많다

Option2: 비디오의 복사본은 여러군데에 복사해서 저장해 둔다

• 여러 CDN node에 여러 복사본 저장
• 클라이언트가 영상 요청시 가까운 CDN 노드로 연결
• 만약 congestion 발생시, 다른 CDN 노드로 연결 가능

CDN content access