[🌐CN] UDP - User Datagram Protocol

Posted Oct 6, 2025 Updated Oct 6, 2025

By xmoonanx

25 min read

🌐 Internet Protocol 전공 수업 정리

IP 계층의 Best Effort 서비스 위에 Transport Layer가 등장한다. UDP는 가장 단순한 전송 계층 프로토콜로, IP에 Multiplexing/Demultiplexing 기능만 추가한다. 단순함 속에 숨겨진 강력한 활용 사례와 설계 철학을 살펴보자.

Transport Layer 개요

TCP/IP 계층 구조에서의 위치

📚Transport Layer: Network Layer(IP) 위에서 동작하며 애플리케이션 간 데이터 전송을 담당하는 계층

프로토콜 스택:

┌─────────────────────────────────────────┐
│      Application Layer                  │
│  Telnet  FTP  HTTP  DHCP  DNS  Ping     │
└─────────────────────────────────────────┘
              ↕
┌─────────────────────────────────────────┐
│      Transport Layer                    │  ◄─ 여기!
│         TCP          UDP                │
└─────────────────────────────────────────┘
              ↕
┌─────────────────────────────────────────┐
│      Network Layer                      │
│    IP      ICMP      IGMP               │
└─────────────────────────────────────────┘
              ↕
┌─────────────────────────────────────────┐
│      Link Layer                         │
│  ARP  Hardware Interface  RARP          │
└─────────────────────────────────────────┘
              ↕
            Media

End-to-End Principle

📚End-to-End Principle: 기능 배치의 원칙 - 애플리케이션별 기능은 통신의 양 끝단(end nodes)에만 구현

핵심 철학:

                HOST                                HOST
┌───────────────────────┐            ┌───────────────────────┐
│     Application       │◄··········►│     Application       │
├───────────────────────┤            ├───────────────────────┤
│     Transport         │◄··········►│     Transport         │
├───────────────────────┤            ├───────────────────────┤
│      Network          │◄─────┐     │      Network          │
├───────────────────────┤      │     ├───────────────────────┤
│     Data Link         │◄──┐  │  ┌─►│     Data Link         │
└───────────────────────┘   │  │  │  └───────────────────────┘
                            │  │  │
                    ┌───────▼──▼──▼───────┐
                    │   Intermediate      │
                    │     Routers         │
                    │  (Network + Link)   │
                    └─────────────────────┘

설계 원칙:

✅ Application-specific features: 통신하는 End nodes에만 구현
✅ Intermediate routers: 네트워크 구성만 담당 (Dumb minimal networks)
✅ Smart terminals: 모든 지능은 양 끝단에
✅ Performance enhancement: 호스트가 올바르게 구현할 수 있다면, 하위 계층에는 성능 향상 목적으로만 구현
❌ No burden: 해당 기능이 필요 없는 애플리케이션에 부담을 주지 않음

철학의 핵심: “기능을 필요로 하지 않는 애플리케이션에 부담을 주지 마라!”

Transport Protocols: UDP vs TCP

인터넷의 2가지 Transport Protocol

비교표:

┌─────────────────────────────────────┬─────────────────────────────────┐
│              UDP                    │             TCP                 │
│   User Datagram Protocol            │ Transmission Control Protocol   │
├─────────────────────────────────────┼─────────────────────────────────┤
│ ✅ Datagram oriented                │ ✅ Stream oriented              │
│ ❌ Unreliable, Connectionless      │ ✅ Reliable, Connection-oriented│
│ ✅ Simple                           │ ❌ Complex                      │
│ ✅ Unicast and Multicast            │ ❌ Only Unicast                 │
└─────────────────────────────────────┴─────────────────────────────────┘

UDP의 특징 및 용도

UDP 특징:

Datagram oriented: 각 메시지가 독립적
Unreliable: 손실, 중복, 순서 바뀜 가능
Connectionless: 연결 설정 없음
Simple: 최소한의 오버헤드
Multicast 지원: 1:N 통신 가능

