1. Principles of network
2. Web & HTTP
3. E-mail, SMTP, IMAP
4. DNS
5. P2P applications
6. Video streaming and CDNs
7. Socket programming with UDP & TCP

P2P applications

Peer-to-peer(P2P) architecture

Peer to peer 설명

앞서 p2p가 무엇인지 배웠었다. 이제 file distribution 측면에서 client-server 구조와 p2p 구조를 비교해보자.

Q. how much time to distribute file (size F) from one server to N peers?

문제는 위 그림처럼 충분한 대역폭을 가지는 네트워크를 둔 상황에서, peer의 업로드, 다운로드 용량이 제한된 자원으로 존재하는 상황이다.

Client-server의 경우

• server transmission : 서버의 경우 모든 peer에게 파일을 보내기 위해 N개의 파일 복사본을 순차적으로 전송(업로드)해야 한다.
  • time to send one copy : F/us
  • time to send N copies : NF/us
• client : 각 client는 파일 복사본을 다운로드 해야 한다.
  • dmin = min client download rate
  • min client download time : F/dmin

=> 최종 시간 : Dc-s $\geq$ max{NF/s,F/dmin}

즉, 업로드 속도와 다운로드 속도를 비교해서 결정되고, peer의 수가 늘어날수록 업로드에 많은 시간이 소요되어 총 걸리는 시간이 늘어나게 된다.

P2P의 경우

• server transmission : 서버는 최소 한 개의 복사본만 올리면 된다.
  • time to send one copy : F/us
• Client : 각 클라이언트는 파일 복사본을 받아야 한다.
  • min client download time : F/dmin
• Client : 전체 client 집단이 최종적으로 NF bit을 받아야 한다.
  • max upload rate (limiting max download rate) : us + $\sum$ui

=> 최종 시간 : DP2P $\geq$ max{F/us, F/dmin, NF/(us + $\sum$ui)}

즉, peer의 수가 늘어남에 따라 업로드 시간이 늘어나긴 하지만, 각 peer가 서비스에 필요한 capacity를 충당해주며 전체 소요시간이 상대적으로 느리게 증가하게 될 것을 예측할 수 있다.

Client-server vs P2P

P2P file distribution : BitTorrent

• 256kB의 chunk들로 파일을 분리한 뒤, torrent에 속하는 peer들이 file chunk들을 전송, 수신 하는 방식이다.

• Torrent를 참가하는 peer는 chunk가 없어도 시간이 지남에 따라 다른 peer로부터 chunk를 얻을 수 있다.
• peer는 tracker를 이용해 peer list를 받아 peer의 부분집합, neighbor들에게 연결될 수 있다.
• 다운로드가 진행되는 동안 peer는 chunk를 다른 peer로 업로드한다.
• peer는 chunk를 교환할 peer들을 바꿀 수 있다.
• peer가 전체 파일을 가지게 된다면, 이기적으로 떠나거나 이타적으로 토렌트 상에 남아있을 수 있다.

BitTorrent: requesting, sending file chunks

Requesting Chunks

• 주어진 시간에 다른 peer는 file chunk들의 다른 subset을 가질 수 있다.
• 주기적으로, Alice는 각 peer에게 그들이 가지고 있는 chunk list를 요청할 수 있다.
• Alice가 없는 chunk를 peer로 부터 요청할 수 있고, 희귀한 것부터 요청하게 된다.

Sending Chunks: tit-for-tat

• Alice는 그녀에게 chunk를 가장 빠르게 보내고 있는 상위 4명에게 chunk를 보낸다.
  • 다른 peer들은 Alice에 의해 choked된다. (chunk를 받지 못하는 상태)
  • 매 10초마다 상위 4명을 재평가한다.
• 매 30초마다 다른 peer를 랜덤하게 선택해서 chunk를 보낸다.
  • 해당 peer를 optimistically unchoke한다.
  • 새로 선택된 peer는 상위 4명과 함께하게 된다.

Tit-for-tat은 좋은 파트너 peer를 남기고 selfish peer를 버리기 위한 전략이다. (같은 peer만 계속 이용할 경우, 모든 파일을 얻어 떠날 수 있기 때문)

Bonus: DHT (Distributed Hash Table)

Trackers in BitTorrent

• BitTorrent와 같은 관습적인 P2P의경우 tracker가 현재 참여하고 있는 peer host들과 해당 peer 장치 어디에 파일 복사본들이 존재하는지 관리하고 있었다.
• 즉, tracker 위주의 centralized index 체제를 따르고 있었다.

