[🌐CN] TCP - Transmission Control Protocol

Posted Oct 19, 2025 Updated Oct 19, 2025

By xmoonanx

23 min read

🌐 Internet Protocol 전공 수업 정리

신뢰성 있는 데이터 전송의 핵심! TCP는 연결 지향적이고 신뢰성 있는 전송을 보장하는 Transport Layer 프로토콜이다. 패킷 손실, 순서 변경, 중복 등 네트워크의 다양한 문제를 해결하여 안정적인 데이터 전송을 제공한다.

TCP Service Model

Network의 Challenge

네트워크는 다음과 같은 문제들을 발생시킬 수 있다:

drop packets: 대량의 패킷 손실 가능
delay packets: 수 초간 지연 가능
deliver packets out-of-order: 임의 지연으로 인한 순서 변경
replicate packets: 드물지만 패킷 복제 발생
corrupt packets: 데이터 손상

TCP의 핵심 기능

📚TCP (Transmission Control Protocol): Transport Layer에서 신뢰성 있고 순서가 보장된 바이트 스트림 전송을 제공하는 연결 지향 프로토콜

주요 특징:

Reliable delivery (신뢰성 있는 전달)
- IP가 패킷을 잃어버리는 경우 TCP는 retransmission 수행
In-order delivery (순서 보장)
- IP가 out-of-order delivery를 하는 경우 TCP가 reordering한 후 application에게 전달
Flow control (흐름 제어)
- 수신 application이 받을 수 있는 만큼만 배달
Byte-stream (바이트 스트림)
- 데이터는 바이트의 연속
- Segmentation → PMTU discovery 이용
Connection oriented (연결 지향)
- 데이터 전송관리 (flow-control, reordering, segmentation, congestion control)
- Hopefully with good performance

TCP Support for Reliable Delivery

신뢰성 보장 메커니즘

1. Checksum

수신자에서 손상된 데이터 감지
손상된 패킷은 드롭

2. Sequence numbers

누락된 데이터 감지
데이터를 올바른 순서로 재배열

3. Retransmission

송신자가 손실되거나 손상된 데이터 재전송
Round-trip time 추정에 기반한 timeout
Fast retransmit algorithm으로 신속한 재전송

Connection-Oriented

📚Connection Establishment: 데이터 전송 전에 TCP는 연결을 수립해야 함

연결 특징:

하나의 TCP entity는 연결을 기다림 (“server”)
다른 TCP entity (“client“)가 서버에 접속
각 연결은 full duplex (양방향 통신)

CLIENT                          SERVER
                                waiting for
                                connection
                                request
  Request a connection    ────────►
                          ◄────────
  Accept a connection

  Data Transfer           ────────►
                          ◄────────

  Disconnect              ────────►

TCP Header

 0                   15 16                  31
┌───────────────────────┬──────────────────────┐
│    Source Port        │   Destination Port   │
│      (16 bits)        │      (16 bits)       │
├───────────────────────┴──────────────────────┤
│            Sequence Number (32 bits)         │
├──────────────────────────────────────────────┤
│         Acknowledgment Number (32 bits)      │
├─────┬────┬──────────────┬────────────────────┤
│HdrLen│ 0  │    Flags     │  Advertised window │
│(4bit)│(6b)│   (6 bits)   │     (16 bits)      │
├──────┴────┴──────────────┼────────────────────┤
│   TCP Checksum (16 bits) │ Urgent Pointer     │
│                          │    (16 bits)       │
├──────────────────────────┴────────────────────┤
│           Options (variable)                  │
├───────────────────────────────────────────────┤
│                  Data                         │
└───────────────────────────────────────────────┘

주요 필드

1. Sequence Number (32 bits)

이 세그먼트에 포함된 데이터의 시작 바이트 오프셋

2. Acknowledgment Number (32 bits)

순서대로 수신한 가장 높은 시퀀스 번호 바로 다음 번호
“다음에 기대하는 바이트는?”
송신자가 시퀀스 S에서 시작하는 N 바이트를 보내면 ACK는 S+N

3. Header Length (4 bits)

TCP 헤더의 4바이트 워드 개수
5 = 옵션 없음 (20 bytes)

4. Reserved (6 bits)