UDP 주요 사용처:

3가지 주요 용도:
Non-unicast (Multicast/Broadcast)
Real-time (실시간 통신)
Short transactions (짧은 트랜잭션)

분류	애플리케이션	이유
서비스	DNS, DHCP, SNMP, RIP	짧은 요청/응답
멀티미디어	VoIP, 화상회의, IPTV, 게임	실시간성 중요, 지연 최소화
멀티캐스트	Router discovery, Multicast video	1:N 통신

TCP의 특징 및 용도

TCP 특징:

Stream oriented: 연속된 바이트 스트림
Reliable: 순서 보장, 손실 복구
Connection-oriented: 3-way handshake
Complex: 흐름 제어, 혼잡 제어
Unicast only: 1:1 통신만 가능

TCP 주요 사용처:

애플리케이션	포트	특징
HTTP	80	웹 브라우징
SMTP	25	이메일 전송
FTP	21	파일 전송
Telnet	23	원격 터미널

UDP의 역할

UDP가 제공하는 것

📚UDP의 핵심 기능: IP의 host-to-host delivery를 application-to-application delivery로 확장

UDP가 추가하는 유일한 기능:

                Applications               Applications
                   ○ ○ ○                      ○ ○ ○
                   │ │ │                      │ │ │
                ┌──▼─▼─▼───┐                ┌─▼─▼─▼──┐
                │   UDP    │                │  UDP   │
                └────┬─────┘                └────┬───┘
                     │                           │
                ┌────▼─────┐                ┌────▼───┐
                │    IP    │ ──────────────►│   IP   │
                └──────────┘                └────────┘

핵심 기능: Multiplexing & Demultiplexing

UDP = IP + Multiplexing/Demultiplexing

Multiplexing (송신 측): 여러 애플리케이션의 데이터를 IP로 전달
Demultiplexing (수신 측): IP 패킷을 올바른 애플리케이션으로 전달

UDP가 제공하지 않는 것:

❌ 신뢰성 (Reliability)
❌ 순서 보장 (Ordering)
❌ 흐름 제어 (Flow Control)
❌ 혼잡 제어 (Congestion Control)
❌ 연결 관리 (Connection Management)

Unreliable transmission: UDP는 datagram의 전송만 제공하며, 낮은 오버헤드를 유지한다!

UDP Header 구조

UDP 패킷 구성

┌──────────┬────────────┬──────────────────────────┐
│IP header │ UDP header │      UDP data            │
│(20 bytes)│  (8 bytes) │      (variable)          │
└──────────┴────────────┴──────────────────────────┘

UDP Header 포맷

 0      7 8     15 16    23 24                    31
├────────┴────────┼────────┴──────────────────────────┤
│ Source Port     │   Destination Port Number        │
│   Number        │         (16 bits)                │
│  (16 bits)      │                                  │
├─────────────────┼──────────────────────────────────┤
│ UDP Message     │       Checksum                   │
│   Length        │       (16 bits)                  │
│  (16 bits)      │                                  │
├─────────────────┴──────────────────────────────────┤
│                                                    │
│                  DATA                              │
│                                                    │
└────────────────────────────────────────────────────┘

필드 설명:

필드	크기	설명
Source Port Number	16 bits	송신 애플리케이션 식별
Destination Port Number	16 bits	수신 애플리케이션 식별
UDP Message Length	16 bits	UDP 헤더 + 데이터 전체 길이
Checksum	16 bits	오류 검출 (IPv4에서는 선택, IPv6에서 필수)

헤더 필드 상세

Port Numbers (각 16 bits):

송신/수신 애플리케이션(프로세스) 식별
프로세스를 찾기 위해 필수
ICMP 에러가 발생한 IP datagram의 처음 부분을 포함하여 전달
연결(association)을 찾을 수 없으면 → ICMP Port Unreachable 에러 반환

UDP Message Length:

최소: 8 bytes (헤더만, 데이터 필드 비어있을 수 있음)
최대: 65,535 bytes (2^16 - 1)
UDP 헤더 + UDP 데이터 포함

Checksum:

UDP 헤더와 UDP 데이터 전체를 검증
IPv4: 선택 사항 (0이면 사용 안 함)
IPv6: 필수 사항
계산 방법: One’s complement arithmetic

Port Numbers

Port Number의 역할

📚Port Number: Transport Layer에서 애플리케이션(프로세스)을 식별하는 16비트 번호

전역 고유 주소:

Transport Layer의 글로벌 주소 = <IP address, Port number>

예시:
  192.168.1.100:80  → 웹 서버
  192.168.1.100:53  → DNS 서버
  (같은 IP, 다른 포트 → 다른 애플리케이션)

범위:

각 호스트당 65,535개 UDP 포트 (2^16 - 1)
TCP와 UDP는 독립적인 포트 공간 사용

Multiplexing & Demultiplexing

Demultiplexing 과정:

                    User Processes
             ┌───┬───┬───┬───┬───┬───┐
             │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │
             └─▲─┴─▲─┴─▲─┴───┴─▲─┴─▲─┘
               │   │   │       │   │
               │   │   │       │   │
        ┌──────┴───┴───┴───────┴───┴──────┐
        │         Demultiplex              │
        │      based on Port Number        │
        │                                  │
        │      TCP            UDP          │
        └──────────────┬───────────────────┘
                       │
        ┌──────────────▼───────────────────┐
        │         Demultiplex              │
        │   based on Protocol Field        │
        │          in IP Header            │
        │                                  │
        │             IP                   │
        └──────────────────────────────────┘

2단계 Demultiplexing:

IP Layer: Protocol field로 TCP/UDP 구분
Transport Layer: Port number로 프로세스 구분

Port Number 관리 체계

📚IANA (Internet Assigned Numbers Authority): 포트 번호를 관리하는 글로벌 기관

포트 번호 범위:

Range	Category	설명
1 - 1023	Well-known	잘 알려진 서비스 (root 권한 필요)
1024 - 4915	Registered	등록된 애플리케이션
49152 - 65535	Private/Dynamic	임시 포트 (클라이언트가 동적으로 사용)

Well-known Ports 예시:

Port	Service	프로토콜	설명
20	FTP-DATA	TCP	FTP 데이터
21	FTP	TCP	FTP 제어
22	SSH	TCP	Secure Shell
23	Telnet	TCP	원격 터미널
25	SMTP	TCP	메일 전송
53	DNS	UDP	도메인 이름 서버
67	DHCP	UDP	DHCP 서버
68	DHCP	UDP	DHCP 클라이언트
80	HTTP	TCP	웹 서버
161	SNMP	UDP	네트워크 관리
443	HTTPS	TCP	보안 웹 서버

Traceroute와 UDP

Linux Traceroute의 동작:

Linux traceroute는 UDP를 사용!

동작 과정:
1. TTL=1부터 시작하여 UDP 패킷 전송
2. Private port number 사용 (33434+)
3. 중간 라우터에서 TTL=0 → ICMP Time Exceeded 응답
4. 목적지 도달 시 → 해당 포트에 프로세스 없음
   → ICMP Destination Unreachable (Port Unreachable) 응답 ✅

이를 통해 목적지 도달을 확인!

예시:

  
$ traceroute www.example.com
...
12  * * *
13  203.0.113.1 (203.0.113.1)  50.123 ms
    → ICMP: Port Unreachable (목적지 도달!)

Port Number와 프로세스 선택

전송 과정:

┌─────────────────────────────────────────┐
│           Host: 193.14.26.7             │
│  ┌───┐  ┌───┐  ┌───┐                    │
│  │ 📄 │  │ 📄 │  │...│  Processes        │
│  └─▲─┘  └─▲─┘  └───┘                    │
│    │      │                              │
│    │      │     Port number              │
│  ┌─┴──────┴──┐  selects the              │
│  │    13     │  process                  │
│  └─────┬─────┘                           │
│        │                                 │
│  ┌─────▼──────────────────┐              │
│  │   UDP header           │              │
│  │ ┌─────────┬──────────┐ │              │
│  │ │Src Port │Dest Port │ │              │
│  │ │         │    13    │ │              │
│  │ └─────────┴──────────┘ │              │
│  └────────────────────────┘              │
│                                          │
│  ┌────────────────────────┐              │
│  │    IP header           │              │
│  │ ┌──────────────────┐   │              │
│  │ │ 193.14.26.7      │   │  IP address  │
│  │ │                  │   │  selects     │
│  │ └──────────────────┘   │  the host    │
│  └────────────────────────┘              │
└─────────────────────────────────────────┘

주소 해석 순서:

IP address: 어느 호스트인가? → 193.14.26.7
Port number: 어느 프로세스인가? → 13번 포트

UDP Checksum

Checksum 계산 과정

📚UDP Checksum: UDP 헤더와 데이터의 무결성을 검증하기 위한 16비트 값

계산 절차:

Pseudo-header 추가
Checksum 필드를 0으로 채움
16-bit words로 분할 (필요시 padding 추가)
One's complement arithmetic으로 모든 words 더하기
결과를 complement하여 checksum 필드에 저장
Pseudo-header와 padding 제거
UDP segment를 IP로 전달

Pseudo-header 구조

왜 Pseudo-header?

Pseudo-header는 IP 헤더의 일부 정보를 포함하여
UDP가 올바른 호스트에 전달되었는지 검증!

Pseudo-header 포맷:

 0      7 8     15 16    23 24                    31
├────────┴────────┴────────┴──────────────────────────┤
│          32-bit Source IP Address                  │
├────────────────────────────────────────────────────┤
│       32-bit Destination IP Address                │
├────────────────┬────────────────┬──────────────────┤
│   All 0s       │  8-bit Protocol│ 16-bit UDP       │
│   (padding)    │     (17)       │  Total Length    │
└────────────────┴────────────────┴──────────────────┘
                        ↓
┌────────────────────────────────────────────────────┐
│         Source Port     │    Destination Port      │
├─────────────────────────┼──────────────────────────┤
│      UDP Total Length   │       Checksum           │
├────────────────────────────────────────────────────┤
│                     Data                           │
│  (Padding must be added to make data multiple      │
│   of 16 bits)                                      │
└────────────────────────────────────────────────────┘

Pseudo-header 필드:

필드	크기	값
Source IP Address	32 bits	IP 헤더에서
Destination IP Address	32 bits	IP 헤더에서
Zero padding	8 bits	0x00
Protocol	8 bits	17 (UDP)
UDP Total Length	16 bits	UDP 헤더에서

Checksum 계산 예시

예제: 간단한 UDP datagram

Pseudo-header:
  153.18.8.105    → 10011001 00010010 00001000 01101001
  171.2.14.10     → 10101011 00000010 00001110 00001010
  All 0s | 17 | 15 → 00000000 00010001 00000000 00001111

UDP Header:
  1087 (port)     → 00000100 00111111
  13 (port)       → 00000000 00001101
  15 (length)     → 00000000 00001111
  Checksum        → 00000000 00000000 (계산 전)

Data:
  T E S T         → 01010100 01000101 01010011 01010100
  I N G           → 01001001 01001110 01000111 00000000 (padding)

계산:
  10011001 00010010  (153.18)
+ 00001000 01101001  (8.105)
+ 10101011 00000010  (171.2)
+ 00001110 00001010  (14.10)
+ 00000000 00010001  (0 and 17)
+ 00000000 00001111  (15)
+ 00000100 00111111  (1087)
+ 00000000 00001101  (13)
+ 00000000 00001111  (15)
+ 00000000 00000000  (0 - checksum)
+ 01010100 01000101  (T and E)
+ 01010011 01010100  (S and T)
+ 01001001 01001110  (I and N)
+ 01000111 00000000  (G and 0 - padding)
───────────────────
  10010110 11101011  → Sum

