Encapsulation — путь пакета сверху вниз и обратно

В прошлом уроке мы упомянули, что HTTP-запрос «спускается» через слои TCP, IP, Ethernet и улетает в кабель. На каждом слое к данным добавляется заголовок. Это процесс называется encapsulation (инкапсуляция). На приёмной стороне — обратный процесс decapsulation: заголовки считываются и снимаются, пока не останутся исходные данные.

Encapsulation — одна из самых элегантных идей в дизайне сетей. Она позволяет каждому слою работать с теми данными, которые относятся к нему, и не вникать в смысл данных верхних слоёв. Это и есть конкретное воплощение принципа «уровни абстракции». В этом уроке разберём encapsulation детально, с реальными цифрами и hex-данными.

Encapsulation — основная идея

Представьте письмо в почтовых конвертах. Вы написали текст. Положили в один конверт с пометкой «личное». Этот конверт положили в больший конверт с адресом получателя. Большой конверт положили в почтовый мешок с городом. Мешок — в самолёт.

Каждая обёртка добавляет свою адресную информацию для своего этапа доставки. Самолёт знает только город. Городская почта только адрес дома. Жилец только пометку «личное». Никто не должен видеть текст письма, кроме отправителя и получателя.

Каждый слой видит payload верхнего слоя как «непрозрачные байты» — ему не нужно понимать структуру. TCP не знает, что внутри HTTP. IP не знает, что внутри TCP. Ethernet не знает, что внутри IP. Это и есть принцип абстракции.

С точки зрения размеров:

• HTTP-запрос «GET /index.html HTTP/1.1\r\nHost: example.com\r\n\r\n» — около 40 байт.
• • TCP header (20 байт) = TCP segment 60 байт.
• • IP header (20 байт) = IP packet 80 байт.
• • Ethernet header (14 байт) + CRC (4 байта) = Ethernet frame 98 байт.

Эти 98 байт улетают в кабель.

Заголовки в деталях

Посмотрим, что конкретно лежит в каждом заголовке.

Ethernet frame header (14 байт + 4 байта CRC)

IPv4 packet header (20 байт без options)

TCP segment header (20 байт без options)

Итого: 14 (Ethernet) + 20 (IP) + 20 (TCP) = 54 байта overhead на каждый TCP-segment. Если ваш HTTP-запрос — 100 байт, на проводе летит 154 байт. Если файл 1 МБ — ~1024 пакетов по ~1460 байт payload + 54 байт header’а = ~55 КБ overhead. Это ~5% издержек на заголовки, что приемлемо.

Decapsulation на приёмной стороне

Когда пакет приходит на receiving host, происходит обратный процесс. Каждый слой считывает свой заголовок, делает свою работу, передаёт payload вверх.

Скорость прохождения через стэк — микросекунды на каждый слой. Большая часть времени тратится в очередях OS (interrupt handling, scheduling) и на копирование данных между kernel space и user space. Для performance-критичных приложений есть kernel bypass (DPDK, AF_XDP), но это уже глубокий уровень.

Encapsulation в действии — реальный hex

Соберём всё вместе. Вот реальный hex-dump TCP SYN-пакета, который я только что захватил.

0000  ff ff ff ff ff ff aa bb cc dd ee 00 08 00              <- Ethernet header
0014  45 00 00 28 12 34 40 00 40 06 a1 b2 c0 a8 01 02   c0   <- IPv4 header
0024  a8 01 01 d6 d8 01 bb f0 12 34 56 00 00 00 00 50 02     <- TCP header
0034  00 ff 1c b3 00 00                                        <- TCP header (end)

Разбор побайтно:

Видите — весь TCP SYN-пакет умещается в 54 байта. Из них 14 Ethernet, 20 IPv4, 20 TCP. Полезной нагрузки в этом конкретном пакете нет — SYN это просто запрос «давай установим соединение».

Encapsulation на routers и switches

Когда пакет идёт через сеть, разные узлы по-разному его обрабатывают.

Это иллюстрирует, почему слои так важны: каждое промежуточное устройство смотрит только нужный ему уровень. Switch’у не нужно понимать HTTP. Router’у не нужно понимать TCP. Это позволяет switches быть простыми и быстрыми (миллиарды пакетов в секунду).

Encapsulation в туннелях — inception

В реальных сетях бывают сценарии, когда внутри одного слоя «вложен» другой слой того же уровня. Это туннели.

Примеры:

1. IPsec. Зашифрованный IP-пакет лежит внутри другого IP-пакета. На внешнем уровне — адреса VPN-серверов. На внутреннем — настоящие адреса пользователей. ESP-заголовок между ними.

2. WireGuard. UDP-пакет лежит внутри другого UDP-пакета. На внешнем — VPN-сервер. На внутреннем — зашифрованный пользовательский трафик.

3. GRE. Generic Routing Encapsulation. Любой L3-пакет (IP, ICMP) внутри IP. Используется для туннелей между сайтами.

4. VXLAN. Ethernet-frame внутри UDP-пакета. Используется в overlay-сетях дата-центров (Kubernetes, OpenStack).

5. HTTP/3 (QUIC). Сложнее — TLS внутри QUIC внутри UDP внутри IP. Структура: IP > UDP > QUIC (с встроенным TLS) > HTTP/3 headers > application data.

В Wireshark такие случаи видны как «слой внутри слоя». Например, IPsec-туннель в Wireshark показывает два IP-заголовка подряд.

Попробуй сам

Посмотрите encapsulation на реальном трафике.

# 1. Захватите 10 пакетов на ваш интерфейс
sudo tcpdump -i en0 -c 10 -nn -e -X
# -e показывает Ethernet-заголовки
# -nn не резолвит имена
# -X показывает payload hex

# Вы увидите что-то вроде:
# 18:32:15.123456 aa:bb:cc:dd:ee:ff > ff:ff:ff:...
#   192.168.1.5.54321 > 142.250.185.78.443: TCP ...
#   0x0000:  4500 0028 ...    <- IP header в hex
#   0x0010:  ...               <- payload

# 2. Захватите в файл и откройте в Wireshark
sudo tcpdump -i en0 -c 20 -w /tmp/encap.pcap
# Откройте /tmp/encap.pcap в Wireshark
# Кликните на любой пакет -- увидите дерево слоёв в нижней панели

# 3. Только Ethernet-заголовок
sudo tcpdump -i en0 -c 5 -nn -e | head
# Каждая строка начинается с MAC-адресов

# 4. Размер пакета
sudo tcpdump -i en0 -c 5 -nn -e -l | awk '{print $NF}'
# Покажет размеры пакетов

# 5. Подсчитать заголовки HTTP-запроса
echo -e 'GET /index.html HTTP/1.1\r\nHost: example.com\r\n\r\n' | wc -c
# Около 40 байт application data
# + 20 TCP + 20 IP + 14 Ethernet = 94 байта на проводе

Откройте Wireshark на любой пакет и развернувайте дерево слоёв. Это и есть encapsulation глазами. Каждый слой — отдельная ветка с полями.