Skip to content
Published on

[컴퓨터 네트워크] 08. 전송 계층: 다중화/역다중화와 UDP

Authors

본 포스팅은 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를 사용하는 애플리케이션

애플리케이션프로토콜이유
DNSUDP단순 질의-응답, 빠른 응답 필요
SNMPUDP네트워크 관리, 간단한 요청
스트리밍 미디어UDP/TCP약간의 손실 허용, 실시간성 중요
인터넷 전화UDP실시간성이 신뢰성보다 중요
온라인 게임UDP낮은 지연이 필수

3.3 UDP 세그먼트 구조

┌──────────────────┬──────────────────┐
│  출발지 포트 (16)  │  목적지 포트 (16)  │
├──────────────────┼──────────────────┤
│   길이 (16)       │  체크섬 (16)      │
├──────────────────┴──────────────────┤
│                                      │
│        애플리케이션 데이터 (페이로드)    │
│                                      │
└──────────────────────────────────────┘

헤더 크기: 8 bytes (4개 필드 x 2 bytes)
필드크기설명
출발지 포트16 bits송신 프로세스의 포트
목적지 포트16 bits수신 프로세스의 포트
길이16 bitsUDP 세그먼트 전체 길이 (헤더 + 데이터)
체크섬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. 확인 문제

Q1. UDP 역다중화와 TCP 역다중화의 핵심 차이는?
  • UDP: 목적지 IP와 목적지 포트만으로 소켓을 식별한다 (2-튜플). 따라서 출발지가 다른 두 데이터그램도 같은 목적지 포트를 가지면 같은 소켓으로 전달된다.
  • TCP: 출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트 모두를 사용하여 소켓을 식별한다 (4-튜플). 출발지가 다른 세그먼트는 다른 소켓으로 전달된다.
Q2. UDP 체크섬의 계산 원리와 한계는?

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

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

Q3. DNS가 TCP 대신 UDP를 사용하는 이유는?

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