본 포스팅은 James Kurose, Keith Ross의 Computer Networking: A Top-Down Approach (6th Edition) 교재를 기반으로 정리한 내용입니다.

1. 전송 계층 서비스

1.1 전송 계층의 역할

전송 계층은 서로 다른 호스트에서 실행되는 **프로세스** 간의 논리적 통신을 제공한다.

네트워크 계층: 호스트 간 (host-to-host) 통신

전송 계층: 프로세스 간 (process-to-process) 통신

┌────────┐ ┌────────┐

│ App P1 │ │ App P3 │

│ App P2 │ │ App P4 │

├────────┤ ├────────┤

│ 전송 │ ←── 논리적 통신 ──→ │ 전송 │

├────────┤ ├────────┤

│ 네트워크│ ←── 논리적 통신 ──→ │ 네트워크│

└────────┘ └────────┘

호스트 A 호스트 B

1.2 전송 계층과 네트워크 계층의 관계

비유: 집 대 집 우편 시스템

집(호스트) A 집(호스트) B

Ann (프로세스) Bob (프로세스)

Bill (프로세스) Carol (프로세스)

전송 계층 = 집에서 편지를 분류해 주는 사람

(어떤 가족 구성원에게 전달할지 결정)

네트워크 계층 = 우체국

(집 A에서 집 B로 편지를 배달)

> 전송 계층은 네트워크 계층이 제공하지 않는 서비스를 자체적으로 추가할 수 있다. 예를 들어, 비신뢰적인 IP 위에 신뢰적인 TCP를 구현한다.

1.3 인터넷 전송 계층의 두 프로토콜

TCP (Transmission Control Protocol):

├── 연결 지향 (3-way handshake)

├── 신뢰적 데이터 전송

├── 흐름 제어 (수신자 보호)

├── 혼잡 제어 (네트워크 보호)

└── 순서 보장

UDP (User Datagram Protocol):

├── 비연결

├── 비신뢰적 (최선 노력 전달)

├── 흐름/혼잡 제어 없음

└── 순서 보장 없음

2. 다중화와 역다중화 (Multiplexing / Demultiplexing)

2.1 개념

하나의 호스트에서 여러 프로세스가 동시에 네트워크를 사용한다. 전송 계층은 이를 관리해야 한다.

다중화 (Multiplexing):

송신 측에서 여러 소켓의 데이터를 수집하여

전송 계층 헤더를 붙여 네트워크 계층으로 전달

역다중화 (Demultiplexing):

수신 측에서 전송 계층 세그먼트를 받아

올바른 소켓(프로세스)으로 전달

역다중화 동작:

네트워크 계층에서 세그먼트 수신

│

↓

전송 계층: 세그먼트 헤더의 포트 번호 확인

│

├──→ 포트 80 → 웹 서버 프로세스

├──→ 포트 25 → 메일 서버 프로세스

└──→ 포트 53 → DNS 서버 프로세스

2.2 포트 번호

전송 계층이 프로세스를 식별하는 데 사용하는 16비트 숫자다.

포트 번호 범위: 0 ~ 65535

0 ~ 1023: 잘 알려진 포트 (Well-Known Ports)

HTTP(80), HTTPS(443), DNS(53), SMTP(25)

1024 ~ 49151: 등록 포트 (Registered Ports)

49152 ~ 65535: 동적/임시 포트 (Dynamic/Ephemeral Ports)

클라이언트가 자동 할당받아 사용

2.3 세그먼트 헤더의 포트 번호 필드

전송 계층 세그먼트:

┌──────────────┬──────────────┐

│ 출발지 포트 │ 목적지 포트 │ ← 각 16 bits

├──────────────┴──────────────┤

│ 기타 헤더 필드 │

├─────────────────────────────┤

│ 애플리케이션 데이터 │

└─────────────────────────────┘

2.4 비연결 역다중화 (UDP)

UDP 소켓은 **(목적지 IP, 목적지 포트)** 의 2-튜플로 식별된다.

서버: IP=10.0.0.1, 포트=46428

클라이언트 A (IP=10.0.0.2, 출발지 포트=9157)

→ 목적지: 10.0.0.1:46428

클라이언트 B (IP=10.0.0.3, 출발지 포트=9157)

