PDU(Protocol Data Unit, 프로토콜 데이터 단위)

PDU(Protocol Data Unit, 프로토콜 데이터 단위)

PDU(Protocol Data Unit) 는 네트워크 통신에서 각 프로토콜 계층이 다루는 데이터 블록을 의미하며, 계층별로 서로 다른 명칭과 헤더 구조를 가진다.

OSI 참조 모델 (7 계층) 과 TCP/IP 모델 (4 계층) 은 모두 PDU 를 통해 계층 간 역할 분리와 독립성을 구현한다.
물리 계층 (Layer 1) 에서는 비트 (Bit) 스트림으로 표현되고,
데이터링크 계층 (Layer 2) 에서는 프레임 (Frame) 에 MAC 주소와 FCS 를 포함하며,
네트워크 계층 (Layer 3) 에서는 패킷 (Packet) 에 IP 주소를 담고,
전송 계층 (Layer 4) 에서는 세그먼트 (Segment, TCP) 또는 데이터그램 (Datagram, UDP) 에 포트 번호를 명시한다.
상위 계층 (5~7 계층) 은 통칭 데이터 (Data) 또는 메시지로 불린다.

각 계층은 상위 계층 PDU 를 페이로드로 받아들이고 고유 헤더를 추가하는 캡슐화 (Encapsulation) 를 수행하며, 수신 측은 역캡슐화 (Decapsulation) 를 통해 원본 데이터를 복원한다.

PDU 구조 이해는 패킷 분석, 방화벽 규칙 설정, QoS(Quality of Service) 정책, MTU(Maximum Transmission Unit) 최적화 등 실무 네트워크 운영의 핵심이다. 또한 SDN(Software-Defined Networking), NFV(Network Functions Virtualization) 환경에서 계층별 헤더 조작과 트래픽 제어를 위한 기초 지식으로 작용한다.

기본 개념과 배경

PDU 의 정의와 특징, 등장 배경, 해결하려는 문제, 흔한 오해, 핵심 용어 정합을 다룬다. 네트워크 계층 모델의 근간이 되는 개념을 명확히 이해하는 것이 목표다.

정의 (Definition)

PDU(Protocol Data Unit) 는 네트워크 프로토콜 스택의 각 계층에서 처리·전송하는 데이터 블록을 의미한다.
보통 헤더(제어정보) + 페이로드(SDU) 구조를 가지며 각 계층의 동작 규칙에 따라 다르게 이름을 가지며 네트워크 프로토콜 효율화에 중요한 역할을 한다.

OSI 참조 모델과 TCP/IP 모델에서 각 계층은 고유한 PDU 이름과 헤더·트레일러 구조를 정의하며, 이를 통해 계층 간 역할 분리와 독립적 프로토콜 설계를 구현한다.
예를 들어, TCP 세그먼트는 전송 계층 PDU 로, IP 패킷은 네트워크 계층 PDU 로, 이더넷 프레임은 데이터링크 계층 PDU 로 지칭된다.

특징 (Characteristics)

PDU 는 각 계층마다 별도의 명칭 (예: Bit, Frame, Packet, Segment 등) 을 가지며, 계층별 프로토콜에 따라 구조와 필드 구성이 달라진다. 캡슐화 과정을 거치며 이전 계층의 데이터 (SDU) 를 포함하고, 송수신 동작의 독립성을 유지한다.

• 계층별 고유 명칭: 물리 (비트), 데이터링크 (프레임), 네트워크 (패킷), 전송 (세그먼트/데이터그램), 상위 (데이터/메시지) 로 구분된다.
• 헤더·트레일러 구조: 각 계층은 상위 PDU 를 페이로드로 받아 자신의 제어 정보 (헤더, 선택적 트레일러) 를 추가한다.
• 캡슐화·역캡슐화: 송신 측은 상위→하위 순으로 헤더를 추가 (캡슐화), 수신 측은 하위→상위 순으로 헤더를 제거 (역캡슐화) 한다.
• 독립성과 투명성: 각 계층은 상·하위 계층의 내부 구현을 알 필요 없이 PDU 인터페이스만 준수하면 된다.
• 실무 도구 연계: 패킷 분석기 (Wireshark, tcpdump), 방화벽 (iptables, ACL), 로드밸런서가 PDU 헤더를 기반으로 동작한다.

PDU 의 12 가지 구조적 특징

PDU 의 12 가지 특징은

1. **구조/명명
2. 크기/경로 제약
3. 신뢰/품질 제어
4. 운영/가시성·성능
   의 4 가지 차원으로 묶인다. 이는 상호 의존적이다.
   구조/옵션 결정이 곧바로 크기/경로 제약에 반영되고, 여기서의 실패는 신뢰/품질의 재전송·지연을 키운다. 암호화·오프로딩은 관찰성을 바꾸므로, 캡처 위치와 텔레메트리를 ’ 이중화 ’ 하는 것이 빠른 트러블슈팅의 핵심이다.

실무에서는 이 4 가지 차원을 동시에 점검해야 헤더 예산·손실/지연·보안·관찰성이 균형을 이룬다.
핵심은 “헤더가 쌓이면 MTU 는 줄고, 그 결과 분할/단편화·재전송이 증가하며, 암호화/오프로딩/터널은 분석 난이도를 높인다 " 는 연쇄 효과를 이해하는 것이다.

구조/명명

• 계층 종속 명명—같은 " 데이터 덩어리 " 라도 관찰 지점에 따라 이름과 의미가 달라진다. 스위치 포트 미러는 L2 Frame을, 라우터/방화벽은 L3 Packet을, 호스트의 소켓 계층은 L4 Segment/Datagram을 본다. 명칭 혼동은 문제 위치 추적을 어렵게 하므로, 증상 보고·캡처·로그를 모두 동일 계층 기준으로 맞추는 것이 중요하다.
• 헤더 구조 (고정 + 옵션/확장)—IPv4 IHL, TCP Options, IPv6 Extension Header, 802.1Q VLAN 처럼 고정 필드 + 가변 옵션 조합이다. 옵션은 확장성과 유연성을 주지만, 오버헤드 증가·미들박스 호환성·슬로패스 전환 위험이 따른다. 운영선에서는 필요 옵션만 최소화하고, 중간장비 호환성 목록을 유지한다.
• 주소/식별/흐름 라벨—MAC/IP/Port 의 전통적 5- 튜플 외에도 IPv6 Flow Label, QUIC Connection ID(CID), VLAN ID, SPI(IPsec) 등 식별자가 있다. 해시 기반 로드밸런싱/ECMP 는 이들 필드를 키로 사용해 흐름을 분산한다. NAT/터널이 개입하면 키 구성이 바뀌므로, 트래픽 핑거프린팅과 경로 일관성을 재검증해야 한다.

크기/경로 제약

• 길이 제약 (MTU/MSS/최소 프레임)—MTU 는 상위 모든 PDU 크기에 상한을 건다. 이더넷 최소 프레임 (패딩 포함) 과 무선 MAC 오버헤드, 터널/보안 헤더가 결합되면 유효 페이로드가 급감한다. MSS 는 TCP 협상 시 안전한 상한을 제공하지만, 실제 경로 MTU 와 불일치하면 재전송·블랙홀이 발생한다.
• 단편화 정책 차이 (IPv4/IPv6)—IPv4 는 중간 라우터 단편화가 가능 (DF=0), IPv6 는 송신자만 단편화 가능하다. 단편화는 손실/지연·CPU 비용을 증가시키므로 회피가 원칙이다. 운영에서는 PMTUD/PLPMTUD 로 크기를 조정하고, 방화벽에서 조각 (Fragments) 처리를 신중히 설계한다.
• PMTUD/PLPMTUD—ICMP 신호에 의존하는 전통 PMTUD(IPv4 Frag Needed, IPv6 PTB) 는 필터링되면 실패한다. PLPMTUD 는 실제 데이터/프로브로 안전 크기를 탐색해 블랙홀을 줄인다. 경로가 자주 바뀌는 모바일/클라우드 환경에서 특히 중요하다.
• 터널/오버레이 중첩—VLAN/QinQ/VXLAN/GRE/IPsec/GTP-U 는 새로운 헤더를 추가해 경계 밖의 L2/L3 를 가상화한다. 중첩 깊이가 증가하면 헤더 예산이 급격히 줄어 PMTUD 실패·단편화·성능 저하로 이어진다. 터널 종단에서 MTU 조정·MSS 클램핑·외부 단편화 방지 설정을 함께 적용한다.

신뢰/품질 제어

• 오류 검출/복구—L2 FCS(CRC)·IPv4 헤더 체크섬·L4 체크섬·TLS/QUIC 의 AEAD 가 계층별로 무결성을 보장한다. 검출 범위와 비용이 달라 중복도 존재한다 (예: IPv6 은 라우터 성능을 위해 헤더 체크섬 제거). 체크섬/암호 검증 실패는 즉시 드롭되므로, 관찰 지표 (드롭 카운터, ICV 오류) 를 병행 모니터링해야 한다.
• 순서/신뢰 의미—TCP 는 순서/재전송/흐름·혼잡제어를 제공해 바이트 스트림을 보장한다. UDP 는 비연결/무보장으로 지연 예측 가능성이 높고, QUIC 은 UDP 위에 스트림 단위 신뢰·복구를 제공해 HOL(Head-of-Line) 문제를 줄인다. 응용의 메시지 경계 보존 요구에 따라 적절한 전송을 선택해야 한다.
• 혼잡/우선 신호 (ECN/DSCP)—ECN 의 ECT/CE 비트로 드롭 없이 혼잡 신호를 전달하고, DSCP/Traffic Class 로 클래스 기반 큐잉을 수행한다. ECN 이 비활성/표백 (bleach) 되는 경로에서는 이득이 제한되며, AQM(RED/CoDel/FQ-CoDel) 과의 조합에서 효과가 크다. 마킹/정책 일관성을 엔드·경계 장비에서 교차 검증한다.

운영/가시성·성능

• 오프로딩 (TSO/GSO/GRO 등)—호스트는 큰 PDU 를 NIC 가 분할/병합하도록 위임하여 PPS/CPU 비용을 낮춘다. 이때 호스트 로컬 캡처에선 큰 가상 세그먼트로 보일 수 있어 온와이어 현실과 불일치한다. 분석은 미러 포트/경계 장비 캡처와 교차하고, ethtool/드라이버 카운터로 상태를 확인한다.
• 보안과 가시성의 상호작용—TLS 1.3/QUIC 은 메타데이터까지 광범위하게 암호화하여 DPI/미들박스 의존 진단을 어렵게 한다. 대신 엔드포인트 텔레메트리 (연결 통계, 실패 코드) 와 패시브 지표 (QUIC 스핀 비트 등, 배포 정책에 따라) 로 관찰성을 보완한다. 암호화 태그/레코드로 헤더 오버헤드가 늘어나 MTU 예산을 소모한다.

PDU 의 12 가지 구조적 특징 (요약)

등장 배경 (Background)

계층화된 네트워크 모델 (OSI, TCP/IP) 은 시스템 간 통신을 표준화하고, 확장성과 신뢰성을 높이기 위해 개발되었다. 각 계층의 PDU 는 이러한 설계 원칙에 따라 독립적으로 정의되며, 계층 간 인터페이스 및 프로토콜 동작을 명확하게 한다.

• 1970 년대 초기 네트워크는 단일 프로토콜 (예: ARPANET NCP) 로 구성되어 확장성과 상호운용성에 한계가 있었다.
• 1974 년 Vint Cerf 와 Bob Kahn 의 TCP/IP 설계
• 1984 년 ISO 의 OSI 참조 모델 표준화를 통해 계층화된 프로토콜 스택 개념이 정립되었다.

각 계층이 독립적으로 PDU 를 정의함으로써, 하드웨어·소프트웨어 변경 시에도 상·하위 계층에 영향을 최소화하고, 이기종 네트워크 간 상호운용성을 확보할 수 있게 되었다.
이후 이더넷 (IEEE 802.3), Wi-Fi(IEEE 802.11), MPLS, VXLAN 등 다양한 프로토콜이 PDU 구조를 기반으로 발전했다.

해결하려는 문제 (Problem)

PDU 개념은 데이터 통신에서 계층 간 정보 전송의 불명확성, 데이터 포장 과정의 오류, 프로토콜 혼동 문제를 해결하고, 계층마다 일관된 데이터 단위 관리와 에러 검출/복구를 가능하게 한다.

Before PDU 개념 도입:

• 단일 프로토콜로 모든 기능 (주소 지정, 라우팅, 오류 제어, 흐름 제어) 을 처리 → 복잡도 증가, 변경 어려움
• 이기종 네트워크 연결 시 전체 프로토콜 재설계 필요
• 네트워크 문제 발생 시 원인 계층 파악 곤란

After PDU 개념 도입:

• 각 계층이 명확한 PDU 와 인터페이스를 정의 → 역할 분리, 모듈화
• 새로운 프로토콜 추가·교체 시 해당 계층만 수정 → 유연성 향상
• 계층별 PDU 헤더 분석으로 문제 원인 계층 신속 식별 → 트러블슈팅 효율화
• 방화벽·QoS·SDN 등 네트워크 제어 정책을 계층별 헤더 기반으로 구현 가능

흔한 오해 (Misconceptions)

오해 1: PDU 는 모든 계층에서 ’ 패킷 ’ 으로 부른다

오해: 데이터 전송 단위를 모두 ’ 패킷 ’ 으로 지칭한다
원인: 네트워크 용어의 일반화/간소화
반례: 전송 계층은 ’ 세그먼트 ‘(TCP), 네트워크 계층 (Layer 3) 은 ’ 패킷 ‘, 프레임 (Layer 2), 세그먼트 (Layer 4) 이라 불린다
올바른 개념: PDU 는 각 계층별 데이터 단위의 총칭이고, 패킷은 그 중 네트워크 계층 (IP) PDU 를 가리킨다.

오해 2: PDU 는 원래 데이터와 별개로 존재한다

