개요

• transport layer는 다른 호스트에서 동작하는 프로세스 사이의 논리적 통신을 제공한다.
• end-system에서 동작한다.
  • sender : 메시지를 segment로 쪼개 network layer로 전달
  • receiver : segment를 메시지로 조립해 application layer로 전달
• TCP, UDP
• Network layer에 의존한다

Mux/Demux

Multiplex (모음)
Demultiplex (배포)

Multiplexing

sender.
소켓들로부터 나온 메시지에 트랜스포트 헤더를 붙임

Demultiplexing

receiver.
헤더 정보를 보고 올바른 소켓으로 보냄

• Connectless Demultiplexing : 수신측 IP주소, 포트번호가 같으면 같은 소켓으로 감
• Connection-oriented demultiplexing : source IP, port와 dest IP, port가 같아야 같은 소켓으로 감

UDP

User Datagram Protocol

특징

• best-effort : 손실이나 순서 뒤바뀜 있을 수 있음
• 커넥션 체결 없음
  • 핸드셰이킹 없음
  • 각 UDP 세그먼트는 독립적으로 처리됨
• 간단 (stateless)
  • 헤더사이즈 작음
  • 혼잡제어 없음
• 쓰임새 : streaming video, DNS, HTTP/3, SNMP(Simple Network Management Protocol)

UDP Segment

<---------36bits------->
<--16bits-->
+----------+-----------+
| src port | dest port |
+----------+-----------|
|  length  | checksum  |
+----------------------|
|   application data   |
|      (payload)       |
+----------------------+

• length : segment의 byte단위 길이
• checksum : 헤더값들의 합
  • 수신측에서 헤더값들의 합과 체크섬이 다르면 에러, 같으면 정상
  • 그러나, 헤더값이 전송과정에서 훼손되었어도 합은 우연히 체크섬과 같을 수 있다. (완벽한 오류탐지법이 아니다.)

체크섬 계산 예시

  11010100
  10111000
 ---------
 100001100 합 : 맨 앞 오버플로우 1은 가장 낮은자리에 넣는다.
  00001101 체크섬

rdt

reliable data transfer

         sending process        receiving process
rdt_snd()---------------        -----------------rdt_rcv()
           rdt protocol            rdt protocol
udt_snd()---------------        -----------------udt_rcv()
                ↑        UNRELIABLE       ↑
                +------→  CHANNEL  ←------+

** FSM : Finite State Machine

+-----+ 
|state|  ---┐  event
|     |  <--┘  ㅡㅡㅡ
+-----+        action

버전

각 버전에 대한 FSM은 여기서 볼 수 있다.

• rdt 1.0
  • ✅ 채널을 신뢰한다. (비트 에러, 패킷 손실 없음)
• rdt 2.0
  • ✅ 채널에서 비트 에러가 발생할 수 있다고 가정 ---> 체크섬 필요
  • 에러 감지와 복구를 위한 응답
    • ACKs
    • NAKs : 에러가 있다고 명시적으로 응답 (재전송 필요)
  • stop and wait : 패킷을 하나 보낸 뒤 응답이 올 때 까지 대기함 (FSM에서 ∧는 아무것도 안한다는 의미)
  • 🔥 결점 : 응답이 훼손되면 아무것도 못한다. 그렇다고 그냥 무작정 재전송 하기에는 수신측에 중복 대응 능력이 없다. ---> 타임아웃을 도입하고 패킷마다 시퀀스 넘버를 주면 좋겠다.
• rdt 3.0
  • ✅ 채널에서 비트에러와 패킷 손실이 발생한다고 가정
  • 타임아웃 : sender가 적당한 시간동안 ACK를 기다림. 기다려도 안오면 패킷을 재전송.
  • 시퀀스 넘버 부여 : sender가 보내는 패킷마다 번호 부여. receiver측에서 어떤 번호에 ACK를 보냈는지 기록하면 중복된 패킷이 또 들어왔을 때 무시할 수 있음. (중복 재전송 대응가능)
  • ⚡ 성능 : $U_{sender} = \frac{\frac{L}{R}}{RTT\times\frac{L}{R}}$
  • 🔥 결점 : stop and wait로 동작하기 때문에 성능이 낮다. 아래 layer들(하드웨어)는 더 빠르게 동작할 수 있는데, 소프트웨어단에서 성능저하를 유발하고 있는 상황이다. 응답을 받지 않고도 패킷을 전송하는 방법으로 해결한다. 이를 pipelining이라 한다.

파이프라이닝

응답을 받지 않고 여러 개의 패킷을 전송한다.
3-packet pipelining하면 Utilization은 $U_{sender} = \frac{3 \frac{L}{R}}{RTT\times\frac{L}{R}}$

복구 방법으로 GBN, SR이 있다.

ACK는 cumulativate ACK이다. (10번까지 받았으면, "10번까지 받았다"가 아니라 "11번 내놓으라"고 응답을 보냄)

GBN (Go-Back-N)

