3. Transport Layer

---

이번에도 역시 이번 챕터의 목표를 먼저 확인하자

• transport layer services의 원리 이해:
  • multiplexing, demultiplexing
  • reliable data transfer
  • flow control
  • congestion control
• internet transport layer protocol 이해
  • UDP: connectionless transport
  • TCP: connection-oriented reliable transport
  • TCP congestion control

---

Transport-layer service

---

Transport services and protocols

• 서로 다른 host들에서 실행중인 application process들 사이에서의 logical communication 제공
  • Logical communication: network의 수많은 path를 고려하지 않고 end-to-end communication만 고려하는 것
• transport protocol들은 end system에서 작동한다.
  • sender: application message를 segment로 쪼개고 network layer로 보낸다.
  • receiver: segment들을 재조립해서 message로 만든 후 application layer로 보낸다.
• Internet application들에서 사용가능한 두 가지 transport protocol
  • TCP, UDP
• 참고로 Network layer는 host간의 logical communication을 제공하고, transport layer는 process간의 logical communication을 제공한다.

---

Transport Layer Actions

Sender

• Application layer에서 message를 전달 받음
• segment header field들의 값을 결정함
• segment를 생성
• segment를 IP로 보냄

Recevier

• IP로부터 segment를 받음
• header 값을 확인
• application-layer message를 추출함
• socket을 통해 message를 app으로 demultiplex

---

Two principal Internet transport protocols

TCP: Transmission Control Protocol

• reliable, in-order delivery
  • error 발생시 recovery 실시
  • out-of-order packet은 rearrange함.
• Congestion control
  • network 상에서 buffer overflow가 발생하지 않도록 Sender는 보내는 속도를 조절하는 것.
• Flow control
  • receiver 또한 받아온 packet을 transport layer의 buffer에 저장하는데, 이때 해당 버퍼에서 buffer overflow가 발생하지 않도록 sender가 보내는 속도를 조절함(throttle)

UDP: User Datagram Protocol

• Unreliable, unordered delivery

  • Packet은 loss 될 수 있음

• "Best effort": no-frills extension (불필요한 서비스가 없음)

• 두 서비스 모두 delay guarantee나 bandwidth guarantee가 없다.

  • network나 link 자체에서 제공할 수 있는 거지, transport layer가 제공하는 것이 아님

---

Multiplexing and demultiplexing

---

• 두 작업 모두 transport layer에서 발생한다. (다른 layer에서도 발생하나, 여기서는 transport layer에서의 것을 다룬다.)
• Multiplexing은 sender측에서 여러 Socket에서 오는 data들에 transport header를 추가해서 packet으로 보내는 작업
• Demultiplexing은 receiver가 해당 segment의 header 정보를 이용해 적절한 socket으로 보내는 작업이다.
  • Port 번호를 통해 Data를 목적 process에게 전달하는 작업

---

Demultiplexing

• Host가 IP datagram을 받음
  • 각 datagram은 source IP 주소와 destination IP 주소를 가짐
  • 각 datagram은 transport-layer segment를 운반
  • 각 segment는 demultiplexing을 위해 source,destination port number를 가지고 있음
    • TCP/UDP 둘다
• Host는 IP 주소와 port번호를 사용해서 segment를 적절한 socket에 보낸다.

UDP에서의 demultiplexing

• Socket을 만들 때 반드시 host-local port번호를 명시해야 한다.
  ex) DatagramSocket javaSocket = new DatagramSocket(12345);
• UDP socket에 넣을 datagram을 만들 때 destination IP 주소와 포트 번호를 명시해야 한다.
  • 심지어 모든 packet에 붙여야 함.. (connection이 없으니까..)
  • header로 추가됨
• Host가 UDP segment를 받으면 segmetn의 destination port 번호를 확인한다.
  • demultiplexing을 위해 오직 destination port 번호만 사용한다
  • 해당 port 번호의 socket에 UDP segment를 전달한다.
  • IP는 이미 Host를 가릴 때 사용했기 때문에 여기선 상관 x (한 host 안에선 다 같은 IP)
• 여기서 가장 중요한 점은 Source IP 주소나 port가 다르더라도, destination port가 같으면 같은 socket에 연결된다는 것 이다.
• 1대 다 통신이 가능함. (하나의 socket이 여러 process와 연결될 수 있다..)

TCP에서의 demultiplexing

• TCP socket은 4가지 tuple들에 의해서 구분된다. (Source IP, port / Destination IP, port)
  • demux: receiver는 segment를 올바른 socket에 연결시키기 위해서 4가지 정보를 모두 사용한다.
  • server는 동시에 여러 TCP socket을 지원할 수 있음.
    • each socket은 그것의 4-tuple들에 의해서 식별됨
    • 각 socket은 서로 다른 client 하나씩 연결됨
    • socket은 1대 1 통신만 가능
  • 아래 그림에서 destination ip는 B로, port는 80으로 같지만, source IP나 port번호가 다르기 때문에 서로 다른 socket들로 demultiplex됨