오해: PDU 와 원래 데이터가 별도의 단위로 간주된다
원인: 헤더와 페이로드 구분 개념의 오해
반례: PDU 는 항상 각각의 계층 데이터 (=SDU) 와 해당 계층 제어정보가 결합된 전체 메시지이다
올바른 개념: PDU = 상위 계층 데이터 (SDU) + 현재 계층 제어정보

오해 3: 헤더만 추가하면 PDU 가 된다

오해: 헤더만 있으면 PDU 구조가 완성된다고 이해
원인: 캡슐화 개념 학습 시 헤더 추가에만 집중
반례: 데이터링크 계층 (예: 이더넷) 은 헤더뿐 아니라 트레일러 (FCS, Frame Check Sequence) 도 추가하며, 일부 프로토콜은 페이로드 패딩도 포함
올바른 개념: PDU 는 헤더 + 페이로드 + (선택적) 트레일러로 구성되며, 계층별로 트레일러 유무와 패딩 규칙이 다르다.

오해 4: 상위 계층 PDU 는 하위 계층과 무관하다

오해: 각 계층 PDU 는 완전히 독립적이므로 상호 영향이 없다
원인: 계층 독립성 원칙을 절대적으로 해석
반례: MTU(Maximum Transmission Unit) 제약, IP 단편화 (Fragmentation), TCP MSS(Maximum Segment Size) 조정 등 하위 계층의 물리적 제약이 상위 계층 PDU 크기에 직접 영향을 미침
올바른 개념: 계층 간 독립성은 인터페이스 수준의 추상화이며, 성능·효율성 측면에서는 상·하위 계층 간 PDU 크기 협상과 최적화가 필수다.

핵심 개념 정의·용어 정합

PDU(Protocol Data Unit), SDU(Service Data Unit) 는 계층화 모델에서 각각 ’ 동일 계층 간 송수신 단위 ’ 와 ’ 인접 계층간 전달 단위 ’ 로 정의된다.
각 계층의 PDU 명칭, 구조, 역할을 명확히 구분해야 하며, 용어 혼동을 방지하는 것이 중요하다.

사전 지식 (Prerequisites):

• OSI 7 계층 모델, TCP/IP 4 계층 모델
• 네트워크 주소 체계 (MAC, IP, Port)
• 기본 네트워킹 용어 (라우팅, 스위칭, 패킷 교환)

핵심 용어:

• Encapsulation(캡슐화): 상위 계층 PDU 를 페이로드로 받아 헤더·트레일러를 추가하는 과정
• Decapsulation(역캡슐화): 수신 측에서 하위→상위 순으로 헤더·트레일러를 제거하여 원본 데이터 복원
• Header(헤더): PDU 앞부분에 추가되는 제어 정보 (주소, 순서 번호, 플래그 등)
• Trailer(트레일러): PDU 뒷부분에 추가되는 제어 정보 (예: FCS, CRC)
• Payload(페이로드): 상위 계층 PDU 또는 실제 사용자 데이터
• MTU(Maximum Transmission Unit): 네트워크 계층이 데이터링크 계층으로 전달할 수 있는 최대 패킷 크기
• MSS(Maximum Segment Size): TCP 세그먼트의 최대 페이로드 크기

계층별 PDU 구조 및 명칭

OSI 7 계층과 TCP/IP 모델의 각 계층별 PDU 명칭, 헤더 구조, 주요 필드를 상세히 다룬다. 실무에서 가장 많이 사용되는 이더넷 프레임, IP 패킷, TCP 세그먼트를 중심으로 설명한다.

OSI 7 계층 PDU 매핑

• 하위 3 계층 (1~3) 은 네트워크 인프라 계층으로, 주소 지정과 라우팅을 담당하며 PDU 명칭이 명확히 구분된다.
• 전송 계층 (4) 은 종단 간 연결 제어를 담당하며, TCP 는 세그먼트, UDP 는 데이터그램으로 구분된다.
• 상위 3 계층 (5~7) 은 OSI 모델에서는 각각 정의되지만, TCP/IP 모델에서는 응용 계층으로 통합되어 " 데이터 " 또는 " 메시지 " 로 통칭된다.

flowchart TD
    application-layer["application-layer(Data)"]
    transport-layer["transport-layer(Segment/Datagram)"]
    network-layer["network-layer(Packet)"]
    datalink-layer["datalink-layer(Frame)"]
    physical-layer["physical-layer(Bit)"]

    application-layer --> transport-layer
    transport-layer --> network-layer
    network-layer --> datalink-layer
    datalink-layer --> physical-layer

<OSI 7 계층에서의 PDU 흐름>
상위 계층 데이터가 하위 계층으로 내려갈 때, 각 계층에서 헤더가 추가되어 계층별로 새로운 PDU 가 생성된다.
실제 송신시에는 physical 계층의 신호 (Bit) 로 변환된다.

TCP/IP 모델 PDU 매핑

TCP/IP 프로토콜 스택 구성과 각 계층 PDU 의 특징, 구조를 병렬 비교한다.

<TCP/IP 모델 계층별 PDU 비교>
TCP/IP 스택에서는 OSI 에 비해 계층 수가 적지만, 각 계층의 PDU 명칭과 실제 동작 방식은 OSI 와 거의 동일하다. 또한 네트워크 장비나 툴에서 각 PDU 명칭을 올바르게 사용하는 것이 중요하다.

graph TD
    A[응용 계층<br>Application Layer] -->|데이터/메시지<br>Data/Message| B[전송 계층<br>Transport Layer]
    B -->|세그먼트Segment or 데이터그램Datagram| C[인터넷 계층<br>Internet Layer]
    C -->|패킷Packet| D[네트워크 접근 계층<br>Network Access Layer]
    D -->|프레임Frame| E[물리 매체<br>Physical Medium]
    E -->|비트Bit| F[네트워크 전송]
    
    style A fill:#e1f5ff
    style B fill:#fff4e1
    style C fill:#ffe1f5
    style D fill:#e1ffe1
    style E fill:#f5e1ff

TCP/IP 4 계층 모델은 OSI 모델을 단순화하여, 응용 (57 계층 통합), 전송 (4 계층), 인터넷 (3 계층), 네트워크 접근 (12 계층 통합) 으로 구성된다.
각 계층은 상위 PDU 를 페이로드로 받아 자신의 헤더를 추가하며, 최하위 네트워크 접근 계층에서 프레임으로 캡슐화된 후 비트 스트림으로 전송된다. 이 도식은 실무에서 가장 많이 사용되는 모델로, 인터넷 프로토콜 스택의 핵심 구조를 나타낸다.

이더넷 프레임 구조 (Layer 2 PDU)

코드 예시: Python 으로 이더넷 프레임 파싱

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

import struct

def parse_ethernet_frame(frame_bytes):
    """
    이더넷 프레임을 파싱하여 주요 필드 추출
    
    입력: frame_bytes (bytes) - 이더넷 프레임 바이트 스트림
    출력: dict - 파싱된 필드 딕셔너리
    """
    # 최소 길이 검증 (Preamble·SFD 제외 시 64바이트)
    if len(frame_bytes) < 64:
        raise ValueError("Invalid frame length")
    
    # Preamble·SFD는 물리 계층에서 제거되므로 보통 Wireshark 등에서는 보이지 않음
    # 여기서는 Destination MAC부터 시작한다고 가정
    dst_mac = frame_bytes[0:6].hex(':')
    src_mac = frame_bytes[6:12].hex(':')
    eth_type = struct.unpack('!H', frame_bytes[12:14])[0]  # Big-endian 2바이트
    payload = frame_bytes[14:-4]  # FCS 4바이트 제외
    fcs = struct.unpack('!I', frame_bytes[-4:])[0]
    
    return {
        'dst_mac': dst_mac,
        'src_mac': src_mac,
        'type': hex(eth_type),  # 예: 0x0800 (IPv4), 0x86dd (IPv6)
        'payload_len': len(payload),
        'fcs': hex(fcs)
    }

# 예시 프레임 (간략화, 실제는 Wireshark 캡처 데이터 사용)
# 예: dst_mac=ff:ff:ff:ff:ff:ff, src_mac=00:11:22:33:44:55, type=0x0800, payload=46바이트, FCS=임의
example_frame = bytes.fromhex(
    'ffffffffffff001122334455080000450000…' + '12345678'
)
# 실제 사용 시: result = parse_ethernet_frame(example_frame)

이더넷 프레임은 데이터링크 계층 PDU 로, MAC 주소 기반 스위칭을 위한 헤더와 오류 검출을 위한 FCS 트레일러를 포함한다.
Type/Length 필드 (2 바이트) 는 상위 프로토콜 (예: IPv4=0x0800, ARP=0x0806) 을 식별하며, Payload 는 46~1500 바이트 범위를 가진다 (MTU=1518 바이트, Jumbo Frame 은 9000 바이트까지 확장 가능). FCS 는 CRC-32 알고리즘으로 프레임 전체의 무결성을 검증한다.

IP 패킷 구조 (Layer 3 PDU)

IPv4 헤더 주요 필드:

IP 패킷 캡슐화 플로우

sequenceDiagram
    participant App as 응용 계층
    participant TCP as 전송 계층(TCP)
    participant IP as 네트워크 계층(IP)
    participant DL as 데이터링크 계층
    
    App->>TCP: 데이터 전송 요청
    TCP->>TCP: 세그먼트 생성<br>(헤더 추가: 출발지·목적지 포트)
    TCP->>IP: 세그먼트 전달
    IP->>IP: 패킷 생성<br>(헤더 추가: 출발지·목적지 IP, TTL)
    IP->>DL: 패킷 전달
    DL->>DL: 프레임 생성<br>(헤더·트레일러 추가: MAC 주소, FCS)
    DL->>DL: 물리 매체로 비트 전송

IP 패킷은 네트워크 계층 PDU 로, 출발지·목적지 IP 주소, TTL, 프로토콜 ID 등을 포함한다.
TTL 은 라우팅 루프 방지를 위해 각 라우터를 거칠 때마다 1 씩 감소하며, 0 도달 시 패킷이 폐기된다.
Identification, Flags, Fragment Offset 필드는 MTU 초과 시 패킷 단편화와 재조립에 사용된다. Header Checksum 은 헤더만 검증하며, 페이로드 무결성은 상위 계층 (예: TCP 체크섬) 이 담당한다.

TCP 세그먼트 구조 (Layer 4 PDU)

TCP 헤더 주요 필드:

코드 예시: Python 으로 TCP 세그먼트 파싱

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

import struct

def parse_tcp_segment(segment_bytes):
    """
    TCP 세그먼트를 파싱하여 주요 필드 추출
    
    입력: segment_bytes (bytes) - TCP 세그먼트 바이트 스트림
    출력: dict - 파싱된 필드 딕셔너리
    에러케이스: 최소 길이(20바이트) 미만 시 ValueError
    """
    if len(segment_bytes) < 20:
        raise ValueError("TCP segment too short")
    
    # Big-endian 형식으로 헤더 파싱
    src_port, dst_port, seq, ack, offset_flags, window, checksum, urg_ptr = \
        struct.unpack('!HHIIHHH', segment_bytes[:20])
    
    # Data Offset은 상위 4비트(4바이트 단위)
    header_len = (offset_flags >> 12) * 4
    # Flags는 하위 9비트 (NS=1, CWR=1, ECE=1, URG=1, ACK=1, PSH=1, RST=1, SYN=1, FIN=1)
    flags = offset_flags & 0x01FF
    
    payload = segment_bytes[header_len:]
    
    return {
        'src_port': src_port,
        'dst_port': dst_port,
        'seq': seq,
        'ack': ack,
        'header_len': header_len,
        'flags': {
            'SYN': bool(flags & 0x02),
            'ACK': bool(flags & 0x10),
            'FIN': bool(flags & 0x01),
            'RST': bool(flags & 0x04),
            'PSH': bool(flags & 0x08)
        },
        'window': window,
        'checksum': hex(checksum),
        'payload_len': len(payload)
    }

# 예시: SYN 세그먼트 (간략화)
# src=12345, dst=80, seq=1000, ack=0, flags=SYN, window=65535
example_tcp = bytes.fromhex('30390050000003e8000000005002ffff0000')
# 실제 사용 시: result = parse_tcp_segment(example_tcp)

TCP 세그먼트는 전송 계층 PDU 로, 포트 번호를 통해 응용 프로세스를 식별하고, 순서 번호와 확인 번호로 신뢰성 있는 데이터 전송을 구현한다.
Flags 필드는 연결 설정 (SYN), 확인 (ACK), 종료 (FIN), 재설정 (RST) 등 제어 기능을 담당하며, Window Size 는 TCP 흐름 제어를 위한 수신 버퍼 크기를 알린다. Options 필드는 MSS(Maximum Segment Size), Window Scale, SACK(Selective Acknowledgment) 등 성능 최적화 파라미터를 협상한다.

대표 PDU 형식 빠르게 보기

표 4-1. 필수 필드 스냅샷

필드 존재와 검증 방식이 PDU 의 신뢰·오버헤드·가시성을 좌우한다. 예컨대 IPv6 는 헤더 체크섬을 제거해 라우터 처리 비용을 낮췄으며, QUIC/TLS 는 암호화로 중간 가시성을 줄여 상위 진단 기법이 요구된다.

Python 스니펫 4-B—20 바이트 IPv4 고정헤더 파서 (학습용)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# 목적: 바이트열에서 IPv4 고정 헤더(20B)를 파싱하여 핵심 필드 추출
# 입력: bytes(길이>=20)
# 출력: dict
# 예외: 길이/버전 오류 발생 시 ValueError

import struct