“Must Be Zero” - 예약된 비트

5. Flags (6 bits)

SYN: 연결 수립
ACK: Acknowledgment 유효
FIN: 연결 종료
RST: 연결 리셋
PSH: Push
URG: Urgent

6. Advertised Window (16 bits)

데이터 수신을 위해 사용 가능한 버퍼 공간
TCP의 sliding window에 사용
Acknowledgment 필드 값을 넘어선 오프셋으로 해석

7. Checksum (16 bits)

에러 감지용

8. Urgent Pointer (16 bits)

URG 플래그가 설정된 경우 사용

ACKing and Sequence Numbers

ACK 메커니즘

송신자가 패킷 전송:

데이터는 시퀀스 번호 X에서 시작
패킷은 B 바이트 포함
X, X+1, X+2, …, X+B-1

패킷 수신 시, 수신자는 ACK 전송:

Case 1: X 이전의 모든 데이터가 이미 수신됨

ACK는 X+B를 확인 (다음 기대 바이트이므로)

Case 2: 이미 수신한 가장 높은 바이트가 더 작은 값 Y

ACK는 Y+1을 확인
이미 ACK했더라도 다시 전송

Cumulative ACK (누적 ACK)
TCP는 누적 ACK 사용
ACK 번호는 “이 번호 이전까지 모두 받았음”을 의미
중간에 손실된 패킷이 있어도 동일한 ACK 반복 전송

Initial Sequence Number (ISN)

📚ISN (Initial Sequence Number): 첫 번째 바이트의 시퀀스 번호

왜 ISN = 0이 아닌가?

실용적 이유:

IP 주소와 포트 번호가 연결을 고유하게 식별
결국 이 포트 번호들은 다시 사용됨
오래된 패킷이 여전히 전송 중일 가능성
새로운 연결과 연관될 수 있음

TCP의 해결책:

ISN을 변경하도록 요구
4 마이크로초마다 틱하는 32비트 클록에서 설정
4.55시간마다 한 번만 wrap around
연결 수립 시 호스트들이 ISN 교환

CONNECTION ESTABLISHMENT: THREE-WAY HANDSHAKE

3-Way Handshake 과정

📚Three-Way Handshake: TCP 연결 수립을 위한 3단계 핸드셰이크 프로세스

Client (initiator)              Server
Active Open                     Passive Open

connect()                       listen()
    │                              │
    │  SYN, SeqNum = x             │
    ├──────────────────────────────►
    │                              │
    │  SYN + ACK, SeqNum = y,      │
    │            Ack = x + 1       │
    ◄──────────────────────────────┤
    │                              │
    │  ACK, Ack = y + 1            │
    ├──────────────────────────────►
    │                              │
                                accept()

Step 1: Client의 SYN

Client가 Server에 SYN 전송
Client의 ISN 포함

Step 2: Server의 SYN-ACK

Server가 SYN acknowledgment 반환
Server의 ISN 포함
Client의 ISN + 1을 ACK

Step 3: Client의 ACK

Client가 Server의 SYN-ACK를 확인
Server의 ISN + 1을 ACK

각 호스트는 상대방에게 자신의 ISN을 알려줌
양방향 통신을 위해 각자의 ISN 필요
이 패킷을 받으면 데이터 전송 시작 가능

SYN Packet이 손실되면?

문제:

Server가 패킷을 버림 (예: listen queue가 가득 참)
결국 SYN-ACK가 도착하지 않음

해결책:

Sender가 타이머를 설정하고 SYN-ACK를 대기
필요시 SYN 재전송
RFC 1122 & 2988: 기본 3초 사용 권장
다른 구현체: 6초 사용

TEARING DOWN THE CONNECTION

TCP Connection Termination

📚Connection Termination: 각 데이터 흐름의 끝은 독립적으로 종료되어야 함 (“half-close”)

4단계 프로세스:

X가 Y에게 FIN 전송 (active close)
Y가 FIN을 ACK
- 이 시점: Y는 여전히 X에게 데이터 전송 가능
Y가 X에게 FIN 전송 (passive close)
X가 FIN을 ACK

Normal Termination