Demultiplexing 요약

• Multiplexing과 Demultiplexing은 segment, datagram의 header field의 값을 기반으로 처리됨
• UDP: 오직 destination port 번호만 사용해서 demultiplexing
• TCP: 4-tuples(source and destination IP and port num)을 모두 사용해서 demultiplexing
• Multiplexing과 Demultiplexing은 모든 layer에서 발생한다!

---

Connectionless transport: UDP

---

UDP: User Datagram Protocol

What UDP?

• port를 사용해서 datagram을 application layer에 전달만 함
• no frills, bare bones internet transport protocol
• "best effort" service
  • UDP의 segment는 loss될 수 있고, out-of-order로 전달될 수 있음
• connectionless
  • UDP sender와 receiver사이엔 handshaking 과정이 없다.
  • 각 UDP segment들은 다른 segment와 독립적으로 처리된다. (Packet은 individual, independent함)

Why UDP?

• Connectionless: RTT delay가 적다
• Simple: sender, receiver에 connection state가 없다.
• small header size
• no congestion control
  • congestion시 TCP는 보내는 양을 줄임
  • UDP는 그런거 없고 원하는 만큼 빠르게 보낼 수 있다.
    • congestion을 직면해도 기능할 수 있다.

Where UDP?

• Streaming multimedia apps (loss 감내, rate가 중요)
• DNS
• SNMP
• HTTP/3
• 만약 HTTP/3처럼 UDP를 쓰면서도 reliable transfer를 원한다면, application layer에서 reliability를 구현해줘야 된다.
• congetsion control 또한 application layer에서 구현 가능.
• 아무튼 뭔가 기능이 필요하면 application layer에서 추가해줘야 한다.

How UDP?

• UDP Sender Action
  • Application layer message를 받는다
  • UDP Segment header file 값들을 설정한다
  • UDP Segment를 생성한다
  • IP로 segment를 넘긴다
• UDP Receiver Action
  • IP에서 segment를 받는다
  • UDP checksum header값을 확인한다
  • Application layer의 message를 추출한다
  • socket을 통해 application에 message를 demultiplexing한다. (port number 사용)

---

UDP Segment Header

• Source port, dest port, length, checksum은 각 16bit (2byte)
• Header 뒤에 application data(payload)가 온다.
• length는 header포함 segment의 길이
• checksum은 전달된 데이터의 correctness 확인 용도로 사용된다.

UDP checksum

• Goal: 전송된 segment에서 flipped bit등의 error를 찾아내는 것
• Sender
  • hedaer를 포함한 UDP segment를 16-bit integer의 sequence로써 contents handle
  • checksum: segment content의 합
  • checksum value는 UDP header의 checksum field에 들어감
• receiver
  • 받은 segment의 checksum을 계산한다
    • segment의 모든 field를 word 단위로 다 더한다. (c0ff + ff32 + ... + 7374)
    • 더할 때 carryout을 result에 더해준다.
    • 모든 bit에 대해서 보수 연산을 취해준다. (0101 -> 1010)
  • 위 과정을 통해 계산된 checksum 값이 checksum field의 값과 같은지 확인한다
    • 만약 다르면 - error detected
    • 같으면 - 에러는 감지되지 않음. 그래도 에러가 생길 수 있지 않을까..?

checksum: weak protection

• 두개의 16-bit 정수를 더한다고 할 때 마지막 두 자리가 원래 1 0이고 다른 하나는 0 1이라고 하자. 이 때 서로 바뀌어도 (0 1, 1 0으로) checksum에는 값의 변화가 없다...!
  • 해결 방법
    • CRC
    • 2-way checksum (2차원으로 검증)

UDP Discussion

• UDP는 큰 데이터를 보낼 수 있다. 그럼 그냥 보내면 될까?
  • 어차피 link layer에 data size 제한이 있어 더 큰 사이즈의 data를 보내고 IP layer에서 쪼개진다..
    • 만약 IP fragmentation이 일어나 잘못돼도, UDP는 해당 상황을 handle하지 않는다
    • 사용자에게 작은 사이즈로 보내기를 권장
  • 만약 큰 데이터를 보냈다 하더라도, 그 중 일부에 문제가 생겼을 뿐인데(심지어 단 1개의 비트라도) checksum에 의해 에러가 잡힌다.
    • 만약 에러가 생기면 전체를 다시 보내야된다..
    • UDP는 에러가 난 부분만 care해주지 않는다.

---