def parse_ipv4_header(buf: bytes) -> dict:
    if len(buf) < 20:
        raise ValueError("short buffer")
    vihl, tos, total_len, ident, flags_frag, ttl, proto, hdr_chk, src, dst = struct.unpack(
        "!BBHHHBBHII", buf[:20]
    )
    version = vihl >> 4
    ihl = (vihl & 0x0F) * 4
    if version != 4 or ihl < 20:
        raise ValueError("invalid IPv4 header")
    flags = (flags_frag >> 13) & 0x7
    frag_off = flags_frag & 0x1FFF
    return {
        "version": version,
        "ihl": ihl,
        "total_len": total_len,
        "id": ident,
        "flags": flags,
        "frag_off": frag_off,
        "ttl": ttl,
        "proto": proto,
        "hdr_checksum": hdr_chk,
        "src": src,
        "dst": dst,
    }

해설: 교육 목적의 최소 파서로, 옵션/확장 미처리·체크섬 재계산은 생략했다. 실제 구현은 경계검사, 옵션 파싱, 조각 재조립, 보안 처리까지 필요하다.

캡슐화와 역캡슐화 메커니즘

PDU 의 핵심 동작 원리인 캡슐화 (Encapsulation) 와 역캡슐화 (Decapsulation) 과정을 상세히 다룬다.
송·수신 측의 계층별 처리 흐름과 실무 네트워크 장비 (라우터, 스위치) 의 PDU 조작 방식을 설명한다.

캡슐화 과정 (Encapsulation)

정의: 송신 측에서 상위 계층 PDU 를 페이로드로 받아, 각 계층의 헤더 (및 트레일러) 를 추가하여 하위 계층 PDU 를 생성하는 과정.

단계별 흐름:

graph LR
    A[응용 데이터<br>Application Data] -->|전송 계층| B[TCP 세그먼트<br>TCP Header + Data]
    B -->|네트워크 계층| C[IP 패킷<br>IP Header + Segment]
    C -->|데이터링크 계층| D[이더넷 프레임<br>Ethernet Header + Packet + FCS]
    D -->|물리 계층| E[비트 스트림<br>Bit Stream]
    
    style A fill:#e1f5ff
    style B fill:#fff4e1
    style C fill:#ffe1f5
    style D fill:#e1ffe1
    style E fill:#f5e1ff

표: 계층별 캡슐화 단계

코드 예시: Python 으로 간단한 캡슐화 시뮬레이션

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

def encapsulate_data(app_data):
    """
    응용 데이터를 계층별로 캡슐화하는 시뮬레이션
    
    입력: app_data (str) - 응용 계층 데이터
    출력: dict - 각 계층별 PDU
    """
    # 응용 계층 (예: HTTP GET 요청)
    http_header = "GET /index.html HTTP/1.1\r\nHost: example.com\r\n\r\n"
    http_pdu = http_header + app_data
    
    # 전송 계층 (TCP 헤더 간략화: 포트 번호만 표시)
    tcp_header = f"SRC_PORT=12345|DST_PORT=80|SEQ=1000|"
    tcp_segment = tcp_header + http_pdu
    
    # 네트워크 계층 (IP 헤더 간략화: IP 주소만 표시)
    ip_header = f"SRC_IP=192.168.1.100|DST_IP=93.184.216.34|TTL=64|"
    ip_packet = ip_header + tcp_segment
    
    # 데이터링크 계층 (이더넷 헤더 간략화: MAC 주소만 표시)
    eth_header = f"SRC_MAC=00:11:22:33:44:55|DST_MAC=AA:BB:CC:DD:EE:FF|TYPE=0x0800|"
    eth_trailer = "|FCS=0x12345678"
    ethernet_frame = eth_header + ip_packet + eth_trailer
    
    return {
        'application': http_pdu,
        'transport': tcp_segment,
        'network': ip_packet,
        'data_link': ethernet_frame
    }

# 예시 실행
result = encapsulate_data("Hello, World!")
# 출력: result['data_link']에 전체 캡슐화된 프레임 포함

캡슐화는 상위→하위 방향으로 진행되며, 각 계층은 상위 PDU 전체를 " 불투명한 페이로드 " 로 취급한다. 예를 들어, 네트워크 계층 (IP) 은 TCP 세그먼트의 내부 구조를 알 필요 없이 헤더만 추가하여 패킷을 생성한다. 이는 계층 간 독립성과 확장성을 보장한다. 실무에서는 네트워크 스택 (예: Linux kernel 의 sk_buff 구조체) 이 각 계층에서 헤더를 prepend 하는 방식으로 구현된다.

역캡슐화 과정 (Decapsulation)

정의: 수신 측에서 하위 계층 PDU 로부터 헤더 (및 트레일러) 를 제거하여 상위 계층 PDU 를 복원하는 과정.

단계별 흐름:

graph LR
    A[비트 스트림<br>Bit Stream] -->|물리 계층| B[이더넷 프레임<br>Ethernet Frame]
    B -->|데이터링크 계층| C[IP 패킷<br>IP Packet]
    C -->|네트워크 계층| D[TCP 세그먼트<br>TCP Segment]
    D -->|전송 계층| E[응용 데이터<br>Application Data]
    
    style A fill:#f5e1ff
    style B fill:#e1ffe1
    style C fill:#ffe1f5
    style D fill:#fff4e1
    style E fill:#e1f5ff

표: 계층별 역캡슐화 단계

코드 예시: Python 으로 간단한 역캡슐화 시뮬레이션

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

def decapsulate_frame(ethernet_frame):
    """
    이더넷 프레임을 역캡슐화하여 응용 데이터 추출
    
    입력: ethernet_frame (str) - 캡슐화된 이더넷 프레임
    출력: str - 응용 계층 데이터
    에러케이스: FCS 불일치 시 None 반환
    """
    # 데이터링크 계층: 이더넷 헤더·트레일러 제거
    if "|FCS=" not in ethernet_frame:
        return None  # FCS 없음 → 손상된 프레임
    
    # FCS 검증 (간략화: 단순 존재 확인)
    parts = ethernet_frame.split("|TYPE=0x0800|")
    if len(parts) != 2:
        return None
    ip_packet = parts[1].split("|FCS=")[0]
    
    # 네트워크 계층: IP 헤더 제거
    if "SRC_IP=" not in ip_packet:
        return None
    tcp_segment = ip_packet.split("|TTL=64|")[1]
    
    # 전송 계층: TCP 헤더 제거
    if "SRC_PORT=" not in tcp_segment:
        return None
    http_pdu = tcp_segment.split("|SEQ=1000|")[1]
    
    # 응용 계층: HTTP 헤더 제거
    if "HTTP/1.1" not in http_pdu:
        return None
    app_data = http_pdu.split("\r\n\r\n")[1]
    
    return app_data

# 예시 실행 (캡슐화 결과를 역캡슐화)
original_data = "Hello, World!"
encapsulated = encapsulate_data(original_data)
recovered_data = decapsulate_frame(encapsulated['data_link'])
assert recovered_data == original_data  # 검증: 원본 데이터 복원 확인

역캡슐화는 하위→상위 방향으로 진행되며, 각 계층은 자신의 헤더를 제거하고 상위 계층으로 페이로드를 전달한다. 데이터링크 계층에서는 FCS 검증을 통해 프레임 무결성을 확인하고, 네트워크 계층에서는 Header Checksum 과 TTL 을 검사하며, 전송 계층에서는 TCP Checksum 과 순서 번호를 확인한다. 검증 실패 시 해당 PDU 는 폐기되고 상위 계층으로 전달되지 않는다.

네트워크 장비의 PDU 처리

네트워크 장비는 특정 계층의 PDU 헤더를 분석·조작하여 패킷 전달, 필터링, 분산 등의 기능을 수행한다. 하위 계층 장비 (허브·스위치) 는 상위 PDU 를 투명하게 전달하는 반면, 상위 계층 장비 (방화벽·로드밸런서) 는 응용 데이터까지 분석할 수 있다. 이는 PDU 계층 구조가 네트워크 인프라의 기능 분리와 확장성을 가능하게 함을 보여준다.

MTU, 단편화, MSS 협상

• MTU (Maximum Transmission Unit): 경로에서 단편화 없이 보낼 수 있는 IP(L3) 패킷 최대 크기. 인터페이스 MTU(링크별) 와 **Path MTU(경로 최소값)**을 구분한다. MTU 는 상위 모든 PDU 크기의 상한을 규정한다.
• 단편화 (Frag/Reassembly): MTU 를 초과하는 IP 패킷을 여러 단편으로 나눠 전송/수신 측에서 재조립. IPv4는 라우터·송신자 모두 가능 (DF=0 일 때), IPv6는 송신자만 가능하며 라우터 단편화 금지 (Frag EH 사용). 원칙은 회피다.
• MSS 협상 (Maximum Segment Size): TCP 가 핸드셰이크 (SYN/SYN‑ACK) 에서 합의하는 TCP 데이터 최대치(헤더 제외). 경계 장비의 MSS 클램핑은 경로 MTU 미스매치에 대한 보호장치다.

해설: 세 개념은 한 파이프라인에서 연결된다. MTU 가 상한을 정하고 → MSS 가 TCP 단위 크기를 결정 → 단편화는 실패 시 발생하는 예외 처리다. 운영 목표는 단편화 없이 PMTUD/PLPMTUD·MSS 로 안전 크기를 유지하는 것이다.

정의·특징·역할/기능

MTU (Maximum Transmission Unit)

• 정의: 단편화 없이 전송 가능한 IP 패킷 (L3) 최대 크기.
• 특징
  • 값의 기준은 IP MTU(L2 헤더/트레일러 제외). 이더넷 1500 이 흔함, IPv6 최소는 1280.
  • 헤더 누적(IPv6, TCP 옵션, TLS/QUIC, 터널/오버레이) 로 유효 L7 이 줄어든다.
  • MTU는 처리량·지연·CPU 효율성에 직접 영향
• 역할/기능
  • 크기 상한 제공 → 패킷화/세그먼트화 기준.
  • 경로 적합성 판단 (블랙홀/재전송 방지의 기준).

계산식: Max L7 ≈ IP MTU − (IP + L4 + 보안/옵션/오버레이) / TCP MSS = IP MTU − (IP + TCP).

1
2
3
4
5
6
7
8

┌────────────────────┐
│     이더넷 프레임 (1518바이트)                  │
├─────┬─────────┬────┤
│  Header   │   Payload (MTU)  │    FCS    │
│ 14바이트 │    1500바이트       │ 4바이트 │
└─────┴─────────┴────┘
            ↑                              ↑
           이 부분이 MTU (헤더·트레일러 제외)

Path MTU: 경로상 링크 IP MTU 의 최소값.

• 예시:

  1 2 3 4 5 6 7 8

  호스트A (MTU=9000) → 스위치 (9000) → 라우터1 (1500) ← Path MTU 병목! → 인터넷 (1500) → VPN 게이트웨이 (1400) ← 실제 Path MTU = 1400 → 호스트B (1500) 결과: 1400 초과 패킷은 단편화되거나 폐기됨

계층별 관계

flowchart TB
    subgraph L2["L2 프레임 (1518 B)"]
        direction LR
        L2H[L2 헤더<br/>이더넷 14 B]
        subgraph MTU["MTU (1500 B)"]
            direction LR
            IPH[IP 헤더<br/>20~60 B]
            subgraph IPP["IP 페이로드 (1440~1480 B)"]
                direction TB
                TCP[TCP 헤더<br/>20 B]
                UDP[UDP 헤더<br/>8 B]
                subgraph MSS["MSS 영역"]
                    DATA[TCP/UDP 데이터<br/>1380~1472 B]
                end
            end
        end
        FCS[FCS<br/>CRC 4 B]
        
        L2H --> IPH
        IPH --> IPP
        TCP -.-> DATA
        UDP -.-> DATA
        IPP --> FCS
    end
    
    style L2 fill:#e3f2fd,stroke:#1976d2,stroke-width:3px
    style MTU fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style IPP fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style MSS fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    style L2H fill:#bbdefb,stroke:#1565c0
    style IPH fill:#c8e6c9,stroke:#2e7d32
    style FCS fill:#bbdefb,stroke:#1565c0
    style DATA fill:#f8bbd0,stroke:#880e4f

MTU와 밀접한 관련이 있는 기타 개념

단편화 (Fragmentation)

• 정의: MTU 초과 패킷을 여러 조각으로 나눠 전송·수신측에서 재조립.
• 특징
  • IPv4: DF=0 이면 라우터/송신자 모두 가능, DF=1 이면 ICMP(Frag Needed).
  • IPv6: 라우터 단편화 금지, 송신자만 가능 (PTB 로 크기 교정).
  • 재조립 비용↑, 손실 민감↑, 방화벽/NAT 문제 (중간 단편에 포트없음) → 회피가 원칙.
• 역할/기능: 최후의 안전망이지만 지연/손실/CPU 비용을 키우므로 PMTUD/PLPMTUD + MSS로 사전 회피.

MSS 협상 (Maximum Segment Size)

• 정의: TCP 세그먼트 데이터부 최대 크기(헤더 제외). 3-way handshake 에서 서로 광고 → 더 작은 값 사용.
• 특징
  • MSS = IP MTU − (IP + TCP)(옵션 고려 시 더 작게). 일반 이더넷 IPv4 기준 1460B, IPv6 1440B(고정헤더만).
  • MSS 클램핑: 중간장비가 SYN 의 MSS 를 낮춰 경로 MTU 에 맞춤 (터널/VPN 안정화).
• 역할/기능: 세그먼트화 단계에서 MTU 초과를 예방 → 단편화·재조립 회피, 재전송 감소.

적용 위치와 흐름

• MTU는 송신 호스트의 IP egress와 라우터 egress에서 실제 크기 검증이 이뤄지고, 터널 ingress 에서는 외부 헤더 가산을 고려해 내부 MTU 를 미리 낮추는 설계가 필수다.
• MSS는 양끝 TCP가 SYN 교환으로 결정하고, 중간 장비가 클램핑으로 강제 축소해 단편화 사전 회피에 기여한다.
• 단편화는 IPv4 에서 송신/라우터 모두 가능 (DF=0), IPv6 는 송신자만 가능하며, 재조립은 항상 수신 호스트 IP가 담당한다. 가능하면 PMTUD/PLPMTUD+MSS로 회피하라.

