캡슐화와 역캡슐화

브라우저가 서버에 HTTP 요청을 보낸다고 합시다. 요청이 상대에게 닿으려면 응용 계층에서 시작해 계층을 하나씩 내려가며 각 계층의 정보가 덧붙고, 받는 쪽에서는 아래 계층부터 올라가며 그 정보를 하나씩 벗겨 냅니다. 앞의 과정을 캡슐화(encapsulation), 뒤의 과정을 역캡슐화(decapsulation)라고 합니다. 이 글에서는 이 과정을 실제 바이트로 만들어 보고, 중간의 라우터가 무엇을 바꾸는지까지 따라갑니다.

보내는 쪽: 계층마다 헤더를 붙인다

캡슐화는 데이터가 위 계층에서 아래 계층으로 내려가면서, 각 계층이 자기 일에 필요한 제어 정보를 덧붙이는 과정입니다. 대부분은 데이터 앞에 붙는 헤더(header)이지만, 이더넷처럼 뒤에 오류 검사용 트레일러(trailer)를 붙이기도 합니다.

응용 계층에서 브라우저가 요청 메서드와 URL, 헤더를 담은 HTTP 메시지를 만듭니다. 전송 계층의 TCP는 이 바이트들에 출발지와 목적지 포트, 순서 번호, 확인 번호, 윈도우 크기를 담은 TCP 헤더를 붙여 세그먼트(segment)를 만듭니다. TCP는 응용의 데이터를 바이트의 흐름으로 다루므로, 메시지 하나가 여러 세그먼트로 나뉘거나 여러 메시지가 한 세그먼트에 함께 실릴 수도 있습니다.

인터넷 계층의 IP는 세그먼트 앞에 출발지와 목적지 IP 주소, TTL, 상위 프로토콜의 번호를 담은 IP 헤더를 붙여 패킷(packet)을 만들고, 링크 계층의 이더넷은 패킷 앞에 목적지와 출발지 MAC 주소, 안에 든 프로토콜의 종류(EtherType)를 담은 헤더를, 뒤에 FCS를 붙여 프레임(frame)을 만듭니다. 프레임은 마지막으로 비트가 되어 케이블이나 전파로 나갑니다.

다음 코드는 이 과정을 파이썬의 struct 모듈로 직접 해 봅니다. IP 주소는 문서용으로 정해 둔 예시 주소를, MAC 주소는 임의로 지은 값을 썼습니다. TCP 체크섬은 0으로 두었고, FCS는 보통 네트워크 카드가 붙이므로 넣지 않았습니다.

헤더는 struct.pack()으로 만듭니다. 형식 문자열에서 B는 1바이트, H는 2바이트, I는 4바이트 부호 없는 정수이고, 4s는 4바이트의 바이트열입니다. 맨 앞의 !는 여러 바이트로 된 숫자를 네트워크 바이트 순서, 곧 큰 자리 바이트부터 적는 빅 엔디언으로 담으라는 뜻으로, 이더넷과 IP, TCP 헤더의 숫자는 모두 이 순서로 적습니다.

import struct

def ipv4_checksum(header):
    total = sum(struct.unpack("!10H", header))      # 20바이트 헤더를 16비트씩 더한다
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)      # 넘친 자리는 다시 더한다
    return ~total & 0xFFFF

def mac(text):
    return bytes.fromhex(text.replace(":", ""))

# 보내는 쪽: 위에서 아래로 내려가며 헤더를 붙인다
message = b"GET / HTTP/1.1\r\nHost: example.com\r\n\r\n"                    # 응용: HTTP 메시지
segment = struct.pack("!HHIIBBHHH", 52373, 80, 1, 1, 5 << 4, 0x18, 65535, 0, 0) + message   # 전송: TCP 헤더 20바이트(PSH+ACK)
header = struct.pack("!BBHHHBBH4s4s", 0x45, 0, 20 + len(segment), 0, 0x4000, 64, 6, 0,
                     bytes([192, 0, 2, 10]), bytes([198, 51, 100, 20]))
