[컴퓨터네트워크] CH2. Application Layer (#4)

P2P

1. File distribution time

한 서버에서 N개의 peer로 size F인 파일을 보내는데 얼마나 걸릴까??

(Peer의 upload/download capacity는 한정되어 있다)

1. Client-Server

1. Server transmission : 파일을 N개로 복사해서 순차적으로 보내야 함
   • 복사본 하나 보내는데 걸리는 시간 = F/us (전체용량 / 시간당 upload 할 수 있는 capacity)
   • N개 보내는데 걸리는 시간 = NF/us
2. Client : 각 client는 파일을 다운로드 받아야 함
   • d_min = download rate의 최솟값 (시간 당 받을 수 있는 파일 (가장 capacity가 작은 것 기준))
   • client가 다운로드 하는 시간의 최솟값 = F/d_min

즉 client-server approach를 사용해서 F 만큼의 파일을 N clients에게 분배하는데 걸리는 total delay

D_c-s >= max {NF/us, F/d_min}

2. P2P

1. Server transmission : 최소한 하나의 copy를 upload 해야 함
   • 한 개의 copy 보내는데 걸리는 시간 = F/us
2. Client : 각 client가 copy본을 다운로드 해야함
   • Min client download time = F/d_min
3. Clients : 종합해서 총 NF bits를 다운로드 해야함
   • 최대 업로드 rate (최대 다운로드 속도를 제한했을 때) = us+∑ui

즉, server-client는 N개의 파일을 올릴 때, 서버가 순차적으로(capacity만큼씩) 다 올려야하고, P2P에서는 peers들이 1개 이상씩 올려서 N개가 되면 되니까, P2P의 file distribution time이 더 짧다.

2. A case study : BitTorrent

P2P File Distribution : BitTorrent

• 파일을 256kb의 덩어리로 쪼갠다
• torrent에 있는 peer들이 file 덩어리를 보내고 받는다.
• Tracker : torrent에 참여하는 peer들을 추적한다
• Torrent : 파일 덩어리를 교환하는 peer들의 그룹
• torrent에 참여한 peer
  • 처음엔 아무것도 없지만 점차 시간이 지날 수록 다른 peers의 chunk가 축적된다
  • tracker에 등록해서 peer의 목록을 가져오고, peers("neighbors")의 하위 집합에 연결한다.
• 다운로드 하는 동안 peer는 chunks를 다른 peers에게 업로드한다.
  • peer는 chunk를 교환하는 peers를 바꿀 수 있다.
  • 만약 peer가 전체 파일을 갖게 되면, 그것은 떠날 수도, torrent에 남아 있을 수도 있다.

Exchanging File Chunk

Requesting chunks

• 어느 시간에나, 다른 peer는 파일 chunk의 다른 부분을 가지고 있다.
• 주기적으로 alice는 각각의 peer에게 그들이 가지고 있는 chunk 목록을 요청한다.
• alice는 가장 드문(?) missing chunk를 peers에게 요청한다.

Sending chunks : tit-for-tat

• Alice는 4명의 peers에게 가장 빠른 속도로 그녀의 chunk를 전송한다.
  • 다른 peers는 Alice에게 질식한다(choked) ; 그녀로부터 chunks를 받지 못함
  • 10초마다 상위 4개를 재평가한다.
• 30초마다 무작위로 다른 peer을 골라서 chunks를 보낸다
  • Optimistically unchoke this peer
  • 새로 선택한 peer가 top 4에 join 할 수 있다.

Streaming and CDN

Video Streaming and CDNs

• video traffic : 인터넷 bandwidth의 가장 주요 consumer! 트레픽의 많은 부분을 차지
  • Netflix, Youtube는 downstream residental ISP Traffic의 각각 37%, 16%를 차지함
  • ~1B는 유튜브 유저, ~75M 는 넷플릭스 유저
• Challenge
  • scalability (확장성)
    : 어떻게 ~1B 유저들에게 도달할 것인가.
    하나의 mega-video server로는 작동하지 않을 것
  • heterogeneity (이질성)
    : 사용자들마다 capabilities이 다르다.
    ex. 유선 vs 모바일, bandwidth가 풍부한 곳과 그렇지 않은 곳
• Solution : distributed, application-level infrastructure!!!

1. Streaming multimedia

Multimedia : Video

• Video란 : 일정한 속도로 표시되는 이미지들의 sequence
• Digital image : 픽셀들의 배열. 각 픽셀들은 bits로 표시됨
  -> CBR (=Constant Bit Rate)
• Encoding : 이미지 내부와 이미지 사이의 중복성을 이용해 이미지를 인코드하는데 사용되는 비트수를 줄인다
  • spatial : 이미지 안에서 씀
  • temporal : 한 이미지에서 다음 이미지로 넘어갈 때 씀
    -> VBR (=Variable Bit Rate) : 비디오의 인코딩 속도는 spatial, temporal coding changes 양에 따라서 변한다.
• spatial coding example : N개의 같은 색을 가진 픽셀 정보를 다 보내는 대신, 색 정보와 반복되는 개수만 전송한다.
• temporal coding example : i+1 번째 이미지 픽셀을 다 보내는게 아니라 frame i 와 달라진 부분만 보낸다.

Streaming Multimedia : DASH

DASH : Dynamic, Adaptive Streaming over Http

• Server
  1. 비디오 파일을 여러개의 덩어리로 나눈다
  2. 각각의 덩어리를 저장하고 각기 다른 속도로 인코딩한다.
  3. Manifest file: 각각 다른 덩어리에 대한 URLs 을 제공한다.컴퓨팅에서 집합의 일부 또는 논리정연한 단위인 파일들의 그룹을 위한 메타데이터를 포함하는 파일이다.
• Client
  1. 주기적으로 server-to-client의 대역폭을 측정한다.
  2. manifest를 consulting하고 한 번에 하나의 chunk를 요청한다.
     • 현재 주어진 대역폭 안에서 받을 수 있는 가장 큰 coding rate의 파일을 고른다.
     • 시점에 따라(사용 가능한 대역폭에 따라) 다른 coding rate를 선택할 수 있다.
• Client 의 "Intelligence" ; 클라이언트가 결정하는 것
  1. 언제 chunk를 요청할지 (버퍼가 남거나 오버플로우가 일어나지 않을 때)
  2. 어떤 인코딩 rate를 요청해야 할지 (더 넓은 대역폭을 사용 가능할 경우 더 높은 품질 추구)
  3. 어디로 chunk를 요청해야 하는지 ( client에게 더 가갑거나 더 많은 대역폭을 사용 가능한 URL server에 요청을 보낼 수 있다)

Case Study : Netflix

2. Content distribution networks ( = CDN )

• Challenge : 어떻게 하면 수십만 명의 동시 사용자에게 컨텐츠를 스트리밍 할 수 있을까?

OPTION 1 : 하나의 넓은 "Mega-server"를 이용한다.

• 하나 잘못되면 다 잘못됨 (Single point of failure)
• network congestion ; 네트워크의 밀집, 정체
• 먼 고객까지 가는 길이 멀다
• 여러 개의 비디오의 복사본이 송신 링크를 통해 전송됨
• ... 이건 좀 아닌 듯

OPTION 2 : 여러 개의 비디오의 복사본을 지리학적으로 분산된 여러 곳에 나누어 저장하고 관리한다.

• CDN 서버를 여러 access networks(사용자들에게 가까운)에 박아 넣어둔다.
• Smaller number (10’s) of larger clusters in POPs (points of presence) near (but not within) access networks
• - limelight에 의해 사용됨

• More Challenges
  1. 어떤 CDN node에서 컨텐츠를 검색해올 것인가
  2. 어떤 컨텐츠를 어떤 CDN node에 배치할 것인가

CDN Content Access : A closer Look

Socket programming

1. UDP socket ; unreliable datagram

• 클라이언트와 서버 사이에 No Connection
  1. 데이터 전송 전에 handshaking 단계 X
  2. Sender는 도착지의 IP 주소와 포트 넘버를 패킷에 명시적으로 담아서 보낸다
  3. Receiver는 수신한 패킷에서 sender의 IP 주소와 포트 넘버를 추출한다.
  4. 전송된 데이터가 분실되거나, 요청이 지난 후 받게될 수 있다.
• *UDP는 클라이언트와 서버 간에 신뢰할 수 없는 bytes 그룹("datagram") 전송 기능을 제공한다. *

2. TCP socket ; reliable, byte stream-oriented

*TCP는 클라이언트와 서버 간에 신뢰할 수 있는, 순서가 있는 byte-stream 전송("PIPE") 를 제공한다. *

• 클라이언트는 무조건 서버와 contact 해야 함!!
  1. 서버 프로세스가 일단 먼저 실행 되어야 뭘 함
  2. 서버는 client의 contact을 받을 socket을 만들게 됨
• 클라이언트가 서버에게 contact 하려면
  1. TCP Socket을 만듦 (서버 프로세스의 IP address와 port number로 구분되는)
  2. client가 socket을 만들 때 client TCP는 server TCP에게 연결을 설정함(establishes)
• 서버는 client에게 contacted 되면 새로운 TCP socket을 만듦
  1. 그 client와 통신하기 위해!
  2. 서버가 여러 클라이언트와 대화할 수 있도록 하려고!
  3. Source port number는 각 클라이언트들을 구분하는데 쓰인다.