One's Complement:
  01101001 00010100  → Checksum!

Checksum 검증 (수신 측)

수신 측 절차:

1. Pseudo-header를 UDP segment에 추가
2. 필요시 padding 추가
3. 16-bit words로 분할
4. One's complement arithmetic으로 모두 더하기
5. 결과를 complement

6. 결과가 all 0's이면:
   - Pseudo-header와 padding 제거
   - Segment 수락 ✅
   그렇지 않으면:
   - Segment 폐기 ❌

Pseudo-header의 목적

역사적 배경 (David P. Reed, 2005):

“TCP (and UDP) are end-to-end protocols. In particular, the TCP checksum is ‘end-to-end’. It is a ‘private matter’ between end points implementing the TCP layer, guaranteeing end-to-end reliability, not hop-by-hop reliability.”

핵심 이유:

1. Source/Destination Address는 의미 있는 정보
   → IP와 TCP/UDP 양쪽에서 사용
   → 중복 저장보다는 "virtual header" (pseudo-header) 사용

2. End-to-end 암호화 보호
   → SA, DA 등을 checksum에 포함하여
   → Man-in-the-middle 공격 방어
   → SA와 DA는 의미 있으므로 IP가 변경하면 안 됨

3. NAT의 문제
   → NAT가 end-to-end 암호화를 방해
   → Middlebox의 등장으로 원래 설계 훼손

Pseudo-header의 의미: IP 헤더 정보를 checksum에 포함시켜 패킷이 올바른 호스트에 전달되었는지 검증!

Encapsulation & Decapsulation

송신 과정 (Encapsulation)

Process (Application)
    │
    │ Message
    ▼
┌───────────────────────────────┐
│  Message from process         │
└───────────────────────────────┘
    │
    │ Add UDP header
    ▼
┌──────────┬────────────────────┐
│   UDP    │     UDP data       │
│  header  │                    │
└──────────┴────────────────────┘
    │
    │ Add IP header
    ▼
┌──────────┬────────────────────┐
│    IP    │      IP data       │
│  header  │  (UDP segment)     │
└──────────┴────────────────────┘
    │
    │ Add Frame header
    ▼
┌──────────┬────────────────────┐
│  Frame   │    Frame data      │
│  header  │   (IP datagram)    │
└──────────┴────────────────────┘
    │
    ▼
   Network

수신 과정 (Decapsulation)

   Network
    │
    ▼
┌──────────┬────────────────────┐
│  Frame   │    Frame data      │
│  header  │                    │
└──────────┴────────────────────┘
    │
    │ Remove Frame header
    ▼
┌──────────┬────────────────────┐
│    IP    │      IP data       │
│  header  │                    │
└──────────┴────────────────────┘
    │
    │ Remove IP header
    ▼
┌──────────┬────────────────────┐
│   UDP    │     UDP data       │
│  header  │                    │
└──────────┴────────────────────┘
    │
    │ Remove UDP header
    ▼
┌───────────────────────────────┐
│  Message to process           │
└───────────────────────────────┘
    │
    ▼
Process (Application)

계층별 처리:

계층	송신 (Encapsulation)	수신 (Decapsulation)
Application	Message 생성	Message 수신
Transport	UDP header 추가	UDP header 제거, Port 확인
Network	IP header 추가	IP header 제거, IP 확인
Link	Frame header 추가	Frame header 제거

UDP의 장단점

UDP의 장점

✅ 1. 낮은 오버헤드

TCP header: 최소 20 bytes
UDP header: 고정 8 bytes
→ 대역폭 효율적!

✅ 2. 낮은 지연 (Low Latency)

TCP: 연결 설정 (3-way handshake) 필요
UDP: 즉시 데이터 전송 가능
→ 실시간 애플리케이션에 유리!

✅ 3. Multicast/Broadcast 지원