→ 목적지: 10.0.0.1:46428

두 데이터그램 모두 같은 소켓으로 전달됨!

(출발지 IP가 달라도 목적지 포트가 같으므로)

2.5 연결 지향 역다중화 (TCP)

TCP 소켓은 **(출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트)** 의 4-튜플로 식별된다.

서버: IP=10.0.0.1, 포트=80

클라이언트 A (IP=10.0.0.2, 출발지 포트=9157)

→ 4-튜플: (10.0.0.2, 9157, 10.0.0.1, 80)

→ 전용 연결 소켓 1

클라이언트 B (IP=10.0.0.3, 출발지 포트=9157)

→ 4-튜플: (10.0.0.3, 9157, 10.0.0.1, 80)

→ 전용 연결 소켓 2

같은 출발지 포트라도 IP가 다르면 다른 소켓!

TCP 서버의 소켓 구조:

환영 소켓 (포트 80)

│

├── 연결 소켓 1: (10.0.0.2:9157, 10.0.0.1:80)

├── 연결 소켓 2: (10.0.0.3:9157, 10.0.0.1:80)

└── 연결 소켓 3: (10.0.0.2:5775, 10.0.0.1:80)

각 연결이 고유한 4-튜플로 구분됨

3. UDP (User Datagram Protocol)

3.1 UDP의 특징

UDP는 전송 계층이 할 수 있는 **최소한의 일**만 수행한다.

UDP가 하는 것:

✓ 다중화/역다중화 (포트 번호)

✓ 간단한 오류 검출 (체크섬)

UDP가 하지 않는 것:

✗ 연결 설정

✗ 신뢰적 전달

✗ 흐름 제어

✗ 혼잡 제어

✗ 순서 보장

3.2 왜 UDP를 사용하는가

UDP의 장점:

1. 연결 설정 없음 → 지연 감소 (DNS가 UDP 사용하는 이유)

2. 연결 상태 없음 → 더 많은 클라이언트 지원 가능

3. 작은 헤더 오버헤드 → 효율적 (UDP: 8 bytes, TCP: 20 bytes)

4. 전송률 제한 없음 → 애플리케이션이 원하는 속도로 전송

UDP를 사용하는 애플리케이션

| 애플리케이션 | 프로토콜 | 이유 |

| --------------- | -------- | ------------------------------- |

| DNS | UDP | 단순 질의-응답, 빠른 응답 필요 |

| SNMP | UDP | 네트워크 관리, 간단한 요청 |

| 스트리밍 미디어 | UDP/TCP | 약간의 손실 허용, 실시간성 중요 |

| 인터넷 전화 | UDP | 실시간성이 신뢰성보다 중요 |

| 온라인 게임 | UDP | 낮은 지연이 필수 |

3.3 UDP 세그먼트 구조

┌──────────────────┬──────────────────┐

│ 출발지 포트 (16) │ 목적지 포트 (16) │

├──────────────────┼──────────────────┤

│ 길이 (16) │ 체크섬 (16) │

├──────────────────┴──────────────────┤

│ │

│ 애플리케이션 데이터 (페이로드) │

│ │

└──────────────────────────────────────┘

헤더 크기: 8 bytes (4개 필드 x 2 bytes)

| 필드 | 크기 | 설명 |

| ----------- | ------- | -------------------------------------- |

| 출발지 포트 | 16 bits | 송신 프로세스의 포트 |

| 목적지 포트 | 16 bits | 수신 프로세스의 포트 |

| 길이 | 16 bits | UDP 세그먼트 전체 길이 (헤더 + 데이터) |

| 체크섬 | 16 bits | 오류 검출용 |

4. UDP 체크섬 (Checksum)

4.1 목적

세그먼트가 전송 중에 변경(비트 오류)되었는지 검출한다.

4.2 계산 방법

세그먼트의 모든 16비트 워드를 더하고, 1의 보수를 취한다.

예시: 3개의 16비트 워드

0110 0110 0110 0000

0101 0101 0101 0101

1000 1111 0000 1100

단계 1: 처음 두 워드 더하기

0110 0110 0110 0000

+ 0101 0101 0101 0101

─────────────────────

1011 1011 1011 0101