packet = header[:10] + struct.pack("!H", ipv4_checksum(header)) + header[12:] + segment   # 인터넷: IPv4 헤더 20바이트
frame = mac("aa:bb:cc:dd:ee:01") + mac("00:1a:2b:3c:4d:5e") + b"\x08\x00" + packet         # 링크: 이더넷 헤더 14바이트
for name, unit in (("메시지", message), ("세그먼트", segment), ("패킷", packet), ("프레임", frame)):
    print(f"{name}: {len(unit)}바이트")

# 받는 쪽: 아래에서 위로 올라가며 헤더를 벗긴다
ethertype = struct.unpack("!H", frame[12:14])[0]
print(f"이더넷: {frame[6:12].hex(':')} -> {frame[0:6].hex(':')}, EtherType 0x{ethertype:04x}")
ip = frame[14:]
ihl, total_length, ttl, proto = (ip[0] & 0x0F) * 4, struct.unpack("!H", ip[2:4])[0], ip[8], ip[9]
print(f"IPv4: {'.'.join(map(str, ip[12:16]))} -> {'.'.join(map(str, ip[16:20]))}, TTL {ttl}, "
      f"프로토콜 {proto}, 체크섬 {'정상' if ipv4_checksum(ip[:20]) == 0 else '오류'}")
tcp = ip[ihl:total_length]                         # IP 헤더의 전체 길이까지만 IP의 데이터다
src_port, dst_port = struct.unpack("!HH", tcp[:4])
offset = (tcp[12] >> 4) * 4
print(f"TCP: {src_port} -> {dst_port}, 헤더 {offset}바이트")
print("응용 데이터의 첫 줄:", tcp[offset:].split(b"\r\n")[0])

메시지: 37바이트
세그먼트: 57바이트
패킷: 77바이트
프레임: 91바이트
이더넷: 00:1a:2b:3c:4d:5e -> aa:bb:cc:dd:ee:01, EtherType 0x0800
IPv4: 192.0.2.10 -> 198.51.100.20, TTL 64, 프로토콜 6, 체크섬 정상
TCP: 52373 -> 80, 헤더 20바이트
응용 데이터의 첫 줄: b'GET / HTTP/1.1'

37바이트의 메시지가 계층을 내려가며 20, 20, 14바이트씩 커져 91바이트의 프레임이 되었습니다. 받는 쪽은 EtherType 0x0800을 보고 안에 IPv4 패킷이 들었음을 알고, IP 헤더의 프로토콜 번호 6을 보고 TCP 세그먼트가 들었음을 압니다. 이렇게 각 헤더가 바로 위 계층이 무엇인지 알려 주기 때문에 받는 쪽이 올바른 순서로 헤더를 벗길 수 있습니다. IPv4 헤더의 체크섬은 체크섬 칸까지 포함해 다시 계산하면 0이 나와야 정상입니다.

각 헤더에 든 것

이더넷 헤더

이더넷 헤더는 목적지 MAC 주소 6바이트, 출발지 MAC 주소 6바이트, EtherType 2바이트로 모두 14바이트입니다. EtherType은 안에 든 것이 IPv4이면 0x0800, IPv6이면 0x86DD, ARP이면 0x0806입니다. 프레임 끝의 FCS 4바이트는 받는 네트워크 카드가 검사한 뒤 떼어 내는 경우가 많아서, 패킷 캡처 도구에서는 대개 보이지 않습니다.

IPv4 헤더

TCP 헤더

TCP 헤더의 각 필드가 연결과 흐름 제어에서 어떻게 쓰이는지는 6장에서 자세히 봅니다.

받는 쪽: 아래에서 위로 벗긴다

역캡슐화는 대체로 캡슐화의 반대입니다. 신호가 도착하면 링크 계층이 비트를 프레임으로 되살리고, 목적지 MAC 주소가 자기 것이거나 브로드캐스트인지, FCS가 맞는지 확인한 뒤 헤더와 트레일러를 벗겨 패킷을 인터넷 계층에 올립니다. 인터넷 계층은 목적지 IP 주소가 자기 것인지 보고 IP 헤더를 벗겨 세그먼트를 전송 계층에 올리며, 전송 계층은 주소와 포트로 어느 연결의 데이터인지 가려 해당 소켓에 바이트를 넘깁니다.

