컴퓨터네트워크 04주차 Application Layer_03/Transport Layer_01

주 교재 : Computer Networking : A Top-Down Approach

 

4주차 Application Layer_03 / Transport Layer_01

1. P2P applications
2. video streaming and content distribution networks
3. socket programming with UDP and TCP

 

1. Transport-layer services
2. Multiplexing and demultiplexing
3. Connectionless transport : UDP

---

1. P2P applications

#Peer-to-peer(P2P) Architecture

• 서버가 없다.
• end system 끼리 직접 소통
• ex : P2P file sharing (토렌트), streaming (KanKan), VoIP (Skype)

#File distribution time: client-server

Server

• F = File
• N = 보낼 개수
• U_s = 업로드 시간

Client

• F = File
• d_min = 다운로드 시간

한 서버에서 모든 요청에 대한 파일 전송을 처리하기 때문에 속도가 느림

#File distribution time: P2P

Server

• 1개의 파일만 복사해서 보내면 업로드하면 됨.

Client

• file copy를 받음.
• F = File
• d_min = 다운로드 시간

Clients

• NF bits를 다운로드 받아야 한다.

Client-server vs. P2P

Client-server vs. P2P

#P2P file distribution: BitTorrent

• 파일을 256kb의 chunks로 나눈다.
• 토렌트의 peer는 file chunks를 주고 받는다.
• ex : 파일이 1 GB라고 가정했을 때, 1GB를 다 가지고 있는 사람과 0.5GB를 가지고 있는 사람 중 빨리 받을 수 있는 사람에게 파일을 받는다.
• Tracker : 토렌트에 참여하는 peer를 찾아서 거리 계산을 해준다.
• Churn : Peer는 토렌트에 들어왔다가 나갔다가 할 수 있다.
  그래서 peer가 적은 chunks를 먼저 받아야 한다.
• chunks를 요청할 때, 많은 peer 중에 빨리 교환할 수 있는 사람을 골라서 교환한다.

Sending chunks : tit-for-tat

• 교환량이 많은 top4를 10초마다 재평가해서 고른다.
• 30초마다 무작위로 다른 peer를 선택한다. => 새로 참여하는 사람에게도 기회를 줘야하기 때문
• 업로드 정도가 높으면 더 빠르게 다운로드를 받을 수 있음

---

2. video streaming and content distribution networks

#Video Streaming and CDNs: context

• Stream video traffic : 인터넷 대역폭의 대부분을 사용한다. 너무 큼.
• solution : application level infra를 분산시킨다.

#Multimedia: Video

• Video = Frame 집합
  Frame = Pixel 집합
  Pixel = RGB값 집합
• 이미지를 인코딩하는 데 사용되는 비트를 줄이기 위해 이미지 내부 및 이미지 간에 중복성을 사용한다.
  spatial = 같은 색깔을 보내는 것 대신에, 색깔 값과 반복되는 값의 숫자를 보낸다.
  temporal = 두 frame의 차이를 계산해서 보낸다.

#Streaming Stored Video

Challenges

• server-to-client 대역폭은 시간에 따라 바뀔 수 있다.
  이로 인해 네트워크 지연(delay)가 발생한다.
• 사용자의 상호작용이 다양해서 계속 재생하는데 제약이 따른다.

playout buffering

#Streaming multimedia: DASH

• DASH : Dynamic, Adaptive Streaming over HTTP = 잘 될 때 미리 받기
• Client는
  - 언제 chunks를 요청할지 (buffer가 비었는지, 넘치는지)
  - 요청할 인코딩 속도 (더 많은 대역폭을 사용할 수 있을 때 높은 퀄리티)
  - 어디서 chunk를 요청할지 (client에 가깝거나, 사용 가능한 대역폭이 높은 URL server에 요청 가능)
  결정한다.
• Streaming video = encoding + DASH + playout buffering

#Content Distribution Networks (CDNs)

• CDN : CDN node에 content의 복사본을 저장한다.
• 구독자들은 CDN에 content를 요청한다.

Case study: Netflix

---

3. socket programming with UDP and TCP

#Socket programming

• 5계층(Application Layer)와 4계층(Transport Layer) 사이에 있다.
• UDP = 속도
• TCP = 신뢰성