그래서 index도 분할시켜 관리한다면 tracker가 필요하지 않을 수 있기에, DHT라는 방식이 등장했다. DHT에선 각 peer가 자기가 소유하고있는 pointer들에 따른 table을 관리하고 있다.

---

Video streaming and CDNs

Video Streaming and CDNs: context

비디오 스트리밍 트래픽은 인터넷 대역폭의 큰 부분을 차지한다. 넷플릭스, 유튜브, 아마존 프라임은 2020년 기준 전체 residential ISP traffic의 80%를 차지하였으니, 그 규모를 실감할 수 있다.

그렇다면, 이렇게 많은 트래픽이 발생하는데 1억명에 가까운 사용자들을 수용할 수 있는걸까? Single mega-video server만으로는 이를 다 수용할 수 없다. 뿐만 아니라 사용자마다 다른 조건(e.g. wired vs mobile, bandwith rich vs bandwith poor)을 가지고 있기에 heterogeneity를 해결하는 것도 중요하다. 이때 제시된 해결책이 바로 distributed, application-level infrastructure이다.

Multimedia: video

비디오는 여러 이미지들의 연속이 일정한 속도로 보여지는 것이고, 각 디지털 이미지는 픽셀들의 배열로 각 픽셀은 비트들로 표현된다. 이때, 이미지 인코딩에 사용되는 비트를 줄이기 위해 이미지 내부 및 이미지 간 중복되는 부분을 활용하는 coding이 존재한다.

• spatial : 하늘을 묘사할 때 연속되는 부분들이 유사한 이미지를 가짐. 이때 비슷한 애들을 다 압축해서 몇개로만 표현.
• temporal : 전체 프레임을 보내는 대신에 이전 프레임과의 차이만을 보냄.
• CBR (Constant bit rate) : Video encoding 속도 고정
• VBR (Variable bit rate) : Video encoding 속도는 spatial, temporal coding에 따라 바뀐다.

Streaming stored video

비디오 스트리미잉은 서버 상에 저장되어있는 영상을 인터넷을 통해 전달해 클라이언트에서 보는 방식인데, 서버와 클라이언트 사이의 대역폭이 시간에 따라 달라지기 때문에 어려움이 생긴다.(네트워크 conjestion level이 바뀜. house/access network/network core/video server) 이런 conjestion에 의해 발생하는 packet loss나 delay는 영상 재생에 delay를 주어 낮은 퀄리티의 영상으로 남게 되는 것이다.

이상적인 방식이라면 위 그림에서 보이듯이 비디오가 서버에 저장되는 속도, 네트워크를 통해 보내지는 속도, 클라이언트에서 재생되는 속도가 일정하다는 것을 확인할 수 있다. 그래서 network delay가 일정하게 나타나기에, 클라이언트 측에서 스트리밍할 때 아무런 문제가 발생하지 않게 된다.

Streaming stored video: Challenges

하지만 실제로 영상을 연속적으로 보내는 것은 어려움이 있다. Client가 영상을 재생한 순간부터, 이후 재생되는 영상들이 기존 영상과 같은 속도를 유지해야만 끊끼지 않고 볼 수 있다. (흔히 우리가 보는 로딩중 화면 같은 것은 네트워크 딜레이로 인해 클라이언트 측 버퍼에서 데이터가 올때까지 기다리는 상태이다.) 이 문제 외에도 client interactivity를 위해 pause, fast-forward, rewind, jump 등의 동작이 가능해야 하고, video packet이 손실될 경우 retransmit도 필요하게 된다는 점 등이 어려움으로 존재한다.

Streaming stored video: Playout buffering

실제 비디오를 스트리밍할 때는 playout buffering이 발생한다. 서버에서 영상을 저장하는 속도와 클라이언트에서 영상을 재생하는 속도는 일정해야 한다. 이때, 영상을 전송하는 네트워크의 딜레이가 일정하지 않고 변수처럼 동작하게 된다. 네트워크가 불안정할수록 클라이언트 측이 가진 버퍼의 양이 많아야 원래 의도대로 영상을 재생할 수 있게 되는 것이다. 또한, 서버와 클라이언트 사이의 물리적 거리가 짧아지면 네트워크 딜레이를 줄일 수 있기에, 여러 대의 서버를 활용하는 CDN 기술이 중요해지는 것이다.

Content distribution networks (CDNs)

• challenge : 어떻게 하면 콘텐츠를 수십만의 동시 사용자들에게 전송할 수 있는가?