실제로는 중간에 할 일이 더 있습니다. FCS가 맞지 않는 프레임은 버리고, 단편화된 IP 패킷은 다시 합치며, TCP는 순서가 뒤바뀐 세그먼트를 정렬하고 빠진 것을 기다립니다. HTTPS라면 TLS가 데이터를 복호화한 뒤에야 HTTP 메시지가 보입니다. 위 코드에서 TCP 세그먼트를 IP 헤더의 전체 길이까지만 잘라 낸 것도 중요한데, 다음 절에서 보듯 프레임 끝에는 IP 패킷에 속하지 않는 바이트가 붙어 있을 수 있기 때문입니다.

작은 패킷과 채움 바이트

이더넷 프레임은 목적지 MAC 주소부터 FCS까지 최소 64바이트여야 합니다. 그래서 데이터가 아주 작으면 모자란 만큼을 0으로 채운 채움 바이트(padding)를 넣습니다.

ETH_HEADER, FCS, IP_HEADER, TCP_HEADER, MIN_FRAME = 14, 4, 20, 20, 64

for data in (1, 10):
    unpadded = ETH_HEADER + IP_HEADER + TCP_HEADER + data + FCS
    frame = max(MIN_FRAME, unpadded)              # 최소 크기보다 작으면 0으로 채운다
    print(f"데이터 {data}바이트: 프레임 {frame}바이트, 채움 {frame - unpadded}바이트, 효율 {data / frame:.1%}")

데이터 1바이트: 프레임 64바이트, 채움 5바이트, 효율 1.6%
데이터 10바이트: 프레임 68바이트, 채움 0바이트, 효율 14.7%

키 하나를 누를 때마다 1바이트를 보내는 원격 터미널이라면, 프레임의 1.6%만 데이터이고 나머지는 헤더와 채움 바이트입니다. 데이터가 10바이트이면 프레임이 이미 64바이트를 넘으므로 채움 바이트가 없습니다. RFC 894에 따르면 채움 바이트는 IP 패킷의 일부가 아니어서 IP 헤더의 전체 길이에 들어가지 않으므로, 받는 쪽은 전체 길이를 보고 IP 패킷이 어디서 끝나는지 알아야 합니다. TCP의 Nagle 알고리즘처럼 작은 데이터를 모아서 보내는 기법은 이런 낭비를 줄이려는 것이지만, 지연이 늘 수 있어 응용의 성격에 맞게 써야 합니다.

라우터를 지날 때 바뀌는 것

캡슐화와 역캡슐화는 양 끝에서만 일어나는 것이 아닙니다. 중간의 라우터도 받은 프레임의 링크 계층 헤더를 벗기고, IP 헤더를 읽어 다음 홉을 정한 뒤, 다음 링크에 맞는 새 링크 계층 헤더를 붙여 내보냅니다.

다음 코드는 PC가 라우터의 A 인터페이스로 보낸 프레임을 라우터가 B 인터페이스를 통해 서버 쪽 링크로 넘기는 과정을 흉내 냅니다.

import struct

def ipv4_checksum(header):
    total = sum(struct.unpack("!10H", header))
    while total > 0xFFFF:
        total = (total & 0xFFFF) + (total >> 16)
    return ~total & 0xFFFF

def with_checksum(header):
    zeroed = header[:10] + b"\x00\x00" + header[12:]
    return zeroed[:10] + struct.pack("!H", ipv4_checksum(zeroed)) + zeroed[12:]

def summary(frame):
    ip = frame[14:34]
    return (f"MAC {frame[6:12].hex(':')} -> {frame[0:6].hex(':')} | "
            f"IP {'.'.join(map(str, ip[12:16]))} -> {'.'.join(map(str, ip[16:20]))} | "
            f"TTL {ip[8]} | 체크섬 0x{struct.unpack('!H', ip[10:12])[0]:04x}")

ip = with_checksum(struct.pack("!BBHHHBBH4s4s", 0x45, 0, 20, 0, 0x4000, 64, 6, 0,
                               bytes([192, 0, 2, 10]), bytes([198, 51, 100, 20])))