단계 2: 결과에 세 번째 워드 더하기

1011 1011 1011 0101

+ 1000 1111 0000 1100

─────────────────────

0100 1010 1100 0001 (올림 발생 시 wraparound)

단계 3: 1의 보수 취하기

0100 1010 1100 0001

→ 1011 0101 0011 1110 ← 이것이 체크섬

4.3 오류 검출 과정

송신 측:

1. 체크섬 필드를 0으로 설정

2. 세그먼트의 모든 16비트 워드를 더함

3. 1의 보수를 취해 체크섬 필드에 저장

수신 측:

1. 세그먼트의 모든 16비트 워드를 더함 (체크섬 포함)

2. 결과가 모두 1이면 → 오류 없음 (높은 확률)

3. 하나라도 0이 있으면 → 오류 발생!

검증 예시 (오류 없는 경우):

데이터 워드들의 합 + 체크섬 = 1111 1111 1111 1111

→ 모든 비트가 1 → 정상

검증 예시 (오류 있는 경우):

비트 오류로 인해 합이 1111 1011 1111 1111

→ 0이 포함됨 → 오류 검출!

4.4 체크섬의 한계

체크섬의 한계:

1. 오류 검출은 가능하지만 오류 정정(correction)은 불가

2. 일부 오류를 놓칠 수 있음 (예: 두 비트가 상보적으로 변경)

3. UDP는 오류를 검출해도 아무 조치를 취하지 않음

- 손상된 세그먼트를 버리거나 경고와 함께 애플리케이션에 전달

> UDP가 체크섬을 제공하는 이유: 모든 링크 계층 프로토콜이 오류 검출을 제공하는 것이 아니며, 메모리 내에서 비트 오류가 발생할 수도 있기 때문이다. **종단 간 원칙(end-to-end principle)** 에 따라 전송 계층에서도 오류 검출을 수행한다.

5. UDP에서의 신뢰적 전송

UDP 자체는 신뢰적 전송을 제공하지 않지만, **애플리케이션 계층**에서 신뢰성을 구현할 수 있다.

애플리케이션 수준 신뢰성 구현:

├── 확인 응답(ACK) 메커니즘

├── 재전송 타이머

└── 시퀀스 번호

예시: QUIC 프로토콜 (HTTP/3에서 사용)

- UDP 위에 신뢰적 전송 구현

- TCP보다 빠른 연결 설정

- 멀티플렉싱 지원

6. 정리

전송 계층 요약:

다중화/역다중화:

├── UDP: (목적지 IP, 목적지 포트) 2-튜플로 소켓 식별

└── TCP: (출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트) 4-튜플

UDP:

├── 비연결, 비신뢰적

├── 8바이트 헤더 (출발지포트, 목적지포트, 길이, 체크섬)

├── 체크섬으로 오류 검출

└── 실시간 애플리케이션에 적합

7. 확인 문제

- **UDP**: 목적지 IP와 목적지 포트만으로 소켓을 식별한다 (2-튜플). 따라서 출발지가 다른 두 데이터그램도 같은 목적지 포트를 가지면 같은 소켓으로 전달된다.

- **TCP**: 출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트 모두를 사용하여 소켓을 식별한다 (4-튜플). 출발지가 다른 세그먼트는 다른 소켓으로 전달된다.

**계산 원리**: 세그먼트의 모든 16비트 워드를 더한 후 1의 보수를 취한다. 수신 측에서 체크섬을 포함한 모든 워드를 더했을 때 결과가 모두 1이면 오류가 없는 것으로 판단한다.

**한계**: 두 비트가 동시에 상보적으로 오류가 나면(한 비트는 0에서 1로, 다른 비트는 1에서 0으로) 검출하지 못할 수 있다. 또한 오류를 검출해도 정정(correction)은 불가하다.

DNS 질의는 대부분 하나의 요청과 하나의 응답으로 이루어지는 짧은 트랜잭션이다. TCP의 3-way handshake 연결 설정은 실제 데이터보다 더 많은 오버헤드를 발생시킨다. UDP를 사용하면 연결 설정 없이 바로 질의를 보내고 응답을 받을 수 있어 **지연이 크게 줄어든다**. 응답이 없으면 애플리케이션이 재전송하면 된다.