적용흐름

1. Host A / TCP: SYN 에 MSS 광고, 상대와 min 선택 → 세그먼트화 한도 결정.
2. Host A / IP: 라우팅 후 출구 MTU/PMTU 확인 → 크기 초과면 축소 (IPv6) 또는 (IPv4, DF=0) 자체 단편화.
3. Routers / Forwarding: egress MTU 비교 → (IPv4, DF=0) 단편화 또는 (IPv4 DF=1/IPv6) ICMP 통지.
4. Host A / PLPMTUD: ICMP 또는 ACK 기반으로 PMTU 캐시 갱신, 세그먼트/레코드 크기 추가 축소.
5. Host B / IP: 도착한 조각 재조립 후 L4 로 인도.

flowchart LR
%% title: mtu-frag-mss-from-to
%% caption: From(캡슐화)→경로(MTU/ICMP)→To(역캡슐화/재조립) 흐름

subgraph HOST_A["Host A — 캡슐화"]
  A1[앱 SDU]
  A2["TLS/QUIC (선택)"]
  A3["TCP/UDP (세그먼트/데이터그램)"]
  A4["IP (IPv4/IPv6)"]
  A5[L2 프레임화]
  A1 --> A2 --> A3 --> A4 --> A5
end

A5 --> R1

subgraph PATH["Routers — 전송 경로"]
  R1{다음 홉 MTU ≥ 패킷?}
  R1 -- 예 --> R2[포워딩]
  R1 -- 아니오 --> R3{IPv4 & DF=0?}
  R3 -- 예 --> R4[IPv4 단편화 수행]
  R3 -- 아니오 --> R5[ICMP Frag Needed / ICMPv6 PTB]
end

R2 --> B1
R4 --> B1

R5 --> A2a["송신자: 크기 축소\n(MSS/레코드/PLPMTUD)"]
A2a --> A3

subgraph HOST_B["Host B — 역캡슐화/재조립"]
  B1[L2 해제]
  B2[IPv4/IPv6 재조립]
  B3[TCP/UDP 전달]
  B4[TLS/앱 인도]
  B1 --> B2 --> B3 --> B4
end

주: 캡슐화 (Host A, 송신) → 전송 경로 (Routers) → 역캡슐화 (Host B, 수신)

MTU—어디서, 어떻게 적용되나

송신 호스트 (Host A)—IP 계층 Egress 경로에서 MTU 적용

• 주체: OS 커널의 IP 출력 경로 (IPv4/IPv6) + 라우팅/디바이스 MTU 테이블.
• 어디서:
  1. 라우팅 결정 (다음 홉/출구 인터페이스 선택) →
  2. 출구 인터페이스의 IP MTU(또는 경로 MTU 캐시) 에 맞춰 IP 패킷 크기 검사 →
  3. 초과하면: IPv4 는 DF=0 이면 자체 단편화, DF=1 이면 전송 금지/ICMP 의존. IPv6 은 라우터 단편화 금지이므로 자체 크기 축소 또는 (필요시) 송신자 단편화 헤더만 가능.
• 어떻게: 커널은 dst_entry/route 의 PMTU(경로 MTU) 캐시를 참조하고, GSO/TSO 가 켜져 있어도 온와이어 기준으로 MTU 를 지킨다 (오프로딩은 NIC 가 패킷을 쪼개 보냄).
• 실무 포인트:
  • Linux: ip link show dev <if>, ip route get <dst> 로 dev/route MTU 확인, ip route change … mtu <n> 가능.
  • PMTU 캐시는 ICMP(Frag Needed/PTB) 나 PLPMTUD 로 갱신된다.

중간 라우터 (Routers)—출구 인터페이스에서 다음 홉 MTU 검사

• 주체: 라우터의 포워딩 평면 (하드웨어/소프트웨어) + egress 인터페이스 MTU.
• 어디서: 라우팅 후 egress MTU 비교에서 패킷 크기>MTU 면 분기:
  • IPv4: DF=0 이면 라우터가 단편화 수행 (Identification/Fragment Offset/MF 조정). DF=1 이면 드롭 + ICMP Type3 Code4(Frag Needed) 전송.
  • IPv6: 항상 드롭 + ICMPv6 PTB(Type 2) 전송 (라우터 단편화 금지).
• 터널/오버레이: VXLAN/GRE/IPsec 같은 캡슐화 (ingress) 장비는 외부 헤더를 얹기 전 내부 패킷 + 외부 헤더 합계가 외부 링크 MTU를 넘지 않게 내부 MTU 를 낮춰야 한다 (장비가 내부 DF 취급을 따로 함). [RF:2,3,4]

수신 호스트 (Host B)—IP 계층 Ingress 에서 재조립/검사

• 주체: OS 커널의 IP 입력 경로 (IPv4 조각 재조립, IPv6 조각 재조립).
• 어디서: 조각화된 IPv4/IPv6 패킷을 IP 계층에서 재조립한 뒤 L4(UDP/TCP) 로 전달. MTU 는 수신 시 강제 적용 대상이 아니며, 이미 경로에서 맞춰진다.

MSS 협상—어디서, 어떻게 결정·강제되나

송신/수신 호스트—TCP 3-way Handshake 에서 결정

• 주체: 양 끝단 TCP 스택.
• 어디서: SYN/SYN-ACK 교환 시 TCP 옵션의 MSS 값을 서로 광고 → **더 작은 값 (min)**을 채택.
• 어떻게: 채택된 MSS 를 기준으로 **세그먼트화 (송신 측 TCP)**가 이뤄진다. 이후 PMTU 가 줄면 커널이 세그먼트 크기를 더 줄인다 (PLPMTUD/PMTUD 반영).
• 실무 포인트:
  • Linux: net.ipv4.tcp_mtu_probing=2(PLPMTUD 항상), tcp_base_mss, tcp_min_snd_mss 로 하한 설정.
  • 캡처로 SYN 옵션의 MSS 값 확인 (중간 장비 개입 여부 점검).

중간 장비 (라우터/방화벽/로드밸런서)—MSS 클램핑

• 주체: L3/L4 장비의 정책 엔진.
• 어디서: 경계 구간에서 TCP SYN 패킷의 MSS 옵션 값을 강제로 낮춤(예: --clamp-mss-to-pmtu 혹은 고정값).
• 어떻게: 이후 전 구간에서 더 작은 MSS로 세그먼트가 생성되어 단편화/블랙홀 사전 예방. 터널/VPN 환경 필수 관행.

요지: MSS 는 **TCP 세그먼트화 단계 (호스트 TCP)**에서 적용되고, 중간 장비는 SYN 의 MSS 를 수정해 경로 제약을 강제한다.

단편화 (Fragmentation)—어디서, 어떻게 발생·해결되나

IPv4

• 송신 호스트: DF=0 이면 자체 단편화 가능(IP 출력 경로). DF=1 이면 단편화 금지 → 크기 축소 필요 (=MSS/레코드 사이즈 조정, PMTUD/PLPMTUD).
• 중간 라우터: DF=0 & MTU 초과 시 라우터가 단편화 수행 (egress 에서). DF=1 이면 드롭 + ICMP Frag Needed.
• 수신 호스트: 재조립은 항상 수신 호스트 IP 계층에서 수행.
• 부작용: 조각 손실=전체 폐기, 방화벽/NAT 필터링 곤란 (중간 조각에 L4 포트 없음), CPU/버퍼 비용↑ → 가능하면 회피.

IPv6

• 송신 호스트만 단편화 가능: Fragment Extension Header를 송신자가 붙일 수 있으나, 권장 경로는 PTB 수신 → 크기 축소.
• 라우터 단편화 금지: MTU 초과 시 항상 PTB로 통지.
• 수신 호스트: 재조립 수행.
• 최소 MTU 1280B: 설계 시 안전 하한.

요지: 단편화는 IPv4 에서는 (송신/라우터) 둘 다, IPv6 에서는 송신자만. 운영상 회피가 원칙이며 PMTUD/PLPMTUD·MSS 로 사전 예방한다.

터널·보안·오프로딩과의 상호작용

• 캡슐화 (From, 터널 ingress): VXLAN/GRE/IPsec ESP 등 외부 헤더 추가 직전에 내부 MTU 를 낮춰야 외부 링크 MTU 를 넘지 않는다 (장비/OS 의 터널 인터페이스 MTU 설정이 핵심).
• 전송 경로 (Routers): 터널 외부 패킷이 egress MTU 를 넘으면 외부 패킷이 드롭/단편화된다 (특히 IPv4). PPTB/Frag Needed 신호가 내부 송신자까지 전달되지 못하면 블랙홀이 되므로 ICMP 정책과 터널의 PTB 처리 로직이 중요.
• 역캡슐화 (To, 터널 egress): 외부 헤더를 제거하고 내부 패킷을 원형대로 내보낸다. 이때 내부 패킷은 이미 작게 설계되어 있어야 한다.
• 오프로딩 (TSO/GSO/GRO): 세그먼트화는 호스트 TCP, MTU 준수는 온와이어에서 NIC/드라이버가 보장. 호스트 캡처는 ’ 큰 가상 세그먼트 ’ 로 보일 수 있어 경계 캡처와 교차 검증 필요.

주체·지점·동작

해설: MTU/단편화는 IP 계층, MSS 는 TCP 계층의 일로서, 결정 지점이 다르다. 터널/오버레이가 끼면 외부 MTU에 맞춰 내부 MTU 하향 + 클램핑을 세트로 적용해야 블랙홀을 방지한다.

IP MTU 기준 대표 조합 (1500 기준)

PMTUD/PLPMTUD·MSS 의사결정 (송신 측 중심)

flowchart TD
%% title: pmtud-plpmtud-mss-decision
S[송신 시작] --> P{ICMP 신뢰 가능?}
P -- 예 --> P1["PMTUD 사용\n(DF=1)"]
P -- 아니오 --> P2["PLPMTUD 사용\n(ACK/Probe 기반)"]
P1 --> C["MSS= min(양단 MSS, PMTU-헤더)"]
P2 --> C
C --> T{터널/보안/옵션 추가?}
T -- 예 --> T1[헤더 가산→내부 MTU/MSS 재계산]
T -- 아니오 --> D[전송]

• 권장 조합: PMTUD(+ICMP 정책 정합) 우선, 경로 불확실/차단 환경은 PLPMTUD 병행 + MSS 클램핑.

웹 브라우징에서의 PDU 흐름

브라우저 URL 입력 후 이름 해석 (DNS/DoH/DoT) → 연결 수립 (HTTP/2 over TCP/TLS 1.3 또는 HTTP/3 over QUIC/UDP/TLS 1.3) → 요청/응답 → 리소스 병렬 로딩으로 진행되며, 상위 **SDU(Service Data Unit)**가 하위 PDU로 캡슐화되어 이동한다.
대표 PDU 는 DNS 메시지, TLS 레코드, QUIC 패킷, TCP 세그먼트, IP 패킷, L2 프레임이다.
HTTP/3 는 HTTP/3 를 QUIC 위에 매핑하고, HTTP/2 는 TCP 위에 HTTP/2 프레이밍을 둔다.

• HTTP/3(하이퍼텍스트 전송 프로토콜 버전 3): QUIC(Quick UDP Internet Connections) 위에서 HTTP 의미론을 운반. 스트림 단위 멀티플렉싱·흐름제어·저지연 수립을 QUIC 이 제공.
• HTTP/2: 단일 TCP 연결 내부에서 프레임 단위 멀티플렉싱 (헤더 압축 포함) 제공.
• DNS-over-HTTPS(DoH)/DNS-over-TLS(DoT): 평문 DNS 를 각각 HTTPS/TLS로 감싸 전송.

단계별 캡슐화·역캡슐화 (요청→응답)

1. 이름 해석
   • 전통 DNS(Domain Name System): 일반적으로 UDP 포트 53, 필요 시 TCP로 폴백. (EDNS0 확장으로 UDP 응답 확장 가능—여기서는 개요만)
   • DoH/DoT: DNS 메시지를 각각 HTTP/2·HTTP/3 또는 TLS로 보호해 전송 (암호화·인증 경로 확보).
2. 연결 수립
   • HTTP/3 over QUIC/UDP/TLS 1.3: QUIC 초기 (Initial) 패킷은 최소 1200 바이트로 전송해야 하며, TLS 1.3 핸드셰이크는 QUIC 의 CRYPTO/핸드셰이크 프레임으로 진행된다 (0-RTT/1-RTT 모드).
   • HTTP/2 over TCP/TLS 1.3: TCP 3-way 핸드셰이크(MSS 협상) 후 TLS 1.3 핸드셰이크 (1-RTT), 그 위에서 HTTP/2 프레임 교환.
3. 요청/응답 교환
   • HTTP/3: L7 요청/응답이 HTTP/3 프레임 → QUIC 패킷 → UDP 데이터그램 → IP → L2로. 스트림 독립 재전송·혼잡제어는 QUIC 담당.
   • HTTP/2: L7 프레임이 TLS 레코드 → TCP 세그먼트 → IP → L2로. 손실 복구·혼잡제어는 TCP 담당.
4. 리소스 병렬 로딩
   • HTTP/3/HTTP/2 모두 단일 연결 (혹은 소수 연결) 에서 스트림/프레임 멀티플렉싱으로 CSS/JS/이미지를 병렬 전송.

웹 브라우저에서 https://example.com 을 입력했을 때 일어나는 모든 과정

flowchart TD
    Start[브라우저에 URL 입력<br/>https\:\/\/example.com]
    
    DNS[DNS 조회<br/>도메인 → IP 주소]
    TCP[TCP 3-Way Handshake<br/>연결 설정]
    TLS[TLS 1.3 Handshake<br/>보안 채널 설정]
    HTTP[HTTP 요청/응답<br/>HTML, CSS, JS 다운로드]
    Render[브라우저 렌더링<br/>화면 표시]
    
    Start --> DNS
    DNS --> TCP
    TCP --> TLS
    TLS --> HTTP
    HTTP --> Render
    
    style DNS fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style TCP fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style TLS fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style HTTP fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style Render fill:#fce4ec,stroke:#c2185b,stroke-width:2px