A                               B
│                               │
│         FIN                   │
├──────────────────────────────►│
│                               │
│         ACK                   │
◄──────────────────────────────┤
│                               │
│                               │ Connection
│                               │ now half-closed
│         FIN                   │
◄──────────────────────────────┤
│                               │
│         ACK                   │
├──────────────────────────────►│
│                               │
│  Timeout: Avoid reincarnation │
│           ↓                   │
│     Connection                │
│     now closed                │

Sending/Receiving the FIN Packet

FIN 전송: close()

프로세스가 소켓을 통한 데이터 전송 완료
프로세스가 “close()”를 호출하여 소켓 닫기
TCP가 모든 미완료 바이트 전송 후 FIN 전송
바이트가 아직 ACK되지 않았어도 FIN 전송
FIN의 seqno가 모든 바이트를 넘어서므로
모든 바이트가 전달될 때까지 ACK되지 않음

FIN 수신: EOF

프로세스가 소켓에서 데이터 읽는 중
결국 읽기 시도가 EOF 반환
송신자가 close() 호출하기 전의 모든 바이트 전달됨

Abrupt Termination

RST (Reset) 사용:

A가 B에게 RST 전송
프로세스 크래시 등의 이유
B는 RST를 ACK하지 않음
RST는 신뢰성 있게 전달되지 않음
전송 중인 데이터는 손실됨
B가 더 보내면 또 다른 RST 발생

TCP Options

📚TCP Options: TCP 헤더의 가변 길이 옵션 필드 (최대 40 bytes, 4 bytes 배수)

주요 옵션 종류

Kind	Option	Length (Byte)
0	End of Option List (EOL)	1≥
1	No Operation (NOP)	1
2	Maximum Segment Size (MSS)	4
3	Window scaling factor	3
4	Selective ACK Permitted	2
5	Selective ACK	2+8k (k < 5)
8	Timestamp	10
28	User timeout	4

옵션 설명:

EOL: 뒤로 더 이상 옵션 없음
NOP: padding 역할
MSS: peer에게 payload 크기 알림 (MSS = MTU - 40)
WSF: 수신 socket buffer > 64KB일 때 peer에게 알려줌
- window size (16 bits) < 65,535 KB
SACK permit: SACK 사용 가능 알림
Timestamp: RTT 측정
UTO: 최대 ACK 기다리는 시간

SACK (Selective Acknowledgment)

📚SACK: TCP 세그먼트 한 번에 여러 개 보낼 때 중간에 잃어버린 것만 알려줌 (SLE, SRE)

장점:

TCP 성능 향상
불필요한 재전송 감소

동작:

Continuous data reception │ #49 │ Gap │ #51 │
                          ↓           ↓
                     ACK = 25733  ACK = 25733

중간 패킷 수신 후:
Continuous received bytes │ #49 │ #53 │ #54 │ #51 │
                                      ↓
                                 ACK = 28699

FLOW CONTROL

📚Flow Control: 송신자가 수신자를 정보로 압도하는 것을 방지하는 알고리즘

TCP Sliding Window Flow Control

특징:

Acknowledgment 전송과 window size 설정이 분리됨
Acknowledgment가 자동으로 window size를 증가시키지 않음
Acknowledgment는 누적적(cumulative)

Sliding Window Protocol

        Advertised window
    ◄─────────────────────►
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ 9 │10 │11 │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
        ◄───┐   ◄───────┐       ◄───────┐
    sent and│   sent but│   can │  can't│
acknowledged│    not    │  be   │  sent │
            │acknowledged│ sent  │       │
            └───────────►        │       │
               USABLE WINDOW     │       │

Window Operations

1. Window Closes (윈도우 닫힘)

데이터 전송 후 ACK 수신
전송된 만큼 윈도우가 왼쪽으로 이동

2. Window Opens (윈도우 열림)

ACK 수신으로 윈도우가 오른쪽으로 확장
수신자의 TCP 버퍼가 비워질 때 발생

3. Window Shrinks (윈도우 축소)

윈도우가 오른쪽에서 축소
사용하지 않아야 함

Window Management

수신자는 송신자에게 두 파라미터 반환:

┌─────────────┬────────────────┐
│   AckNo     │ window size    │
│  (32 bits)  │    (16 bits)   │
└─────────────┴────────────────┘