TCP: 1:1 통신만 가능
UDP: 1:N 통신 가능
→ IPTV, 화상회의, 라우터 discovery 등

✅ 4. 단순성

연결 상태 관리 불필요
흐름 제어, 혼잡 제어 없음
→ 구현 및 디버깅 용이

UDP의 단점

❌ 1. 신뢰성 없음

패킷 손실 가능
중복 가능
순서 뒤바뀜 가능
→ 애플리케이션 레벨에서 처리 필요

❌ 2. 혼잡 제어 없음

네트워크 상태 고려 안 함
과도한 트래픽 발생 가능
→ 네트워크 혼잡 악화 가능

❌ 3. 순서 보장 없음

먼저 보낸 패킷이 나중에 도착 가능
애플리케이션이 직접 재정렬 필요

UDP 사용 사례 분석

1. DNS (Domain Name System)

왜 UDP?

특징:
  - 짧은 요청/응답 (Query/Response)
  - 보통 512 bytes 이하
  - 빠른 응답이 중요

동작:
  Client ──(Query: www.example.com)──► DNS Server
  Client ◄─(Response: 93.184.216.34)── DNS Server

장점:
  ✅ TCP의 3-way handshake 오버헤드 없음
  ✅ 단일 UDP datagram으로 완료
  ✅ 응답 없으면 재전송 (애플리케이션 레벨)

단, 512 bytes 초과 시 → TCP로 전환!

2. DHCP (Dynamic Host Configuration Protocol)

왜 UDP?

특징:
  - 클라이언트는 아직 IP 주소가 없음!
  - Broadcast 사용 필요
  - 짧은 트랜잭션

동작:
  Client (0.0.0.0) ──(DHCP Discover - Broadcast)──► Server
  Client          ◄─(DHCP Offer)──────────────────── Server
  Client          ──(DHCP Request)───────────────►   Server
  Client          ◄─(DHCP ACK)────────────────────   Server

장점:
  ✅ Broadcast 가능 (TCP는 불가능)
  ✅ IP 주소 없이도 통신 가능
  ✅ 빠른 주소 할당

3. Real-time 애플리케이션 (VoIP, 화상회의)

왜 UDP?

특징:
  - 지연 > 신뢰성
  - 오래된 데이터는 무용지물
  - 실시간성이 핵심

예시: VoIP (Voice over IP)
  - 200ms 이상 지연 → 대화 불가능
  - 1-2% 패킷 손실 → 사람 귀로 구별 어려움
  - 재전송된 오래된 음성 데이터 → 쓸모없음

TCP 문제:
  ❌ 재전송으로 인한 지연 증가
  ❌ Head-of-line blocking
  ❌ 혼잡 제어로 인한 처리량 감소

UDP 장점:
  ✅ 최소 지연
  ✅ 손실된 데이터는 그냥 무시
  ✅ 일정한 전송 속도 유지

4. SNMP (Simple Network Management Protocol)

왜 UDP?

특징:
  - 네트워크 관리 및 모니터링
  - 주기적인 polling
  - 간단한 요청/응답

장점:
  ✅ 네트워크 문제 발생 시에도 동작
     (TCP는 연결 설정 자체가 실패할 수 있음)
  ✅ 경량 프로토콜
  ✅ 많은 장비를 빠르게 polling

5. Multicast 애플리케이션

왜 UDP?

특징:
  - 1:N 통신
  - 동일 데이터를 여러 수신자에게

예시:
  - IPTV
  - 실시간 주식 정보
  - 멀티캐스트 비디오 스트리밍
  - 라우터 discovery

TCP 불가능:
  ❌ TCP는 unicast만 지원
  ❌ 각 수신자마다 별도 연결 필요
  ❌ 확장성 문제

UDP 장점:
  ✅ 자연스러운 multicast 지원
  ✅ 단일 패킷으로 모든 수신자에게 전달

UDP vs TCP 선택 기준

선택 가이드

UDP를 사용해야 하는 경우:

✅ 실시간성이 중요한 경우 (VoIP, 게임, 화상회의)
✅ Multicast/Broadcast가 필요한 경우
✅ 짧은 트랜잭션 (DNS, DHCP)
✅ 손실을 감내할 수 있는 경우
✅ 애플리케이션 레벨에서 신뢰성 구현 가능한 경우
✅ 최소 오버헤드가 필요한 경우

TCP를 사용해야 하는 경우:

✅ 데이터 무결성이 중요한 경우 (파일 전송, 이메일)
✅ 순서가 중요한 경우
✅ 신뢰성 있는 전송이 필수인 경우 (HTTP, FTP)
✅ 대량의 데이터 전송
✅ 흐름 제어와 혼잡 제어가 필요한 경우

비교표:

특성	UDP 적합	TCP 적합
실시간성	✅ VoIP	❌
파일 전송	❌	✅ FTP
멀티캐스트	✅ IPTV	❌
짧은 쿼리	✅ DNS	❌
스트리밍	✅ (지연)	✅ (품질)
게임	✅	❌
웹 브라우징	❌	✅ HTTP
이메일	❌	✅ SMTP

정리

UDP의 핵심 특징

특징	설명
Unreliable	손실, 중복, 순서 바뀜 가능
Connectionless	연결 설정 없이 즉시 전송
Datagram	각 메시지 독립적으로 처리
Simple	최소 오버헤드 (8 byte header)
Fast	낮은 지연, 실시간 통신에 유리
Multicast	1:N 통신 지원

UDP Header 요약

필드	크기	역할
Src Port	16 bits	송신 애플리케이션 식별
Dst Port	16 bits	수신 애플리케이션 식별
Length	16 bits	전체 길이 (8~65535)
Checksum	16 bits	무결성 검증

Port Number 범위

범위	분류	용도
1-1023	Well-known	표준 서비스
1024-49151	Registered	등록된 애플리케이션
49152-65535	Private/Dynamic	임시 포트

UDP의 철학: “단순함이 강력함이다.” - 최소한의 기능만 제공하고, 필요한 기능은 애플리케이션이 구현!

UDP의 핵심 가치:

✅ IP + Multiplexing/Demultiplexing
✅ Low overhead, Low latency
✅ Multicast support
❌ No reliability, No flow control
✅ Perfect for real-time, short transactions, multicast

References

RFC 768 (User Datagram Protocol)
RFC 1122 (Requirements for Internet Hosts)
Prof. Jongwon Yoon, Intelligent Machines Lab
David P. Reed, “Purpose of pseudo header in TCP checksum”, 2005

CS, Internet Protocol

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

Transport Layer 개요

TCP/IP 계층 구조에서의 위치

End-to-End Principle

Transport Protocols: UDP vs TCP

인터넷의 2가지 Transport Protocol

UDP의 특징 및 용도

TCP의 특징 및 용도

UDP의 역할

UDP가 제공하는 것

UDP Header 구조

UDP 패킷 구성

UDP Header 포맷

헤더 필드 상세

Port Numbers

Port Number의 역할

Multiplexing & Demultiplexing

Port Number 관리 체계

Traceroute와 UDP

Port Number와 프로세스 선택

UDP Checksum

Checksum 계산 과정

Pseudo-header 구조

Checksum 계산 예시

Checksum 검증 (수신 측)

Pseudo-header의 목적

Encapsulation & Decapsulation

송신 과정 (Encapsulation)

수신 과정 (Decapsulation)

UDP의 장단점

UDP의 장점

UDP의 단점

UDP 사용 사례 분석

1. DNS (Domain Name System)

2. DHCP (Dynamic Host Configuration Protocol)

3. Real-time 애플리케이션 (VoIP, 화상회의)

4. SNMP (Simple Network Management Protocol)

5. Multicast 애플리케이션

UDP vs TCP 선택 기준

선택 가이드

정리

UDP의 핵심 특징

UDP Header 요약

Port Number 범위

References

Trending Tags