요약

캡슐화 과정 (송신, 하향)

1. 애플리케이션 → DNS 쿼리, TCP SYN, TLS 핸드셰이크, HTTP 요청 생성
2. 전송 계층 → UDP(DNS) 또는 TCP(웹) 헤더 추가 (8-60 B)
3. 네트워크 계층 → IP 헤더 추가 (20-40 B), 라우팅 정보
4. 데이터링크 → 이더넷 헤더 (14 B) + FCS(4 B) 추가
5. 물리 계층 → 전기/광 신호로 변환, 네트워크 전송

역캡슐화 과정 (수신, 상향)

1. 물리 계층 → 신호 수신, 디지털 변환
2. 데이터링크 → MAC 확인, FCS 검증, 헤더 제거
3. 네트워크 계층 → 목적지 IP 확인, 헤더 제거
4. 전송 계층 → 포트 확인, 재조립, 흐름 제어
5. 애플리케이션 → TLS 복호화, HTTP 처리, 브라우저 렌더링

관찰 지점별로 실제 보이는 PDU

MTU·MSS·단편화—웹 특화 검증 포인트

• **MTU(Maximum Transmission Unit)**와 Path MTU: 경로의 최소소값이 상한을 결정. IPv4 는 ICMP “Fragmentation Needed”(RFC 1191) 로, IPv6 는 ICMPv6 “Packet Too Big”(RFC 8201) 로 송신자에게 축소를 알린다.
• PLPMTUD(Packetization Layer PMTUD): ICMP 의존 없이 전송/애플리케이션 계층에서 증분 크기 탐색으로 안전 크기를 학습 (TCP/QUIC 에 적용).
• MSS(Maximum Segment Size) 협상: TCP SYN/SYN-ACK에서 양단이 알린 값의 최솟값 사용 (이후 PMTUD/PLPMTUD 에 의해 더 줄어들 수 있음). (표준은 TCP/IP 일반 규정·HTTP/2 사양 맥락에서 간접 확인)
• TLS 1.3 레코드 오버헤드: TLS 레코드 헤더 5 바이트 + 선택된 AEAD(Authenticated Encryption with Associated Data) 태그(일반적으로 16 바이트: AES-GCM/ChaCha20-Poly1305). 레코드 크기를 MSS/Path MTU에 맞춰 쪼개야 불필요한 IP 단편화나 PMTUD 블랙홀을 예방.
• QUIC 초기 패킷 최소 크기 1200 바이트: 경로 검증·증폭 공격 완화 목적. 무선/터널 경로의 작은 Path MTU 와 충돌 시 PLPMTUD 정책이 중요.

HTTP/2 Vs HTTP/3—PDU 관점의 차이

• HTTP/2(TCP/TLS 1.3): 전송 PDU 는 TCP 세그먼트, 보안 PDU 는 TLS 레코드. 위험 신호는 PMTUD 블랙홀(큰 객체가 특정 지점에서 멈춤) 로 나타나며 ICMP 허용 + PLPMTUD + MSS 클램핑으로 완화.
• HTTP/3(QUIC/UDP/TLS 1.3): 전송 PDU 는 QUIC 패킷. 스트림별 재전송·혼잡제어로 HOL(Head-of-Line) 블로킹을 줄이고, 0-RTT/1-RTT 수립을 지원. 초기 패킷은 1200 바이트 이상으로 Path MTU/방화벽 정책과의 상호작용을 반드시 점검.

HTTP/2(TCP) 웹 페이지 로딩의 PDU 흐름

sequenceDiagram
%% title: web-h2-pdu
participant U as User Agent (Browser)
participant R as DNS/DoH Resolver
participant S as Web Server (H2)
U->>R: DNS/DoH 질의 (DNS msg / HTTPS)
R-->>U: A/AAAA
U->>S: TCP SYN [MSS]
S-->>U: SYN-ACK [MSS]
U->>S: ACK  (연결 성립)
U-->>S: TLS1.3 ClientHello (TLS Record)
S-->>U: TLS1.3 ServerHello… (TLS Records)
U->>S: GET / (HTTP/2 frames)
S-->>U: HTML/CSS/JS (HTTP/2 frames → TLS records → TCP segments)
Note over U,S: L7(HTTP/2) → TLS Record → TCP Segment → IP → L2

HTTP/2 는 TLS 레코드가 상위 PDU, TCP 세그먼트가 전송 PDU 다. MSS 협상과 PMTUD/PLPMTUD에 따라 세그먼트 크기가 결정되고, 손실 시 TCP 재전송이 수행된다.

HTTP/3(QUIC) 웹 페이지 로딩의 PDU 흐름

sequenceDiagram
%% title: web-h3-pdu
participant U as User Agent (Browser)
participant R as DNS/DoH Resolver
participant S as Web Server (H3)
U->>R: DNS/DoH 질의 (DNS msg / HTTPS)
R-->>U: A/AAAA(또는 Alt-Svc)
U->>S: QUIC Initial (TLS CH)  ~1200B
S-->>U: QUIC Initial (TLS SH/EE)
U->>S: GET / (HTTP/3 frames)
S-->>U: HTML/CSS/JS (H3 frames → QUIC packets)
Note over U,S: L7(HTTP/3) → QUIC frame → QUIC packet → UDP → IP → L2

HTTP/3 은 QUIC 패킷이 전송 PDU 이고, 그 안에 HTTP/3 프레임과 TLS 핸드셰이크가 들어간다. 손실 시 QUIC 이 스트림 단위로 재전송/복구하며, 멀티플렉싱으로 HOL 지연을 줄인다.

단계/계층별 SDU→PDU 매핑

관찰 지점별 PDU 맵 (웹 브라우징)

MTU·MSS·단편화—웹 특화 포인트

• MTU 기준: Max L7 ≈ IP MTU − (IP + L4 + 보안/옵션/오버레이). H3 는 QUIC+UDP+AEAD, H2 는 TLS+TCP 오버헤드가 반영된다. 터널/VPN/모바일 경로는 추가 차감.
• MSS 협상 (H2): 3-way 에서 min(MSS) 이 정해지고, 이후 PMTUD/PLPMTUD 로 더 줄어들 수 있다. 클램핑으로 블랙홀 예방.
• 단편화 회피: IPv4 DF=1, IPv6 라우터 단편화 금지. PMTUD/PLPMTUD 실패 시 대용량 객체에서 멈춤 현상 → MTU 하향/레코드 크기 축소.

MTU 별 전송 효율 비교

오버헤드 비교:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

MTU 1500:
- 세그먼트당 오버헤드: 54 B (IP 20 + TCP 20 + 이더넷 14)
- 총 오버헤드: 54 × 36 = 1944 B
- 효율: 50000 / (50000 + 1944) = 96.3%

MTU 576 (최소):
- 세그먼트당 오버헤드: 54 B
- 총 오버헤드: 54 × 95 = 5130 B
- 효율: 50000 / (50000 + 5130) = 90.7%

결론: 큰 MTU = 높은 효율

Path MTU 문제 시나리오

sequenceDiagram
    participant C as 클라이언트<br/>(MTU 1500)
    participant R as 라우터<br/>(MTU 1400)
    participant S as 서버<br/>(MTU 1500)
    
    Note over C,S: TCP 연결 성립 (MSS=1460)
    
    C->>R: TCP 세그먼트 (1460 B 데이터)
    Note over R: MTU 1400 초과!<br/>DF=1 설정됨
    R->>C: ICMP PTB (Next MTU=1400)
    
    Note over C: Path MTU 업데이트<br/>MSS 1360으로 조정
    
    C->>R: TCP 세그먼트 (1360 B 데이터)
    R->>S: 전달 성공
    S->>R: TCP ACK
    R->>C: ACK 전달
    
    Note over C,S: 이후 1360 B로 계속 전송

TLS 레코드 크기와 MTU

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

TLS 레코드 최대 크기: 16 KB (RFC 8446)
실제 권장 크기: MTU 고려하여 설정

예시:
Path MTU = 1400
→ MSS = 1400 - 20(IP) - 20(TCP) = 1360 B
→ TLS 레코드 크기 = 1360 - 5(레코드 헤더) - 16(AEAD 태그) = 1339 B

큰 HTTP 응답:
→ TLS가 자동으로 여러 레코드로 분할
→ 각 레코드는 MSS 이하로 유지
→ TCP 세그먼트 단편화 방지

실시간 동영상 스트리밍에서의 PDU 흐름

라이브/실시간 스트리밍의 일반 경로는 **캡처·인코딩 (Producer) → 인제스트 (Origin) → 패키징 (CMAF/HLS/DASH) → CDN 전송 (Edge) → 플레이어 (Client)**이다.
각 홉에서 상위 **SDU(Service Data Unit)**가 하위 계층의 **PDU(Protocol Data Unit)**로 캡슐화/역캡슐화되며, 사용 스택에 따라 PDU 이름·오버헤드·복구전략·지연 특성이 달라진다.

라이브 영상은 L7 미디어 청크가 선택한 전송 스택 (HTTP/3/QUIC 또는 HTTP/2/TCP, 또는 SRTP) 에 따라 서로 다른 PDU(QUIC 패킷·TLS 레코드·TCP 세그먼트·RTP 패킷) 로 포장되어 IP/L2 위를 흐르고, MTU·손실·혼잡 제약 속에서 재전송·적응·버퍼링으로 품질을 유지한다.

대표 전송 스택

단계별 캡슐화·역캡슐화

1. Producer → Origin(인제스트)

   • L7 SDU: H.264/H.265/AV1 프레임/슬라이스
   • 전송 예: RTMP(Real-Time Messaging Protocol)/TCP, SRT(Secure Reliable Transport)/UDP, WebRTC(SRTP/UDP)
   • PDU: RTMP 메시지↔TCP 세그먼트 / SRT 패킷↔UDP 데이터그램

2. Origin(패키징) → CDN Edge

   • L7 SDU: CMAF(fMP4) 청크, HLS 세그먼트/파트, DASH 세그먼트, 매니페스트 (playlist/MPD)
   • PDU: (A) HTTP/3 프레임 → QUIC 패킷 → UDP → IP → L2 / (B) HTTP/2 프레임 → TLS 레코드 → TCP 세그먼트 → IP → L2

3. Edge → Player(클라이언트)

   • 매니페스트 갱신 → 파트/세그먼트 프리페치/우선순위 요청
   • 역캡슐화: L2 → L3(IP) → L4(UDP/TCP) → (QUIC/TLS 해제) → L7 컨테이너 (fMP4) 파싱 → 디코더

요약

PDU 캡슐화 (송신)

1. L7: 영상 데이터 → RTP 메시지 (1212 B)
2. L4: UDP 헤더 추가 → 데이터그램 (1220 B)
3. L3: IP 헤더 추가 → 패킷 (1240 B)
4. L2: 이더넷 헤더 +FCS → 프레임 (1258 B)
5. L1: 디지털 → 전기 신호 → 전송

PDU 역캡슐화 (수신)

1. L1: 전기 신호 → 디지털 비트
2. L2: 프레임 검증 → 헤더 제거 (1240 B)
3. L3: IP 확인 → 헤더 제거 (1220 B)
4. L4: UDP 확인 → 헤더 제거 (1212 B)
5. L7: RTP 재조립 → 디코딩 → 화면 표시

각 계층의 역할

• L7: 비디오 인코딩/디코딩, 패킷화/재조립
• L4: 포트 기반 애플리케이션 식별
• L3: IP 주소 기반 라우팅
• L2: MAC 주소 기반 로컬 전달, 오류 검출
• L1: 물리적 신호 전송

관찰 지점별 PDU 맵

시퀀스—라이브 세그먼트 전달 (HTTP/3 예시)

sequenceDiagram
%% title: live-h3-pdu
participant P as Player(Client)
participant E as CDN Edge
participant O as Origin
P->>E: GET /playlist.m3u8 (HTTP/3)
E-->>P: playlist (QUIC packets)
P->>E: GET /seg_101_part_1.m4s (HTTP/3)
E-->>P: part_1 (CMAF chunk in QUIC)
E->>O: cache miss → fetch chunk (HTTP/3)
O-->>E: chunk (HTTP/3/QUIC)
Note over P,E: L7 chunk → H3 frame → QUIC packet → UDP → IP → L2

WebRTC 경로 핵심 (초저지연·상호작용)

• **ICE(Interactive Connectivity Establishment)**가 **STUN(Session Traversal Utilities for NAT)/TURN(Traversal Using Relays around NAT)**으로 경로를 찾고, DTLS로 키 교환 후 SRTP로 미디어 보호.
• 수신 품질 피드백은 RTCP의 NACK(Negative Acknowledgement)/PLI(Picture Loss Indication)/FIR(Full Intra Request).
• 손실 복구: RTX(RTP Retransmission), FEC(Forward Error Correction), SVC(Scalable Video Coding) 조합.

sequenceDiagram
%% title: webrtc-pdu
participant Pub as Publisher
participant SFU as SFU(Selective Forwarding Unit)
participant Sub as Subscriber(Player)
Pub->>SFU: DTLS handshake (over UDP)
SFU-->>Pub: DTLS complete
Pub->>SFU: SRTP media (RTP protected)
Sub-->>SFU: RTCP RR/NACK/PLI
SFU-->>Sub: SRTP media (forwarded)
Note over Pub,Sub: RTP → SRTP → UDP → IP → L2

MTU/MSS/단편화—스트리밍 맥락