해석:

SeqNo = AckNo, AckNo+1, …, AckNo+Win-1의 새 데이터를 받을 준비가 됨

특징:

수신자는 윈도우를 열지 않고 데이터 확인 가능
수신자는 데이터 확인 없이 윈도우 크기 변경 가능

Flow Control Example

Sender                          Receiver Buffer
sends 2K                        0           4K
of data     ┌─────────┐         ┌─────────────┐
            │2K│SeqNo=0│         │             │
            └────┼─────┘         └─────────────┘
                 └────────────►  ┌────┬────────┐
                                 │ 2K │        │
                 ◄──────────────┐└────┴────────┘
            ┌────────────────┐  │
            │AckNo=2048      │  │
            │Win=2048        │  │
            └────────────────┘  │

Sender      ┌─────────┐         │
sends 2K    │2K│SeqNo=2048│     │
of data     └────┼─────┘         │
                 └────────────►  ┌──────────┐
                                 │   4K     │
                 ◄──────────────┐└──────────┘
            ┌────────────────┐  │
            │AckNo=4096      │  │
            │Win=0           │  │
            └────────────────┘  │
                                │
Sender blocked                  │
                                │
                 ◄──────────────┤ ┌───┬────┐
            ┌────────────────┐  │ │   │ 3K │
            │AckNo=4096      │  │ └───┴────┘
            │Win=1024        │  │
            └────────────────┘  │

Advertised Window

📚Advertised Window: W: 다음 기대 바이트를 넘어 W 바이트를 보낼 수 있음

Flow Control 메커니즘:

수신자는 W를 사용하여 송신자의 버퍼 오버플로우 방지
윈도우가 W이면 송신자는 최대 W/RTT bytes/sec로 전송 가능
수신자는 암묵적으로 송신자를 수신 가능한 속도로 제한
송신자가 너무 빠르면 윈도우 광고가 점점 작아짐

RELIABILITY: RETRANSMISSION

Reasons for Retransmission

Timeout         Timeout         Timeout
   │               │               │
Packet    ACK   Packet    ACK   Packet
  │  ┌╳┐   │      │   ┌╳┐   │      │    ┌───┐
  │  └─┘   │      │   └─┘   │      │ ┌╳┐│ACK│
  └────►   │      └────►     │      │ └─┘└───┘
      ◄────┘          ◄──────┘      └────►  │
                                        ◄────┘◄────┐
  Packet lost     ACK lost        Early timeout  │
                  DUPLICATE       DUPLICATE PACKETS│
                  PACKET                           │

How Long Should Sender Wait?

Timeout 설정:

너무 짧음: 불필요한 재전송
너무 김: 패킷 손실 시 과도한 지연

TCP의 RTO (Retransmission Timeout):

RTT의 함수로 설정
ACK가 데이터 전송 후 대략 RTT 후에 도착 예상
변동(queuing, MAC)을 허용하는 슬랙 추가

측정 문제
RTT를 어떻게 측정할 것인가?
RTT의 좋은 추정치는?
“슬랙”의 좋은 추정치는?

Problem: Ambiguous Measurement

재전송 시 문제:

Sender          Receiver        Sender          Receiver
  │ Original      │                │ Original      │
  │ Transmission  │                │ Transmission  │
  ├──────────────►│                ├──────────────►│
  │               │                │      ACK      │
  │Retransmission │                │  ◄─────┐      │
  ├──────────────►│                │Retransmission │
  │      ACK      │                ├──────────────►│
  ◄───────────────┤                │               │
  ↕               │                ↕               │
SampleRTT ?                      SampleRTT ?

실제 ACK와 재전송된 패킷의 ACK를 어떻게 구분?

Karn/Partridge Algorithm

📚Karn/Partridge Algorithm: 재전송 시 RTT 측정 문제 해결

규칙:

원본 전송에 대해서만 SampleRTT 측정
세그먼트가 재전송되면 추가 측정에 사용하지 않음

Exponential Backoff 적용:

RTO 타이머 만료 시마다: RTO ← 2·RTO
새 측정 도착 시 (성공적인 원본 전송): RTO를 계산된 값으로 복원

RTT Estimation