#Socket programming with UDP

UDP : client와 server사이에 연결이 없다.

• 데이터를 전송하기 전에 handshaking이 없다.
• 목적지의 IP 주소와 port 번호만 알면 된다.
• 데이터 Loss가 발생하거나 받는(received) 순서가 바뀔 수 있다.
  Loss가 발생해도 그냥 간다.
  순서가 다른 이유는 가는 길이 다르기 때문이다.

#Socket programming with TCP

• Client는 반드시 server와 contact 해야한다.
  - server process가 반드시 먼저 실행되어야 한다.
• Client는 다음과 같은 방법으로 server에 contact 한다.
  - TCP socket을 만들고, server process의 IP주소와 port 번호를 특정한다.
  - client가 socket을 만들 때, client TCP가 server TCP로 가는 연결을 만든다.
  - client와 contact 됐을 때, server TCP는 특정 client와 통신하기 위해서 server process를 위한 새로운 socket을 만든다. 

 

---

Transport Layer_01

1. Transport-layer services

#Transport Services and Protocols

• 다른 host에서 동작하는 application process 간에 논리적 통신(logical communication)을 제공한다.
• Transport protocol는 end system에서 동작한다.
  - 보내는 쪽 : application massage를 segment로 쪼개서 network layer로 보낸다.
  - 받는 쪽 : segment를 message로 다시 합쳐서 application layer로 보낸다.

#Transport vs. Network layer Services and Protocols

• network layer : Host 간에 논리적 통신
• transport layer : process 간에 논리적 통신

#Internet Transport-layer Protocols

• 신뢰성, 순서대로 전달 (TCP)
• 신뢰성이 없고, 순서 없이 전달 (UDP)
  - 보내기만 잘 하면 됨
• 둘 다 제공 안하는 것
  - delay guarantees
  - bandwidth guarantees
  - security

---

2. Multiplexing/demultiplexing

• multiplexing at sender
  - header를 붙이면서 내려가는 것
• demultiplexing at receiver
  - header를 떼면서 올라가는 것

#How Demultiplexing Works

• host가 IP datagrams를 받으면,
  - 각각의 datagram은 source IP 주소와, destination IP 주소를 갖는다.
  - 각각의 datagram은 하나의 transport 계층의 segment를 갖는다.
  - 각각의 segment는 source, destination port 번호를 갖는다.
• host는 IP주소와 port 번호를 이용해서 segment를 적절한 socket으로 보낸다.

 

#Connectionless Demultiplexing

UDP socket으로 보낼 datagram을 만들 때는

• 목적지 IP 주소
• 목적지 port 번호

가 특정돼야 한다.

#Connection-oriented Demultiplexing

TCP socket은 4가지 정보로 식별된다.

• source IP 주소
• source Port 번호
• destination IP 주소
• destination Port 번호

---

3. Connectionless transport : UDP

#UDP: User Datagram Protocol [RFC 768]

• no frills internet transport protocol
• UDP segment는
  - lost
  - 순서 없이 전달됨
• connectionless
  - UDP sender와 receiver 사이에 handshaking이 없다.
  - 각각의 UDP segment는 독립적으로 다뤄진다.
• UDP 활용
  - streaming multimedia apps (loss tolerant, rate sensitive)
  - DNS
  - SNMP (Simple Network Management Protocol)
• 신뢰성을 보장하는 UDP 전송
  - HTTP/3

#UDP Segment Header

 

• checksum을 쓰는 이유
  - 받는 쪽으로 데이터가 정확히 간다는 보장이 없기 때문에 데이터 유효성 검사를 하기 위해서 사용한다.
  - checksum 값을 보내고, 받는 쪽에서 checksum을 계산 했을 때 그 값이 같으면 유효한 데이터.

#UDP Checksum

sender

• segment contents(header field를 포함한)을 16 bit 정수로 취급
• checksum : segment content의 합(1의 보수)
• sender는 checksum 값을 UDP checksum field에 담아서 보낸다.

receiver

• segment는 받은 checksum을 계산한다.
• 계산된 checksum 값과 받은 checksum 값이 같은지 검사한다.

---