📚 네트워크 · 패킷 분석 › 01. TCP/IP 구조 이해 — 24편
이전 글: 23. OSI 7계층과 TCP/IP 4계층 — 계층으로 읽는 패킷 · 다음 글: 25. Decapsulation
1. 개념
Encapsulation(캡슐화) 은 송신 측에서 데이터가 위 계층에서 아래 계층으로 내려갈 때, 각 계층이 자신의 제어 정보(헤더, 경우에 따라 트레일러)를 앞뒤에 붙이는 과정입니다. 위 계층이 넘긴 데이터 전체는 아래 계층 입장에서 내용물을 해석하지 않는 페이로드(payload) 가 됩니다.
23. OSI 7계층과 TCP/IP 4계층 — 계층으로 읽는 패킷에서 "데이터 → 세그먼트 → 패킷 → 프레임" 순서를 간단히 소개했습니다. 이 글은 그 과정을 바이트 단위와 식별 필드 중심으로 더 구체적으로 다룹니다. 각 단계의 이름(PDU)은 26. PDU란 무엇인가에서 정리합니다.
2. 동작 원리
HTTP 요청 하나가 전송될 때 각 계층이 붙이는 정보는 다음과 같습니다.
[응용] HTTP 요청 데이터
↓ TCP가 헤더를 붙임
[전송] [TCP 헤더 | HTTP 데이터]
↓ IP가 헤더를 붙임
[인터넷] [IP 헤더 | TCP 헤더 | HTTP 데이터]
↓ Ethernet이 헤더와 트레일러를 붙임
[네트워크 접근] [Eth 헤더 | IP 헤더 | TCP 헤더 | HTTP 데이터 | FCS]
↓
비트(신호)로 전송중요한 점은 아래 계층 헤더가 "다음에 무엇이 들어 있는지"를 알려 주는 식별 필드를 가진다는 것입니다. 이 필드가 있어야 수신 측이 올바른 순서로 해석할 수 있습니다.
| 헤더 | 식별 필드 | 대표 값 | 의미 |
|---|---|---|---|
| Ethernet | EtherType | 0x0800 / 0x86DD / 0x0806 | IPv4 / IPv6 / ARP가 들어 있음 |
| IPv4 | Protocol | 6 / 17 / 1 | TCP / UDP / ICMP가 들어 있음 |
| IPv6 | Next Header | 6 / 17 / 58 | TCP / UDP / ICMPv6가 들어 있음 |
| TCP·UDP | Destination Port | 80, 443, 53 등 | 어느 서비스(응용)의 데이터인지 (관례상) |
포트는 "이 서비스일 것"이라는 관례일 뿐, 실제 내용이 그 프로토콜이라는 보장은 없습니다(93. 서비스와 포트 매핑 — 포트 번호만으로 서비스를 단정하면 안 되는 이유).
3. 주요 특징
- 헤더는 오버헤드입니다. 실제 전달하려는 데이터 외에 계층마다 고정 크기 이상의 헤더가 추가됩니다.
| 계층 | 추가되는 것 | 최소 크기 |
|---|---|---|
| 전송 | TCP 헤더 (옵션 포함 시 증가) / UDP 헤더 | 20바이트 / 8바이트 |
| 인터넷 | IPv4 헤더 (옵션 포함 시 증가) / IPv6 기본 헤더 | 20바이트 / 40바이트 |
| 네트워크 접근 | Ethernet 헤더 + FCS (802.1Q 태그 시 +4) | 14 + 4바이트 |
- MTU와 MSS의 관계: 일반 이더넷의 MTU(IP 패킷 최대 크기)는 1500바이트입니다. IPv4 헤더 20바이트와 TCP 헤더 20바이트를 빼면, 한 세그먼트에 담을 수 있는 TCP 데이터(MSS)는 1460바이트입니다. 캡슐화 결과가 MTU를 넘으면 단편화나 전송 실패가 발생합니다(28. MTU와 IP 단편화 — 큰 패킷이 쪼개질 때).
- 터널링은 캡슐화의 반복입니다. VPN, GRE, VXLAN 등은 완성된 패킷 전체를 다시 다른 패킷의 페이로드로 넣습니다. 그만큼 헤더가 늘어나 실제 전송 가능한 데이터 크기가 줄어듭니다.
4. 예시
계산 예시(값은 환경마다 다름): 100바이트짜리 HTTP 요청을 IPv4·TCP(옵션 없음)·Ethernet으로 보낼 때입니다.
HTTP 데이터 100 바이트
+ TCP 헤더 20 → 세그먼트 120
+ IPv4 헤더 20 → 패킷 140 (IP Total Length = 140)
+ Ethernet 헤더 14 → 154
+ FCS 4 → 프레임 158 (회선상 크기)- Wireshark의 Frame Length는 보통 154바이트로 보입니다. FCS는 대부분의 캡처 환경에서 NIC가 제거하기 때문입니다.
- Linux는 TCP 타임스탬프 옵션을 기본 사용하므로 실제 TCP 헤더는 32바이트인 경우가 많습니다. Wireshark의
tcp.hdr_len으로 확인합니다.
실습 예시: 본인 소유 VM에서 헤더 길이를 필드로 확인할 수 있습니다. tshark 설치는 Rocky Linux sudo dnf install -y wireshark-cli, Ubuntu sudo apt install -y tshark 입니다.
sudo tshark -i ens160 -c 5 -f "tcp port 80" \
-T fields -e frame.len -e ip.hdr_len -e ip.len -e tcp.hdr_len -e tcp.len출력 예시(값은 환경마다 다름):
74 20 60 40 0
66 20 52 32 0
166 20 152 32 100첫 줄은 SYN(TCP 옵션이 많아 헤더 40바이트), 셋째 줄은 타임스탬프 옵션이 붙은 32바이트 헤더에 100바이트 데이터가 담긴 경우입니다.
ip.len(IP 패킷 전체) − ip.hdr_len − tcp.hdr_len = tcp.len(실제 데이터) 관계를 확인할 수 있습니다.
5. 보안 관점
- 식별 필드는 송신자가 적는 값입니다. 다른 프로토콜을 흔히 쓰는 포트(80, 443, 53)로 보내 방화벽 정책을 통과하려는 시도가 가능한 이유입니다.
- 터널링은 내부 내용을 가립니다. 허용된 프로토콜 안에 다른 트래픽을 넣는 방식(예: DNS 질의 안에 데이터를 넣는 DNS 터널링)은 바깥 헤더만 보는 장비를 우회할 수 있습니다(144. DNS 악용 유형 — 터널링·DGA·비정상 질의 탐지에서 다룸).
- 캡슐화 계층이 늘어날수록 탐지 장비가 안쪽 헤더까지 해석할 수 있는지가 중요해집니다. 장비가 모르는 캡슐화는 "알 수 없는 페이로드"로만 보입니다.
6. SOC 관점
흔적이 남는 곳
- pcap: 계층별 헤더와 길이 필드 전체
- 방화벽·NetFlow: 바깥쪽 IP·포트·프로토콜과 바이트 수 (안쪽 캡슐 내용은 보통 없음)
- IDS: 해석 가능한 계층까지의 필드와 페이로드
관제자가 확인할 질문
- 포트 번호가 가리키는 프로토콜과 실제 페이로드의 프로토콜이 일치하는가?
- 바깥 헤더 안에 또 다른 IP 헤더(터널)가 들어 있지는 않은가? 허가된 VPN·터널인가?
- 패킷 크기 분포가 해당 프로토콜의 일반적인 모습과 다르지 않은가? (예: DNS 질의가 비정상적으로 큼)
오탐 주의
- 기업 VPN, 클라우드 오버레이 네트워크(VXLAN 등)는 정상적인 캡슐화입니다. 터널 자체보다 허가된 터널인지를 확인해야 합니다.
7. 핵심 정리
- Encapsulation은 송신 측에서 계층마다 헤더(Ethernet은 FCS 트레일러 포함)를 붙이는 과정입니다.
- 위 계층 데이터 전체는 아래 계층에게 해석하지 않는 페이로드입니다.
- EtherType, IP Protocol/Next Header, 포트가 "다음 계층이 무엇인지"를 알려 주는 식별 필드입니다.
- 헤더는 오버헤드이며, MTU 1500에서 TCP MSS가 1460이 되는 이유가 여기에 있습니다.
- 터널링은 캡슐화의 반복이며, 관제에서는 허가된 터널인지와 포트·내용 일치 여부를 확인합니다.