Exponential Averaging

SampleRTT = AckRcvdTime - SendPacketTime
EstimatedRTT = α × EstimatedRTT + (1-α) × SampleRTT

α = 7/8 (for one measurement per flight)

그래프:

EstimatedRTT ▲
              │     ╱╲
              │    ╱  ╲  ╱╲
              │   ╱    ╲╱  ╲
              │──────────────── EstimatedRTT
              │ ╱│  ╱│   │╲  │╲
              │╱ │ ╱ │   │ ╲ │ ╲
              └──┴──┴───┴──┴──┴──► Time
                SampleRTT

Jacobson/Karels Algorithm

📚Jacobson/Karels Algorithm: 관찰된 변동성 측면에서 “슬랙” 계산

표준 편차 대신 평균 편차 사용:

표준 편차는 비싼 제곱근 필요
평균 편차(mean deviation) 사용

Deviation = | SampleRTT – EstimatedRTT |
EstimatedDeviation: Deviation의 지수 평균

EstRTT = (1-α) × EstRTT + α × SRTT
RTTvar = (1-β) × RTTvar + β × (SRTT - EstRTT)
RTO = ERTT + 4 × RTTvar

α와 β 값
α = 1/8 (0.125)
β = 1/4 (0.25)
RTO는 EstimatedRTT + 4배의 변동성

Alternative to Timeouts: Fast Retransmission

Triple Duplicate ACK

📚Fast Retransmission: 3개의 중복 ACK 수신 시 즉시 재전송

동작 원리:

패킷 n이 손실되지만 n+1, n+2, … 도착
순서에 맞지 않는 패킷 도착 시마다 수신자가 ACK 생성
n+1, n+2, … 도착 시 시퀀스 번호 n에 대한 반복 ACK 생성
모두 동일하게 보이므로 “duplicate” acknowledgments
송신자가 3개를 보면 즉시 패킷 n 재전송 (n만)

Fast Retransmission Diagram

Sender                          Receiver
  │      segment 1              │
  ├──────────────────────────►  │
  │                             │
  │◄──────ACK 2                 │
  │                             │
  │      segment 2              │
  ├──────────────────────────►  │
  │      segment 3              │
  ├──────────────────────────►  │
  │                             │
  │◄──────ACK 3                 │
  │                             │
  │◄──────ACK 4                 │
  │                             │
  │      segment 4 ──╳          │ segment 5 lost
  │      segment 5              │
  ├──────────────────────────►  │
  │      segment 6              │
  ├──────────────────────────►  │
  │      segment 7              │
  ├──────────────────────────►  │
  │                             │
  │◄──────ACK 4  ┐              │
  │◄──────ACK 4  │ 3 duplicate  │
  │◄──────ACK 4  ┘    ACKs      │
  │                             │
  │      segment 4              │
  ├──────────────────────────►  │ Fast Retransmit!

주의사항:

ACK는 다음 기대 패킷에 대한 것
패킷 재정렬(reordering)이 중복 ACK 유발 가능
윈도우가 너무 작으면 충분한 중복 ACK 생성 불가능

Additional TCP Features

Cumulative ACK

📚Cumulative ACK (Accumulated ACK): TCP ACK는 누적적으로 동작

특징:

ACK 번호는 “이 번호 이전까지 모두 수신했음”을 의미
중간에 패킷이 손실되어도 연속으로 수신된 부분까지 ACK
손실된 패킷 이후에 도착한 패킷들은 동일한 ACK 번호 반복

예시:

Continuous received bytes │ #49 │ Loss │ #51 │
                          ↓           ↓
                     ACK = 25733  ACK = 25733

손실 패킷 재전송 후:
Continuous received bytes │ #49 │ #53 │ #54 │ #51 │
                                      ↓
                                 ACK = 28699

Delayed ACK

📚Delayed ACK: TCP는 기본적으로 ACK suppress (performance 향상)

목적:

Full duplex (반대방향) 활용
데이터와 함께 ACK 전송 가능

동작:

Delayed ACK timer expire 시 ACK 전송
두 개의 세그먼트마다 하나의 ACK
최대 지연: 보통 200ms

Persist Timer

📚Persist Timer: Window size = 0 상황 처리