• IPv6 최소 MTU = 1280 바이트, QUIC Initial ≥ ≈1200 바이트: 초기 QUIC 핸드셰이크는 큰 패킷을 요구하므로, 터널/VPN(예: VXLAN, IPsec) 오버헤드를 뺀 Path MTU 기준으로 UDP 페이로드 상한을 계산해야 합니다.
• MSS(Maximum Segment Size) 협상 (TCP): SYN/SYN-ACK 에서 min(MSS) 채택 → 이후 PMTUD/PLPMTUD로 추가 축소 가능. 방화벽/경계에서 MSS 클램핑은 블랙홀 예방책.
• 단편화 (Fragmentation) 회피가 원칙: IPv4 는 DF=0 에서 라우터 단편화 가능하지만 지양, IPv6 라우터 단편화 금지(송신자만 분할). 실패 시 ICMP PTB(Packet Too Big)/Frag Needed로 축소 유도.

MTU 와 PDU 의 관계

1
2
3
4
5

MTU 1500 B = L3 패킷 최대 크기
→ L4 데이터 최대 = 1500 - 20(IP) = 1480 B
→ L7 메시지 최대 = 1480 - 8(UDP) = 1472 B
→ RTP 페이로드 최대 = 1472 - 12(RTP) = 1460 B
→ 실전 권장 = 1200 B (안전 마진)

이 과정을 통해 영상 데이터는 송신자에서 수신자까지 각 계층의 PDU 로 변환되며 전달된다.

손실·혼잡 시 복구 비교 (요점)

지연 예산 (End-to-End Latency Budget, 전형 가이드)

전형 합계: WebRTC ≈ 100–300 ms, LL-HLS/LL-DASH ≈ 0.5–3 s, 전통 HLS/DASH(2–6 s 세그먼트) ≈ 3–30 s.

품질·지연 최적화 체크리스트 (수신자/운영자 관점)

• ABR(Adaptive Bitrate): 목표 버퍼 (예: 2–6 s), 다운스위치 임계값을 RTT/손실률과 정합.
• ECN/DSCP(Differentiated Services Code Point): 경로 지원 시 활성화, **AQM(Active Queue Management)**와 조합.
• QUIC 튜닝: 패킷 페이싱, 초기 윈도, 재전송 타이머, ACK 배송 정책 조정.
• Wi-Fi/5G: 변동 MTU/지연/손실 → 작은 파트, 다중 연결/도메인 (shard) 병렬화.
• ICMP 정책: PTB/Frag Needed 허용 (레이트리밋), PLPMTUD 병행.
• 오버헤드/터널: 터널 인터페이스 MTU 하향 + 내부 MSS 클램핑 동시 적용.
• 오프로딩 (TSO/GSO/GRO): 성능↑/가시성↓ → 경계 캡처로 온와이어 재검증.

(부록) 간단 산식 메모

1
2

Max L7 payload ≈ Path MTU − (IP 헤더 + L4 헤더 + 보안/옵션/오버레이)
예: IPv6/TCP + TLS1.3 @ MTU 1500 → 1500 − (40 + 20 + ~21) ≈ 1419 B

PDU 크기 변화 요약

graph LR
    A["L7 메시지<br/>1212 B"] 
    B["L4 데이터그램<br/>1220 B<br/>(+8)"]
    C["L3 패킷<br/>1240 B<br/>(+20)"]
    D["L2 프레임<br/>1258 B<br/>(+18)"]
    E["L1 비트<br/>10064 bits"]
    
    A -->|UDP 캡슐화| B
    B -->|IP 캡슐화| C
    C -->|이더넷 캡슐화| D
    D -->|물리 인코딩| E
    
    E -.->|물리 디코딩| D
    D -.->|이더넷 역캡슐화| C
    C -.->|IP 역캡슐화| B
    B -.->|UDP 역캡슐화| A
    
    style A fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style B fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style C fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    style D fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style E fill:#fce4ec,stroke:#c2185b,stroke-width:2px

캡슐화 과정 (송신)

오버헤드 비율: 46 B / 1212 B = 3.8%

역캡슐화 과정 (수신)

실전 예시: 한 프레임의 전체 여정

송신 측 타임라인

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

T=0ms    : 카메라에서 원본 프레임 캡처 (1920×1080)
T=5ms    : H.264 인코딩 완료 (8 KB 압축)
T=6ms    : RTP 패킷화 (7개 패킷으로 분할)
T=7ms    : 첫 번째 RTP 패킷 전송 시작
           └─ L4 캡슐화 (UDP 헤더 추가)
           └─ L3 캡슐화 (IP 헤더 추가)
           └─ L2 캡슐화 (이더넷 프레임화)
           └─ L1 전송 (NIC로 전기 신호 송출)
T=8ms    : 두 번째 RTP 패킷 전송...
T=13ms   : 일곱 번째 RTP 패킷 전송 완료

네트워크 전송

1
2
3
4
5

T=14ms   : 패킷들이 네트워크를 통해 전파
           - 라우터 1 통과 (1 ms)
           - 라우터 2 통과 (1 ms)
           - 인터넷 백본 (20 ms)
           - ISP 라우터 (2 ms)

수신 측 타임라인

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

T=38ms   : 첫 번째 패킷 도착
           └─ L1 수신 (NIC에서 비트 수신)
           └─ L2 역캡슐화 (이더넷 헤더 제거)
           └─ L3 역캡슐화 (IP 헤더 제거)
           └─ L4 역캡슐화 (UDP 헤더 제거)
           └─ L7 처리 (RTP 버퍼에 저장)
T=39ms   : 두 번째 패킷 도착...
T=40ms   : 세 번째 패킷 손실! (네트워크 혼잡)
T=41ms   : 네 번째 패킷 도착...
T=45ms   : 일곱 번째 패킷 도착
T=46ms   : 손실 패킷 복구 (FEC 또는 재전송)
T=50ms   : 지터 버퍼에서 프레임 추출
T=55ms   : H.264 디코딩 완료
T=60ms   : GPU 렌더링 및 화면 표시

총 엔드투엔드 지연: 60 ms (캡처 → 화면)

대용량 파일 다운로드에서의 PDU 흐름

대용량 다운로드는 애플리케이션의 바이트 스트림이 전송 스택에서 TLS 1.3 레코드 (Transport Layer Security 1.3 Record) → TCP 세그먼트 (Transmission Control Protocol Segment) 또는 QUIC 패킷 (Quick UDP Internet Connections Packet) → IP 패킷 (Internet Protocol Packet) → L2 프레임 순으로 반복 캡슐화되어 흐르며, 실제 처리량은 **MSS(Maximum Segment Size)·PMTUD(Path MTU Discovery)/PLPMTUD(Packetization-Layer PMTUD)·혼잡 윈도 (cwnd)·수신 윈도 (rwnd/Window Scaling)·재전송 (SACK/ACK Ranges)·오프로딩 (TSO/GSO/GRO)**의 상호작용으로 결정된다.
목표는 단편화 없이 (Path MTU 이내) 꾸준히 흘려보내는 것이다.

전체 경로와 단계 (송신 → 경로 → 수신)

1. 서버 (송신)

   • L7 SDU(Service Data Unit): 파일 바이트 스트림
   • TLS 1.3 사용 시 수 KB~수십 KB 크기의 TLS 레코드로 잘라 암호화 (AEAD: Authenticated Encryption with Associated Data).
   • 전송 계층이 MSS를 기준으로 TCP 세그먼트(HTTP/2/1.1) 또는 QUIC 패킷(HTTP/3) 으로 분할.
   • TSO/GSO가 켜져 있으면 커널은 큰 청크를 NIC 가 온와이어 MSS 단위로 쪼개도록 위임.

2. 네트워크 경로 (라우터/방화벽)

   • 각 홉 egress 에서 다음 홉 MTU를 넘는지 판정.
   • IPv4: DF=0 이면 (지양하지만) 라우터 단편화 가능, DF=1 이면 드롭 + ICMP Frag Needed 통지.
   • IPv6: 라우터 단편화 금지 → ICMPv6 Packet Too Big로 송신자 축소 유도.
   • 송신자는 PMTUD/PLPMTUD로 안전한 크기를 학습.

3. 클라이언트 (수신)

   • IP 에서 재조립 (필요 시) → L4 로 인도.
   • TCP 는 순서 재정렬·SACK(Selective ACK) 기반 손실 복구·혼잡제어 수행 / QUIC 은 ACK Ranges로 손실 구간만 재전송.
   • TLS 복호화 후 HTTP 바디를 파일에 기록. rwnd(Receive Window) 및 Window Scaling이 작으면 BDP(대역폭×지연) 대비 병목.

전송 스택별 PDU 흐름

HTTP/2(TCP / TLS 1.3) 기반

1
2

앱 바이트 → [TLS 레코드] → [TCP 세그먼트(MSS)] → [IP 패킷] → [L2 프레임]
손실: TCP 빠른재전송/타임아웃, SACK으로 결손 범위만 재전송 (그러나 연결 단위 HOL 영향)

sequenceDiagram
%% title: large-download-h2-tcp
participant C as Client
participant N as Network (Routers)
participant S as Server
C->>S: TCP 3-way (MSS 협상)
S-->>C: TLS1.3 핸드셰이크(Records)
C->>S: GET /big.iso (HTTP/2)
S-->>C: HTTP/2 DATA (연속) → TLS Records
Note over S,N: TLS 레코드 → TCP 세그먼트(MSS) → IP → L2
loop steady transfer
  S-->>C: [세그먼트 n..n+k]
  C-->>S: ACK/SACK (누락 범위 통지)
end
alt 손실 발생
  N-->>S: (드롭)
  C-->>S: SACK으로 결손 알림
  S-->>C: 손실 세그먼트만 재전송
end

세그먼트 단위로 흐르고, cwnd/rwnd가 충족되면 파이프가 가득 차며, SACK이 부분 손실만 신속 복구한다. PMTUD/PLPMTUD 실패 시 특정 크기에서 멈춤 (블랙홀) 이 발생한다.

HTTP/3(QUIC / UDP / TLS 1.3) 기반

1
2
3

앱 바이트 → [HTTP/3 프레임] → [QUIC 패킷(AEAD)] → [UDP 데이터그램] → [IP] → [L2]
손실: QUIC이 해당 패킷 번호 범위만 재전송, 스트림 단위로 HOL 완화
초기: QUIC Initial 패킷은 경로 안전성 위해 ≈1200B 이상(IPv6 1280B 최소 MTU와 호환 고려)

sequenceDiagram
%% title: large-download-h3-quic
participant C as Client
participant N as Network (Routers)
participant S as Server
C->>S: QUIC Initial (~1200B)
S-->>C: QUIC Initial (1-RTT)
C->>S: GET /big.iso (H3)
loop steady transfer
  S-->>C: H3 DATA frames → QUIC packets
  C-->>S: ACK Ranges (손실 범위 보고)
end
alt 손실 발생
  N-->>S: (드롭)
  S-->>C: 해당 패킷 번호 범위만 재전송 (스트림 HOL 완화)
end

QUIC 은 사용자 공간 전송 + ACK Ranges로 빠른 손실 국지화와 스트림 수준 복구가 가능하다. UDP 경로 특성, PTB 수신 및 PLPMTUD 정책이 안정성을 좌우한다.

캡슐화·역캡슐화—한 번의 온와이어 예 (IPv6/TCP/TLS)

• 가정: MTU 1500B, IPv6(40B) + TCP(20B) + TLS 1.3 오버헤드 ≈21B
• 유효 TCP 페이로드 (=MSS) ≈ 1500 − 40 − 20 − 21 = 1419B
• TLS 레코드가 8KB 라면 MSS 배수로 나뉘어 여러 세그먼트로 전송됨.
• 수신 측은 L2→L3→L4→L7 순으로 헤더 제거 (역캡슐화) 후 원본 바이트를 파일에 기록.

포인트: TLS 레코드 크기가 MSS 와 정렬되지 않으면 여분 세그먼트/패딩·작은 PDU 가 늘어 효율이 떨어질 수 있습니다.

요약

송신 측 캡슐화 (7 단계)

1. TCP 연결 설정 → 3-Way Handshake, MSS 협상
2. HTTP 응답 생성 → 헤더 + 파일 데이터
3. TLS 암호화 → 16 KB 레코드 단위 (HTTPS)
4. TCP 세그먼트화 → MSS 단위 분할 (1460 B)
5. 흐름/혼잡 제어 → 윈도우, Slow Start, ACK
6. IP 캡슐화 → DF=1, PMTUD
7. 이더넷 프레임화 → MAC, FCS

수신 측 역캡슐화 (9 단계)

1. 물리 신호 수신 → 디지털 변환
2. 이더넷 검증 → FCS 체크
3. IP 처리 → 목적지 확인
4. TCP 재조립 → 시퀀스 순서 보장
5. ACK 전송 → 흐름 제어
6. TLS 복호화 → 무결성 검증
7. HTTP 파싱 → 헤더/바디 분리
8. 파일 저장 → 디스크 쓰기
9. 무결성 검증 → MD5/SHA

MTU·MSS·단편화 동작

• MTU(Maximum Transmission Unit, L3 상한)
  • 결정 지점: 인터페이스/NIC, 터널 인터페이스, 라우팅 경로 (최솟값이 Path MTU).
  • 조치: 터널·VPN·오버레이가 있으면 외부 MTU 대비 내부 MTU 하향 필수.
• MSS(Maximum Segment Size, TCP 데이터 상한)
  • 결정 지점: SYN/SYN-ACK 옵션에서 min(MSS) 채택 (중간장비의 MSS 클램핑이 개입 가능).
  • 운용: PMTUD/PLPMTUD 결과에 맞춰 송신자가 세그먼트/레코드 크기 추가 축소.
• 단편화 (Fragmentation)
  • 원칙: 회피. IPv4 는 DF=0 에서만 라우터 단편화 가능 (권장 X), IPv6 라우터 단편화 금지 (송신자만 분할).
  • 실패 신호: ICMP Frag Needed/Packet Too Big. 필터링되면 PLPMTUD로 대체 학습.

처리량을 좌우하는 6 요소