pc, router_a, router_b, server = (bytes.fromhex(x) for x in ("001a2b3c4d5e", "aabbccdd0001", "aabbccdd0002", "02aabb000099"))
frame_in = router_a + pc + b"\x08\x00" + ip                   # 첫 링크: PC -> 라우터의 A 인터페이스

ip_out = bytearray(frame_in[14:])                              # 라우터: 링크 헤더를 벗기고
ip_out[8] -= 1                                                 # TTL을 하나 줄인 뒤
frame_out = server + router_b + b"\x08\x00" + with_checksum(bytes(ip_out))   # 체크섬을 다시 계산해 새 프레임에 담는다

print("라우터 앞:", summary(frame_in))
print("라우터 뒤:", summary(frame_out))

라우터 앞: MAC 00:1a:2b:3c:4d:5e -> aa:bb:cc:dd:00:01 | IP 192.0.2.10 -> 198.51.100.20 | TTL 64 | 체크섬 0x4e92
라우터 뒤: MAC aa:bb:cc:dd:00:02 -> 02:aa:bb:00:00:99 | IP 192.0.2.10 -> 198.51.100.20 | TTL 63 | 체크섬 0x4f92

MAC 주소는 링크마다 완전히 바뀌었지만, IP의 출발지와 목적지 주소는 그대로입니다. 링크 계층 헤더는 그 링크 안에서만 쓰는 봉투이고, IP 헤더는 처음부터 끝까지 가는 주소표이기 때문입니다. 그렇다고 IP 헤더가 한 비트도 바뀌지 않는 것은 아니어서, IPv4 라우터는 TTL을 1 줄이고 그에 맞게 헤더 체크섬을 다시 계산합니다. TTL이 0x40에서 0x3F로 줄자 체크섬이 정확히 0x0100만큼 늘어난 것을 볼 수 있습니다. 보통의 라우터는 TCP 헤더와 그 안의 데이터는 건드리지 않으며, NAT나 방화벽, 프록시, 터널 장비는 그보다 깊은 정보를 보거나 주소를 바꾸기도 합니다.

더 깊이: 라우터는 체크섬을 어떻게 빨리 고치나