첫 번째 선택지 - 하나의 큰 mega-server를 사용하자

• single point of failure (하나 망하면 모두 망함)
• point of network congestion (한 곳에 집중되니 네트워크 송수신 과정 데이터 처리가 더 혼잡)
• long path to distant client (물리적 거리가 멀수록 전송 딜레이도 증가)
• multiple copies of video sent over outgoing link

두 번째 선택지 - 비디오 복사본들을 여러 개의 기하학적으로 분산된 위치에 저장하고 전송하자 (CDN)

• push CDN servers deep into many access networks
  • close to users
  • CloudFlare
    • servers in 250+ cities in 100+ countries
    • 10k+ networks
    • <50ms for 95% users
    • 나무위키가 cloudflare를 사용하는 대표적인 예.

CDN은 컨텐츠 복사본들을 CDN node에 저장하고 있고, subscriber가 CDN으로부터 컨텐츠를 요청하면 가까운 node로부터 컨텐츠를 꺼내온다. 이때, 네트워크 경로가 congest되어 있으면 다른 복사본을 고를 수도 있다.

CDN content access

---

Socket programming with UDP & TCP

Socket programming

Socket programming은 client/server application에서 socket을 이용해서 communicate하는 방식이다. 여기서 Socket은 application process와 end-end-transport protocol 사이의 문과 같은 역할을 하며, user level에서 kernel의 network를 쓸 수 있게 해주는 interface이다.

Socket programming은 두 가지 방식의 transport service가 있으며, 각각의 서비스에 따른 socket type이 존재한다.

• UDP : unreliable datagram
• TCP : reliable, byte stream-oritented

Socket programming with UDP

• UDP : no "connection" between client and server
  UDP는 데이터 전송 전에 handshaking 과정이 존재하지 않는다. 이로 인해 sender가 IP destination address & port를 각 packet에 직접적으로 명시해서 사용한다. 마찬가지로 receiver도 packet으로부터 sender의 IP address & port를 추출해서 알아낸다.

• UDP : transmitted data may be lost or received out-of-order
  데이터가 도착할지, 올바른 순서대로 도착할 지 보장할 수 없어, unreliable하게 되는 것이다.

Client/server socket interaction: UDP

1. client와 server에서 socket을 생성함.
2. client에서 server IP와 port를 포함해서 datagram을 만듬. clientSocket을 전송.
3. serverSocket에서 datagram을 읽음.
4. serverSocket에서 client address와 port를 포함하여 답변하느 datagram 만듬.
5. clientSocket에서 datagram을 읽음.
6. clientSocket을 닫음.

Example app

UDP Client

UDP Server

Socket programming with TCP

TCP의 경우 client가 server와 반드시 접촉해야 하기 때문에 server process가 항상 실행되어 있어야 하고, client가 접촉할 수 있는 socket을 만들어 둬야 한다.

Client는 TCP socket을 접촉하고자하는 server의 IP 주소와 port를 포함해서 만들고, client가 socket을 생성할 때 server TCP와 connection이 만들어진다.

Client에 의해 접촉될 때 server TCP는 해당 특정 client와 소통하기 위한 server process의 새로운 socket을 만들게 된다. 매번 새로운 소켓을 만들기에 서버는 여러 클라이언트를 둘 수 있고, 같은 서버는 같은 IP 주소를 가지기에 port 번호를 통해 구분한다.

TCP는 reliable하며 in-order를 보장하는 byte-stream transfer("pipe")가 가능하다.

Client/server socket interaction: TCP

1. 서버에서 추후 들어올 request를 읽기 위해 port번호를 명시하여 serverSocket을 만들어둔다.
2. 서버의 소켓은 connection request를 기다리고 있다.
3. 클라이언트가 host id와 port를 명시해 clientSocket을 생성하고, 이때 tcp connection이 이루어지며 connectionSocket을 통해 소통하게 된다.
4. clientSocket을 통해 request 전송
5. connectionSocket에서 request를 읽는다.
6. reply를 작성해 clientSocket으로 보내고, 여기서 읽는다.
7. connectionSocket과 clientSocket을 닫는다.

Example app

TCP Client

UDP와 달리 메세지를 전송할 때 서버의 이름과 포트를 명시할 필요 없음.
한 번 연결해두면 끝.

TCP Server

여기선 listen의 과정이 추가되었으며, accept를 통해 connection을 생성하고 connectionSocket을 닫을 뿐 serverSocket은 내버려둔다.