1. cwnd(혼잡 윈도): 혼잡제어 상태 (초기 슬로스타트→회피).
2. rwnd(수신 윈도/Window Scaling): BDP(대역폭×RTT) 에 맞게 충분히 커야 함.
3. RTT(Round-Trip Time): 지연이 클수록 같은 cwnd 로 덜 전송됨 → 패이싱 유효.
4. 손실·재전송: TCP 는 SACK, QUIC 은 ACK Ranges로 손실 구간만 신속 복구.
5. ECN(Explicit Congestion Notification)/DSCP: 드롭 없이 혼잡 신호, 클래스별 QoS.
6. 오프로딩 (TSO/GSO/GRO): CPU/PPS 이득 크지만 캡처 착시 유발 → 경계 캡처로 교차검증.

BDP 산식: BDP(bytes) = Bandwidth(bytes/s) × RTT(s) → rwnd·cwnd·버퍼가 BDP 이상이어야 라인을 채웁니다.

HTTP 계층 특화 (대용량 전송 튜닝)

• Range 요청 + 206 Partial Content: 중단 지점 재개(Resume).
• 병렬 범위 다운로드: 벽시계 단축 가능 (여러 TCP/QUIC 흐름) ↔ cwnd 공정성·서버/경로 부하 고려.
• 캐시/CDN: 엣지 HIT면 경로 짧아지고 손실 위험↓, MISS면 Origin↔Edge 구간에도 동일 PDU 파이프라인이 한 번 더 생김.
• TLS 레코드 크기: 너무 작으면 헤더 비율↑, 너무 크면 손실 시 재전송 비용↑ → 보통 수 KB~수십 KB + MSS 배수 정렬 권장.

관찰 지점별 PDU 맵

TCP 특성이 파일 전송에 미치는 영향

재전송 메커니즘

sequenceDiagram
    participant C as 클라이언트
    participant S as 서버
    
    S->>C: SEQ=1000, DATA[1460B]
    C->>S: ACK=2460
    
    S->>C: SEQ=2460, DATA[1460B]
    Note over C: 패킷 손실!
    
    S->>C: SEQ=3920, DATA[1460B]
    C->>S: ACK=2460 (중복 1)
    
    S->>C: SEQ=5380, DATA[1460B]
    C->>S: ACK=2460 (중복 2)
    
    S->>C: SEQ=6840, DATA[1460B]
    C->>S: ACK=2460 (중복 3)
    
    Note over S: 3 중복 ACK 감지<br/>Fast Retransmit
    
    S->>C: SEQ=2460, DATA[1460B] (재전송)
    C->>S: ACK=8300 (누적 ACK)
    
    Note over C,S: 정상 전송 재개

재전송 시나리오 3 가지:

1. Fast Retransmit (빠른 재전송)

1
2

3개 중복 ACK 수신 → 즉시 재전송
지연: 매우 낮음 (수 ms)

1. Timeout Retransmit (타임아웃 재전송)

1
2
3

RTO (Retransmission Timeout) 초과 → 재전송
지연: 높음 (수백 ms ~ 초)
RTO = SRTT + 4 × RTTVAR

1. Selective Acknowledgment (SACK)

1
2
3
4

정확한 손실 범위 통보:
SACK: 3920-8300 수신 완료
→ 서버는 2460-3919만 재전송
→ 효율적 (불필요한 재전송 방지)

혼잡 제어의 영향

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

다운로드 속도 변화:

초기 (Slow Start):
┌─────────────────┐
│ 시간(초) │ cwnd    │ 속도(Mbps)  │
│   0-0.1  │  10 MSS │    1.2           │
│  0.1-0.2 │  20 MSS │    2.4          │
│  0.2-0.3 │  40 MSS │    4.8          │
│  0.3-0.5 │  80 MSS │    9.6          │
└─────────────────┘

혼잡 회피 (Congestion Avoidance):
┌────────────────┐
│   0.5-1  │ 160 MSS │   19.2     │
│    1-2   │ 240 MSS │   28.8      │
│    2-3   │ 320 MSS │   38.4      │
│    ...   │   ...   │    ...                   │
│   10-11  │ 800 MSS │   96.0    │
└────────────────┘

손실 발생 (시간 11초):
┌────────────────┐
│    11    │ 800 MSS │   96.0       │
│  11.001  │ 400 MSS │   48.0 ↓  │
│  11.1-12 │ 450 MSS │   54.0 ↑  │
│  12-13   │ 500 MSS │   60.0 ↑   │
└────────────────┘

→ 톱니 모양 속도 변화 (Sawtooth Pattern)

MTU 와 MSS 의 실전 영향

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

시나리오 1: 표준 환경 (MTU 1500)
─────────────────────────────────
MSS: 1460 B
1 GB 파일: 732,064 세그먼트
평균 RTT: 50 ms
이론 처리량: 1460 × 8 / 0.05 = 233.6 Kbps (1개 세그먼트/RTT)

실제 처리량 (윈도우 크기 고려):
윈도우: 64 KB = 44 세그먼트
처리량: 44 × 1460 × 8 / 0.05 = 10.3 Mbps

Large Window (256 KB):
처리량: 176 × 1460 × 8 / 0.05 = 41.2 Mbps


시나리오 2: VPN 환경 (MTU 1400)
─────────────────────────────────
MSS: 1360 B (40 B 감소)
1 GB 파일: 786,432 세그먼트 (7.4% 증가)
오버헤드: 40 B × 786,432 = 30.1 MB (3% 증가)

실제 영향:
• 세그먼트 수 증가 → ACK 수 증가
• CPU 부담 증가 (패킷 처리)
• 혼잡 제어 영향 (더 많은 패킷 손실 기회)


시나리오 3: 점보 프레임 (MTU 9000)
─────────────────────────────────
MSS: 8960 B (6.1배 증가)
1 GB 파일: 119,210 세그먼트 (6.1배 감소)
오버헤드: 40 B × 119,210 = 4.6 MB (0.4%)

실제 영향:
• 세그먼트 수 감소 → ACK 감소
• CPU 효율 향상
• 단편화 위험 (경로 MTU 불일치 시 치명적)

실전 시나리오

정상 다운로드

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

타임라인 (1 GB 파일, 100 Mbps 회선):

T=0ms: TCP 연결 설정 (3-Way Handshake)
├─ SYN → (RTT/2)
├─ SYN-ACK ← (RTT/2)
└─ ACK → (RTT/2)
총 소요: 1.5 RTT (예: 75 ms)

T=75ms: TLS 핸드셰이크 (HTTPS)
├─ ClientHello →
├─ ServerHello, Certificate ←
├─ ClientKeyExchange, Finished →
└─ Finished ←
총 소요: 2 RTT (예: 100 ms)

T=175ms: HTTP 요청 전송
└─ GET /video.mp4 HTTP/1.1 →
소요: 0.5 RTT (예: 25 ms)

T=200ms: 데이터 전송 시작
├─ Slow Start: 0.5초 (10 MSS → 800 MSS)
├─ 안정 상태: 10초 (100 Mbps 지속)
└─ 완료: 총 10.7초

T=10.9초: 다운로드 완료
└─ 파일 검증 (MD5): 0.3초

총 소요 시간: 약 11.2초
실효 처리량: 1 GB / 11.2s = 89.3 MB/s = 714 Mbps

패킷 손실 복구

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

시나리오: 1% 패킷 손실률

T=5초: 정상 전송 중 (500 MB 다운로드)
   ↓
패킷 손실 발생 (SEQ=367,000,000)
   ↓
T=5.003초: 3 중복 ACK 수신
   ↓
Fast Retransmit: SEQ=367,000,000 재전송
   ↓
T=5.053초: 재전송 완료 (RTT 50 ms)
   ↓
혼잡 윈도우 감소: 800 MSS → 400 MSS
   ↓
속도 일시 감소: 100 Mbps → 50 Mbps
   ↓
T=5.1초: 회복 시작 (선형 증가)
   ↓
T=5.5초: 정상 속도 복구 (100 Mbps)

손실 영향:
• 지연: 0.5초 추가
• 속도 저하: 0.4초 동안 50% 감소
• 총 영향: 약 0.2초 추가 소요

MTU 불일치 문제

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

상황: 클라이언트 MTU 1500, 중간 경로 MTU 1400

T=0: 연결 설정, MSS=1460 협상
   ↓
T=0.2초: 데이터 전송 시작
├─ IP 패킷 (1500 B) 전송
└─ 중간 라우터 MTU 1400 초과
   ↓
라우터: ICMP "Fragmentation Needed, MTU=1400"
   ↓
T=0.25초: 클라이언트 ICMP 수신
   ↓
[PMTUD 조정]
Path MTU: 1400
MSS: 1400 - 20(IP) - 20(TCP) = 1360
   ↓
T=0.26초: 재전송 (작은 세그먼트)
   ↓
이후 정상 전송 (MSS=1360)

영향 분석:
• 초기 지연: 0.06초
• 세그먼트 수 증가: 7.4%
• 오버헤드 증가: 3%
• 실효 처리량 감소: 약 5%

스트리밍 vs. 파일 다운로드 비교

대용량 파일 다운로드는 TCP 의 신뢰성 메커니즘 (재전송, 순서 보장, 흐름/혼잡 제어) 을 통해 100% 완전성을 보장하며, MTU/MSS 최적화와 병렬 연결로 처리량을 극대화하되, 실시간 스트리밍과 달리 지연보다 완전성을 우선하는 트레이드오프를 선택한다.

핵심 차이점 요약

PDU 구조 비교

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

파일 다운로드 (TCP):
┌──────────────────┐
│ L7: HTTP(200B) + TLS(21B)              │
├──────────────────┤
│ L4: TCP(20-60B) [순서, ACK, 흐름]    │
├──────────────────┤
│ L3: IP(20-40B) [DF=1]                       │
├──────────────────┤
│ L2: Ethernet(18B)                              │
└──────────────────┘
총 오버헤드: 259-339 B
특징: 신뢰성 우선, 오버헤드 높음


스트리밍 (UDP/RTP):
┌──────────────────┐
│ L7: RTP(12B) [시퀀스, 타임스탬프]     │
├──────────────────┤
│ L4: UDP(8B) [포트만]                         │
├──────────────────┤
│ L3: IP(20-40B)                                   │
├──────────────────┤
│ L2: Ethernet(18B)                              │
└──────────────────┘
총 오버헤드: 58-78 B
특징: 저지연 우선, 오버헤드 낮음

네트워크 동작 비교

graph TD
    subgraph TCP["TCP (파일 다운로드)"]
        T1[3-Way Handshake]
        T2[데이터 전송]
        T3[ACK 대기]
        T4[재전송]
        T5[흐름 제어]
        
        T1 --> T2
        T2 --> T3
        T3 -->|손실| T4
        T4 --> T2
        T3 -->|성공| T5
        T5 --> T2
    end
    
    subgraph UDP["UDP (스트리밍)"]
        U1[즉시 전송]
        U2[순서 무시]
        U3[손실 무시]
        U4[지터 버퍼]
        
        U1 --> U2
        U2 --> U3
        U3 --> U4
        U4 --> U1
    end
    
    style TCP fill:#e3f2fd,stroke:#1976d2
    style UDP fill:#e8f5e9,stroke:#388e3c

성능·신뢰·보안 트레이드오프와 튜닝 포인트

표 5-1. 설계/운영 트레이드오프

해설: MTU 상향은 이득이 크지만 경로 호환성·PMTUD 가 관건이다. ECN 은 드롭 없는 혼잡신호로서 점진 확산 중이며, NIC 오프로딩은 성능 향상과 가시성 저하 (패킷 캡처 왜곡) 의 딜레마를 낳는다.

MTU→MSS 계산 & 경계 체크 (교육용)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// 목적: MTU와 IPv4/IPv6 여부로 MSS를 산출하고, 페이로드 초과 여부를 검사
// 입력: mtu(number), ipver(4|6), l4('tcp'|'udp'), extraOverhead(number=0)
// 출력: {mss, maxPayload}
// 예외: 잘못된 입력 시 throw

function mtuToMss(mtu, ipver=4, l4='tcp', extraOverhead=0){
  if (![4,6].includes(ipver)) throw new Error('ipver must be 4 or 6');
  const ip = ipver === 4 ? 20 : 40;
  const l4h = l4 === 'tcp' ? 20 : (l4 === 'udp' ? 8 : 0);
  const base = mtu - ip - l4h - extraOverhead;
  if (base <= 0) return { mss: 0, maxPayload: 0 };
  return { mss: base, maxPayload: base };
}

// 예: IPv6/TCP + TLS(태그 16B + 레코드헤더 5B)
const r = mtuToMss(1500, 6, 'tcp', 21); // ≈142,2B 유효 페이로드

실제 네트워크에서는 VLAN, 터널, 옵션, 보안태그를 extraOverhead 에 반영해 안전한 MSS 를 산출한다. 경계 장비의 MSS 클램핑/PMTUD 동작과 함께 검증해야 한다.

PDU 기반 네트워크 문제 진단 및 최적화

PDU 구조 이해를 활용한 실무 네트워크 트러블슈팅, 성능 최적화, 보안 정책 수립 사례를 다룬다. Wireshark, tcpdump 등 패킷 분석 도구 활용법을 포함한다.

패킷 분석 도구 활용

Wireshark: GUI 기반 패킷 캡처·분석 도구. 계층별 PDU 헤더를 시각적으로 표시하고, 필터링·통계·플로우 추적 기능을 제공한다.
tcpdump: CLI 기반 패킷 캡처 도구. 스크립트·자동화에 적합하며, 원격 서버에서 실시간 캡처·분석이 가능하다.

표: 주요 패킷 분석 도구 비교

Wireshark 필터 예시:

• tcp.port == 80: HTTP 트래픽만 표시
• ip.addr == 192.168.1.1: 특정 IP 주소 관련 패킷
• tcp.flags.syn == 1 && tcp.flags.ack == 0: SYN 패킷만 (3-way handshake 시작)
• frame.len > 1514: Jumbo Frame 탐지

tcpdump 필터 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# HTTP 트래픽 캡처
tcpdump -i eth0 'tcp port 80'