• sender
  • send_base : 보냈지만 ACK를 받기 전인 패킷 중 가장 앞쪽 것
  • nextseqnum : 보내기 이전인 패킷 중 가장 앞쪽 것
  • window size : 최대 한 번에 전송할 수 있는 패킷의 수. 사이즈가 N이면 send_base부터 뒤쪽으로 N개를 윈도우에 포함
  • 가장 오래된 송신에 대해 타임아웃 적용. 타임아웃 나면 윈도우에 있는 것들 재전송
• receiver
  • rcv_base : 아직 받지 못한 패킷 중 가장 앞쪽 것

SR (Selective Repeat)

윈도우 내의 패킷들에 대해 개별적으로 재전송함
** 시퀀스 넘버는 윈도우 사이즈보다 커야 한다.

• sender
  • send_base
  • nextseqnum
  • window
  • 모든 unACKed 패킷에 대해 타이머 운영/타임아웃/재전송
• receiver
  • sender와 동일한 크기의 window.

TCP

** MSS : Maximun segment size

특징

• point-to-point : sender --> receiver
• reliable, in-order byte stream.
• full-duplex data
• cumulative ACKs
• pipelining
• connection-oriented
• flow controlled

TCP Segment Structure

<-----------32bits-------------->
<---16bits----->
+--------------+----------------+
|  src port    |    dest port   |
+--------------+----------------+
|        sequence number        |
+--------------+----------------+
|          ack number           |
+--------------+----------------+
|headlen flags | receive window |
+--------------+----------------+
|  checksum    |Urg data pointer|
+--------------+----------------+
|                               |
|          options              |
+--------------+----------------+
|                               |
|          data                 |
|                               |
+--------------+----------------+

• flags : C E U A P R S F
  • C E : Congestion noti
  • A : ACK
  • R S F : RST SYN FIN

RTT

• EstimatedRTT = (1-a)*EstimatedRTT + a*SampleRTT
• Time Inverval = EstimatedRTT + 4*DevRTT
• DevRTT = (1-b)*DevRTT + b*|SampleRTT-EstimatedRTT|

빠른 재전송

타임아웃되기 전에 세 번 정도 중복응답오면 재전송

Flow control

1.수신측에서 RcvBuffer를 갖고 있고, 이 중 이용가능한 부분의 크기를 나타내는 rwnd (receive window)값을 갖고있음.
2. rwnd값은 TCP응답의 헤더에 실어보냄.
3. 송신측은 rwnd값을 보고 데이터가 넘치지 않도록 보내는 양을 조절함

Connection management

수신프로세스와 송신프로세스가 데이터를 주고받기 전 핸드셰이킹을 해야 한다. 이는 양쪽 모두 통신을 하고 싶어 함을 확인하고 주고받을 파라미터를 합의하는 동작이다.

• 2-way handshake
  • 클라이언트 --> 서버 : req_conn(x)
  • 서버 --> 클라이언트 : acc_conn(x)
  • 문제 : half_open connection 발생 가능
• 3-way handshake
  • 클라이언트 --> 서버 : SYNbit=1, Seq=x
  • 서버 --> 클라이언트 : SYNbit=1, Seq=y, ACKbit=1, ACK=x+1
  • 클라이언트 --> 서버 : ACKbit=1, ACK=y+1
• TCP커넥션 닫기
  • 닫고자 하는 쪽에서 FINbit=1인 세그먼트를 보낸다.
  • 이에 응답한다.

Congestion control

insight

• throughput은 capacity를 넘지 않는다.
• arrival rate가 capacity에 근접할 수록 딜레이가 매우 커진다.
• 손실, 재전송, 불필요한 중복은 throughput을 낮춘다.
• 업스트림 transmittion capacity, buffering은 다운스트림 패킷을 낭비한다.

구현 아이디어

• end-end congestion control : 손실과 딜레이로 혼잡함을 눈치챔 (TCP에서 사용)
• Network-assisted congestion controll : 라우터가 송수신 호스트에게 망이 혼잡함을 명시적으로 알려줌 (TCP ECN, ATM, DECbit)
  • ECN : 라우터의 ECN값이 수신측으로 간 뒤, 수신측에서 헤더에 ECE를 실어 응답

알고리즘

AIMD 접근법을 사용한다.

• ssthresh : slow start상태를 유지할 최고 윈도우 크기
• slow start : ssthresh지점까지 지수승으로 윈도우 크기 증가
  ssthresh를 지나면 linear하게 증가한다.

AIMD, RENO, TAHOE
CUBIC

• RENO
  • 3연속 중복ACK를 받으면 : 전송률 반으로
  • 타임아웃 나면 : 전송률 반으로
• Tahoe
  • 3연속 중복ACK를 받으면 : 전송률 1MSS로
  • 타임아웃 나면 : 전송률 1MSS로
• CUBIC : 3차함수

Fairness

TCP끼리는 공평하다.
TCP-UDP끼리는 불공평하다
병렬 TCP는 불공평할 수도 있다. (한 앱이 대다수의 TCP커넥션을 먹을 수 있음)