IPv4 헤더 체크섬은 인터넷 체크섬(Internet checksum)이라 부르는 방식으로 계산합니다. 헤더를 16비트 단위로 끊어 1의 보수 덧셈(one's complement addition)으로 모두 더한 뒤, 그 합의 비트를 뒤집은 값입니다. 1의 보수 덧셈은 맨 위에서 넘친 올림수를 버리지 않고 맨 아래 비트에 다시 더합니다. RFC 1071은 이 덕분에 더하는 순서와 바이트 순서에 상관없이 같은 결과가 나오고, 바뀐 부분만 반영해 고칠 수도 있다고 설명합니다.

앞의 출력에서 체크섬이 0x0100만큼 늘어난 것도 이 성질로 설명됩니다. TTL은 프로토콜 번호와 함께 16비트 단어 하나를 이루면서 그 단어의 위쪽 바이트에 있으므로, TTL이 1 줄면 그 단어는 0x0100만큼 작아지고, 합을 뒤집은 체크섬은 그만큼 커집니다. 그래서 라우터는 헤더 전체를 다시 더하지 않고 바뀐 단어의 옛 값과 새 값만으로 체크섬을 고칩니다. RFC 1624는 옛 체크섬 HC와 바뀌기 전후의 단어 m, m'으로 이 증분 갱신(incremental update)의 식을 HC' = ~(~HC + ~m + m')로 정리하면서, 앞선 RFC 1141의 식은 결과가 0이어야 할 때 0xFFFF를 내는 경우가 있다고 바로잡았습니다.

NAT도 같은 방법을 씁니다. NAT는 주소와 포트를 바꾸므로 IP 헤더 체크섬뿐 아니라, 주소까지 포함해 계산하는 TCP와 UDP의 체크섬도 고쳐야 합니다. RFC 3022는 이때 바꾸기 전후 값의 차이만 체크섬에 더하면 충분하다고 설명합니다.

패킷 캡처로 바이트를 읽기

Wireshark와 tcpdump는 네트워크 인터페이스를 오가는 패킷을 붙잡아 계층별 헤더를 보여 주는 도구입니다. 서버에서는 주로 tcpdump로 캡처하고, 저장한 파일을 Wireshark로 열어 살펴봅니다.

sudo tcpdump -i eth0 -nn -c 5 port 80          # 80번 포트의 패킷 다섯 개를 주소와 포트를 숫자로 보이며
sudo tcpdump -i eth0 -nn -c 1 -XX port 80      # 링크 헤더부터 바이트를 16진수로
sudo tcpdump -i eth0 -w capture.pcap -c 100    # 파일로 저장해 Wireshark에서 열기

인터페이스 이름 eth0은 ip link로 확인해 바꾸어야 하고, 캡처에는 root 권한이 필요합니다. port 80은 포트로 고른 것일 뿐 그 안의 내용이 HTTP라는 보장은 아닙니다. VLAN 태그가 없는 이더넷과 옵션 없는 IPv4, TCP라면 -XX가 보여 주는 바이트는 다음처럼 나뉩니다.

옵션이 있으면 헤더 길이 필드를 읽어 위치를 다시 계산해야 하고, HTTPS라면 TCP 데이터는 암호화되어 있어 HTTP 요청을 읽을 수 없습니다. 장애를 진단할 때도 계층별로 보는 정보가 다릅니다. 링크 계층에서는 MAC 주소와 브로드캐스트, ARP를, 인터넷 계층에서는 IP 주소와 TTL, ICMP 오류를, 전송 계층에서는 포트와 TCP 플래그를, 응용 계층에서는 HTTP 상태 코드나 DNS 응답을 봅니다.

정리

• 캡슐화는 데이터가 계층을 내려가며 계층마다 헤더와 트레일러가 붙는 과정이고, 역캡슐화는 받는 쪽에서 아래부터 헤더를 벗기는 과정입니다.
• 각 헤더는 바로 위 계층이 무엇인지 알려 주어, 받는 쪽이 EtherType과 프로토콜 번호를 보고 올바른 순서로 헤더를 벗길 수 있습니다.
• 이더넷 프레임은 최소 64바이트여서 작은 데이터에는 채움 바이트가 붙으며, 채움 바이트는 IP 패킷에 속하지 않으므로 IP 헤더의 전체 길이로 패킷의 끝을 찾습니다.
• 라우터는 링크 계층 헤더를 새로 만들어 MAC 주소를 바꾸지만, IP의 출발지와 목적지 주소는 그대로 두고 TTL과 체크섬만 고칩니다.
• tcpdump와 Wireshark로 실제 바이트를 계층별로 읽을 수 있으며, 헤더의 길이 필드를 읽어 각 계층의 위치를 정해야 합니다.

연습 문제

1. 데이터가 10바이트라면

옵션이 없는 IPv4와 TCP, 이더넷에서 TCP 데이터가 10바이트인 프레임의 크기, 채움 바이트, 데이터의 비율을 구하세요. 이더넷의 최소 크기 64바이트를 모든 프레임에 더하는 것이 맞나요?

2. 스위치와 라우터를 지나는 주소

PC, 스위치, 라우터의 A 인터페이스가 첫 번째 이더넷 링크에, 라우터의 B 인터페이스와 서버가 두 번째 이더넷 링크에 있습니다. NAT도 터널도 없습니다. PC가 서버에 보낸 패킷이 스위치를 지날 때 목적지 MAC 주소가 서버의 것으로 바뀌나요? 라우터를 지난 뒤의 MAC 주소와 IP 주소, TTL은 어떻게 되나요?

3. 전체 길이를 무시하면

본문 코드의 받는 쪽에서 ip[ihl:total_length] 대신 ip[ihl:]로 TCP 세그먼트를 잘라 낸다고 합시다. 데이터가 1바이트여서 프레임 끝에 채움 바이트 5개가 붙은 경우, 응용 프로그램은 무엇을 받게 되나요?

다음 장의 물리 계층의 역할에서는 계층 구조의 가장 아래에서 비트가 전기와 빛, 전파의 신호로 바뀌어 전달되는 과정을 살펴봅니다.