문제:

RX로부터 0-ACK (Window size = 0) 받으면 TX 더 이상 전송 불가
RX가 window update 할 때까지 TX freeze
Window update (ACK) 손실 시 deadlock

해결책:

RX가 0-ACK 수신 시 persist timer 시작 (RTO)
Timer expires, RX가 persist probe 전송 (1 byte)
1. 0-ACK 다시 전송 + 동일 ACK#
2. 0-ACK 다시 전송 + ACK 1증가
3. ACK (window size > 0) 전송

Keepalive Timer

📚Keepalive Timer: Half-open 상태 탐지

목적:

Half-open (client 조용히 다운된 경우) 상태를 탐지하여 connection 끊기
Server overhead 감소

동작:

TCP 표준은 아님
약 2시간 후 timeout
Keepalive probe: inadequate seq# (예: 이미 ACK 받은 것)
살아 있는 client의 경우 바른 ACK# packet 전송
Closed client 무응답 → probe 3-5번 뒤 연결 해지

TCP 요약

TCP의 핵심 특징

1. 연결 지향 (Connection-Oriented)

Three-way handshake로 연결 수립
Full duplex 양방향 통신
명시적 연결 종료 (FIN)

2. 신뢰성 보장 (Reliable Delivery)

Sequence number로 순서 보장
Acknowledgment로 수신 확인
Timeout & Retransmission
Fast Retransmit (3 duplicate ACKs)

3. 흐름 제어 (Flow Control)

Sliding window mechanism
Advertised window로 수신 버퍼 관리
수신자가 처리 가능한 속도로 전송

4. 혼잡 제어 (Congestion Control)

Network 상태에 맞춰 전송 속도 조절
Good performance 목표

TCP vs UDP

특징	TCP	UDP
연결	Connection-oriented	Connectionless
신뢰성	Reliable delivery	Unreliable
순서	In-order delivery	No ordering
흐름 제어	Yes	No
오버헤드	높음 (20+ bytes)	낮음 (8 bytes)
속도	느림	빠름
사용 예	HTTP, FTP, Email	DNS, VoIP, Streaming

TCP 사용이 적합한 경우
데이터 손실이 허용되지 않는 경우
순서가 중요한 경우
신뢰성 있는 전송이 필요한 경우
UDP 사용이 적합한 경우
실시간 전송이 중요한 경우
약간의 손실이 허용되는 경우
낮은 지연이 필요한 경우

References:

RFC 793: Transmission Control Protocol
RFC 1122: Requirements for Internet Hosts
RFC 2988: Computing TCP’s Retransmission Timer
Prof. Jongwon Yoon, Intelligent Machines Lab.

CS, Internet Protocol

This post is licensed under CC BY 4.0 by the author.

TCP Service Model

Network의 Challenge

TCP의 핵심 기능

TCP Support for Reliable Delivery

신뢰성 보장 메커니즘

Connection-Oriented

TCP Header

Header 구조

주요 필드

ACKing and Sequence Numbers

ACK 메커니즘

Initial Sequence Number (ISN)

왜 ISN = 0이 아닌가?

CONNECTION ESTABLISHMENT: THREE-WAY HANDSHAKE

3-Way Handshake 과정

SYN Packet이 손실되면?

TEARING DOWN THE CONNECTION

TCP Connection Termination

Normal Termination

Sending/Receiving the FIN Packet

Abrupt Termination

TCP Options

주요 옵션 종류

SACK (Selective Acknowledgment)

FLOW CONTROL

TCP Sliding Window Flow Control

Sliding Window Protocol

Window Operations

Window Management

Flow Control Example

Advertised Window

RELIABILITY: RETRANSMISSION

Reasons for Retransmission

How Long Should Sender Wait?

Problem: Ambiguous Measurement

Karn/Partridge Algorithm

RTT Estimation

Exponential Averaging

Jacobson/Karels Algorithm

Alternative to Timeouts: Fast Retransmission

Triple Duplicate ACK

Fast Retransmission Diagram

Additional TCP Features

Cumulative ACK

Delayed ACK

Persist Timer

Keepalive Timer

TCP 요약

TCP의 핵심 특징

TCP vs UDP

Trending Tags