# 특정 IP로/부터 패킷 캡처
tcpdump -i eth0 'host 192.168.1.1'

# SYN 패킷만 캡처 (TCP 플래그 비트마스크)
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0'

# MTU 초과 패킷 탐지 (프레임 길이 > 1514)
tcpdump -i eth0 'greater 1514'

Scapy 로 최소 패킷 생성·송신 (오프라인 실습용 예시)

1
2
3
4
5

# 목적: 로컬 환경에서 학습용으로 ICMP 에코 패킷을 구성
# 주의: 권한/환경에 따라 송신 금지. pcap 파일로만 저장하는 오프라인 흐름 예시
from scapy.all import Ether, IP, ICMP, wrpcap
pkt = Ether()/IP(dst="198.51.100.1")/ICMP()
wrpcap("icmp_echo_min.pcap", [pkt])

해설: Scapy 는 계층을 “/” 로 쌓아 PDU 를 구성한다. 실제 송신·스캔은 법·정책·소유권을 준수해야 하며, 여기서는 파일로 저장해 오프라인 분석만 가정한다.

일반적인 네트워크 문제와 PDU 진단

문제 1: 패킷 손실 (Packet Loss)

증상: 애플리케이션 지연, 재전송 증가, 연결 끊김
PDU 진단 방법:

• Wireshark 에서 tcp.analysis.retransmission 필터로 재전송 패킷 확인
• tcp.analysis.lost_segment 필터로 누락된 세그먼트 탐지
• TCP 순서 번호 (Sequence Number) 불연속성 확인
  원인 및 해결:
• 네트워크 혼잡: QoS 정책 적용, 대역폭 증설
• FCS 오류: ip.checksum_bad.expert 필터로 체크섬 오류 확인 → 케이블·NIC 점검
• 방화벽 정책: 특정 포트·프로토콜 차단 → ACL 검토

문제 2: 높은 지연 (High Latency)

증상: 응답 시간 증가, 실시간 서비스 (VoIP, 게임) 품질 저하
PDU 진단 방법:

• Wireshark 의 “Statistics > Flow Graph” 로 RTT(Round-Trip Time) 측정
• tcp.time_delta > 0.1 필터로 100ms 이상 지연 패킷 찾기
• ICMP Echo Request/Reply 의 타임스탬프 차이 확인
  원인 및 해결:
• 라우팅 경로 비효율: traceroute 또는 mtr 로 경로 확인 → 라우팅 테이블 최적화
• 대역폭 포화: ip.len > 1400 필터로 큰 패킷 탐지 → QoS·트래픽 셰이핑
• DNS 조회 지연: DNS 캐시 설정, 로컬 DNS 서버 사용

문제 3: MTU 불일치 (“Black Hole”)

증상: 작은 패킷은 전달되지만 큰 패킷 (예: 파일 전송) 은 실패
PDU 진단 방법:

• ip.flags.df == 1 && icmp.type == 3 && icmp.code == 4 필터로 “Fragmentation Needed” ICMP 메시지 확인
• 패킷 크기별 전송 성공률 비교 (frame.len > 1400 vs frame.len < 1400)
  원인 및 해결:
• PMTUD 차단: 방화벽이 ICMP Type 3 Code 4 를 차단 → ICMP 허용 규칙 추가
• VPN·PPPoE MTU: MTU 를 1400~1492 로 수동 설정 또는 MSS Clamping 적용
• Jumbo Frame 불일치: 경로 전체에서 Jumbo Frame 지원 확인 또는 MTU=1500 으로 통일

Workshops

OSI 7 계층 캡슐화 실습

시나리오: 실제 HTTP 메시지를 네트워크로 전송할 때, OSI 7 계층을 따라 SDU → PDU, 캡슐화/역캡슐화 과정과 PDU 명칭 변화, 헤더/페이로드 구조를 직접 분석한다.

수행 절차:

산출물:

• 각 계층별 PDU 구조 해설 문서
• Wireshark 캡처 파일
• 단계별 캡슐화/역캡슐화 서식 표

수용 기준 (AC):

• 각 계층의 PDU 명칭/구조 도출
• 캡슐화 흐름에 따른 헤더/페이로드 확인
• SDU→PDU 관계 해설 작성
• 용어/개념 혼동 없는 설명

TCP/UDP 프로토콜별 PDU 분석

시나리오: TCP 와 UDP 로 메시지를 각각 전송/수신할 때, 각 프로토콜별 PDU 구조 차이와 에러 검출 방식, 트러블슈팅 포인트를 코드로 실습한다.

수행 절차:

산출물:

• TCP/UDP 송수신 예제 코드 (댓글 포함)
• PDU 필드 비교 표
• 에러 검출/분석 사례 집합

수용 기준 (AC):

• TCP/UDP 별 PDU 명칭/구조 파악
• 오류 검출 기능 구현/설명
• 트러블슈팅 상황 정리/해설
• 코드 및 프로토콜 비교표 완성

Wireshark 로 PDU 계층 읽기

목표: L2→L7 캡슐화와 필드 관계를 눈으로 확인
절차:

1. tcpdump -s 0 -w trace.pcap 로 캡처
2. Wireshark 로 열기
3. 필터 tcp.flags.syn==1 or icmp 적용
4. 프레임/패킷/세그먼트 길이와 헤더 구조 기록
   지표: 평균 헤더비율 (헤더/전체), PMTUD/ICMP 가시성, 재전송 비율
   산출물: 스크린샷 + 표 1 매 (헤더비율, MSS, MTU 추정)

Wireshark 로 HTTP 트래픽 분석 및 PDU 계층별 디코딩

시나리오: 사용자가 웹 브라우저로 http://example.com/index.html 에 접속할 때, PDU 계층별 헤더를 Wireshark 로 캡처·분석하여 캡슐화 과정을 시각적으로 확인한다.

수행 절차:

산출물:

• Wireshark 캡처 파일 (.pcap)
• 계층별 헤더 필드 기록 표 (예: Ethernet: src_mac=…, dst_mac=…, IP: src_ip=…, dst_ip=…, TCP: src_port=…, dst_port=…, HTTP: method=GET)
• 캡슐화 구조 도식 (Ethernet 프레임 → IP 패킷 → TCP 세그먼트 → HTTP 메시지)

수용 기준 (AC):

• HTTP GET 요청 패킷이 캡처되고 필터링되었는가?
• Ethernet, IP, TCP, HTTP 계층의 주요 헤더 필드 (MAC, IP, Port, Method) 가 정확히 기록되었는가?
• 각 계층이 상위 PDU 를 페이로드로 캡슐화하는 구조가 도식으로 표현되었는가?

Tcpdump 로 MTU 초과 패킷 탐지 및 MSS Clamping 시뮬레이션

시나리오: PPPoE(MTU=1492) 환경에서 표준 MSS(1460) 를 사용하면 IP 단편화가 발생한다. tcpdump 로 MTU 초과 패킷을 탐지하고, MSS Clamping 을 적용하여 단편화를 방지한다.

수행 절차:

산출물:

• tcpdump 캡처 로그 (단편화 전/후 비교)
• iptables MSS Clamping 규칙 스크립트
• 성능 비교 표 (전송 시간, 재전송 횟수)

수용 기준 (AC):

• MTU 초과 패킷이 tcpdump 로 탐지되었는가?
• MSS Clamping 적용 후 IP 단편화가 제거되었는가 (MF=0)?
• 파일 전송 시간이 단축되거나 재전송 횟수가 감소했는가?

MTU·MSS 튜닝 실험 (가상 환경)

목표: MTU 변화가 PDU 오버헤드·처리량에 미치는 영향 관찰
절차:

1. 가상 네트워크에서 링크 MTU 를 1500↔9001 로 교체
2. iperf3 로 TCP/UDP 측정
3. mtuToMss()/max_payload() 로 이론값 산출
4. ICMP 필터링/허용 비교
   지표: 처리량 (Gbit/s), P90 지연 (ms), 재전송률, 블랙홀 발생률
   산출물: 실험노트 (그래프, 설정, 결론)

Final Summary

PDU(Protocol Data Unit) 는 네트워크 프로토콜 스택의 각 계층에서 처리하는 데이터 블록으로, 계층별로 고유한 명칭 (비트·프레임·패킷·세그먼트·데이터) 과 헤더·트레일러 구조를 가지며, 캡슐화·역캡슐화를 통해 계층 간 역할 분리와 독립성을 구현하고, MTU·MSS 협상·PMTUD 등의 메커니즘을 통해 네트워크 성능 최적화와 문제 진단의 기초가 된다.

PDU 는 OSI 7 계층 모델과 TCP/IP 모델에서 각 계층이 다루는 데이터 단위를 의미한다. 물리 계층 (비트), 데이터링크 계층 (프레임), 네트워크 계층 (패킷), 전송 계층 (세그먼트/데이터그램), 상위 계층 (데이터/메시지) 으로 구분되며, 각 계층은 상위 PDU 를 페이로드로 받아 자신의 헤더·트레일러를 추가하는 캡슐화를 수행한다. 이는 1970 년대 네트워크 상호운용성 문제를 해결하기 위해 등장했으며, 현대 네트워크 아키텍처의 근간이 되었다.

PDU 구조는 계층 간 독립성과 확장성을 제공하지만, MTU 제약·단편화·재조립 오버헤드 등의 성능 이슈를 동반한다. IP 단편화는 MTU 불일치를 해결하지만 재조립 부담과 단편 손실 리스크가 크며, PMTUD 는 ICMP 차단 시 Black Hole 문제를 일으킨다. 이를 해결하기 위해 TCP MSS 협상, MSS Clamping, Jumbo Frame, ECN 등의 최적화 기법이 사용되며, 각 기법은 환경 (데이터센터·인터넷·VPN) 에 따라 트레이드오프가 존재한다. 예를 들어, Jumbo Frame 은 데이터센터 내부에서는 효과적이지만 인터넷 구간에서는 사용할 수 없다.

PDU 개념은 전통적인 계층 모델을 기반으로 하지만, SDN(Software-Defined Networking), NFV(Network Functions Virtualization), 5G 네트워크, QUIC 프로토콜 등 새로운 네트워크 패러다임에서는 계층 경계가 모호해지고 있다. 예를 들어, QUIC 는 전송 계층과 응용 계층을 통합하여 UDP 위에서 동작하며, SDN 은 제어 평면과 데이터 평면을 분리하여 계층 간 조작을 동적으로 수행한다. 추가 학습 과제로는 MPLS·VXLAN 등 터널링 프로토콜의 PDU 구조, IPv6 확장 헤더, QUIC 의 프레임 구조, eBPF 를 이용한 커널 레벨 PDU 조작 등이 있다. 실무 프로젝트에서는 Wireshark·tcpdump 를 활용한 패킷 분석, 방화벽·로드밸런서의 Layer 7 PDU 검사, 클라우드 환경 (AWS VPC, Azure VNet) 의 MTU 설정 최적화 등에 PDU 지식을 적용할 수 있다.

Learning Guide

Terminology

References

IETF RFC / 표준 스펙 (1 차 근거)

• RFC 8200: Internet Protocol, Version 6 (IPv6) Specification
• RFC 791: Internet Protocol (IPv4)
• RFC 9293: Transmission Control Protocol (TCP)
• RFC 768: User Datagram Protocol (UDP)
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC 3168: Explicit Congestion Notification (ECN)
• RFC 1191: Path MTU Discovery for IPv4
• RFC 8201: Path MTU Discovery for IPv6
• RFC 4821: Packetization Layer Path MTU Discovery
• RFC 879: TCP Maximum Segment Size
• RFC 7323: TCP Extensions for High Performance
• RFC 1122: Requirements for Internet Hosts
• RFC 7348: VXLAN

IEEE/ISO 표준

• IEEE 802.3-2022: Ethernet (overview)
• IEEE 802.11-2024: WLAN MAC/PHY (overview)
• IEEE 802.1Q: Virtual LANs
• ISO/IEC 7498-1: OSI Reference Model

3GPP / ETSI (모바일 스택 참조)

• 3GPP TS 38.321: NR MAC protocol specification
• 3GPP TS 38.323: NR PDCP specification
• ETSI TS 138 323 V18.5.0 (2025-04)

운영체제/플랫폼 가이드 & 클라우드 문서

• Linux kernel: Segmentation Offloads (TSO/GSO/GRO)
• Microsoft Learn: SetPMTUDiscovery
• AWS EC2: Network MTU & Jumbo Frames
• Google Cloud VPC: MTU & MSS Clamping

도구 매뉴얼

• Wireshark User’s Guide
• tcpdump man page

서적/학술 (1 차·심화)

• Computer Networks (Tanenbaum & Wetherall, 5th Edition)
• TCP/IP Illustrated, Vol. 1 (Stevens)
• The Design Philosophy of the DARPA Internet Protocols (Clark, 1988)
• DCTCP: Efficient Packet Transport for the Commoditized Data Center (Alizadeh et al., 2010)
• Software-Defined Networking: A Comprehensive Survey (Kreutz et al., 2015)

벤더/실무 아티클 (보조)

• Cloudflare Developers: MTU and MSS

입문/용어 해설 (보조—PDU 등)

• Protocol data unit – Wikipedia
• Protocol Data Unit (PDU) – GeeksforGeeks
• 프로토콜 데이터 단위(PDU) – 위키백과(한국어)
• Protocol Data Unit – Lenovo Glossary
• Protocol Data Unit — ScienceDirect Topic Overview
• What is a Protocol Data Unit (PDU)? – TechTarget

PDU 관련 블로그/학습 글 모음

• https://bkkhyunn.github.io/network/3_network/
• https://hoonsb.tistory.com/70
• https://jh7722.tistory.com/94
• https://coconuts.tistory.com/1415
• https://www.professormesser.com/professor-messer-archives/n10-007/protocol-data-units/
• http://www.ktword.co.kr/test/view/view.php?no=310
• https://www.vpnunlimited.com/ko/help/cybersecurity/protocol-data-unit