OSI / TCP-IP Model

Зачем

«L4 vs L7 load balancer» — топ-5 networking-вопрос на интервью. «Почему ping ходит, а curl нет?» — топ-5 production-incident. Оба требуют одного — mental model слоёв. Без неё непонятно где живут load balancers, firewalls, gateways, application proxies.

OSI/TCP-IP — словарь, на котором написана документация AWS, Cloudflare, Envoy, iptables и каждый incident-постмортем. «У нас L7 retry на ALB не отрабатывает» — экономит пять минут объяснений. «L3-L4 ACL разрешает, L7 WAF режет» — точно описывает где DROP.

Где знание окупается за минуту:

• Выбор балансировщика. NLB (L4) или ALB (L7)? Path-based routing? Sticky sessions по cookie? TLS termination на LB или passthrough? Ответы — в том, какой слой видит балансировщик.
• Debug сети. ping (L3) ходит, nc -zv host 443 (L4) — connection refused. Это не firewall L7, это L4: port закрыт, security group, или service не listen.
• TLS / certificate. TCP handshake done (L4 OK), HTTPS падает с SSL_ERROR_BAD_CERT. Это L6, не «сеть упала», не перезагружай router.
• Service mesh. Envoy / Istio — L7-прокси, видят HTTP/gRPC headers. Для не-HTTP трафика (raw TCP к Postgres, MQTT) большая часть фич отключена.
• Capacity planning. L4 балансировщик держит миллионы коннектов на CPU-µs latency. L7 терминирует TLS, парсит HTTP — на порядок дороже.

Главный takeaway: encapsulation сверху вниз (каждый слой добавляет header), troubleshooting снизу вверх (cable → IP → TCP → TLS → HTTP). Эта пара правил решает 80% повседневного debugging.

Mental model

Каждый слой думает только о своих обязанностях и не заглядывает выше. Application говорит про content, Transport — про reliable delivery, Network — про routing, Data Link — про physical hop, Physical — про сигналы. Соседи общаются через хорошо определённый интерфейс.

Семь слоёв OSI — академическая модель. На практике TCP/IP схлопывает 5/6/7 в один «Application»:

OSI	TCP/IP	Кто здесь	Примеры
7 Application	Application	HTTP, gRPC, DNS, SMTP	curl, browser
6 Presentation	(Application)	TLS, encoding, compression	openssl, JSON
5 Session	(Application)	Сессии (редко выделяют)	—
4 Transport	Transport	TCP, UDP, QUIC	sockets, ports
3 Network	Internet	IP, ICMP, BGP	routers, ping
2 Data Link	Link	Ethernet, Wi-Fi MAC, ARP	switches, NIC
1 Physical	(Link)	электроны/радиоволны	cables, Wi-Fi

Где живёт что:

Компонент	Слой	Что видит
Switch	L2	MAC адреса
Router	L3	IP адреса, routing tables
NLB / L4 firewall / IPVS	L4	5-tuple: src/dst IP+port, protocol
ALB / Nginx / WAF / Envoy	L7	HTTP host, path, headers, cookies, body
TLS termination	L6	encrypted bytes → plaintext

Три железных правила:

1. Encapsulation сверху вниз. App → TLS (шифрованный record) → TCP (seq/ack/port) → IP (src/dst) → Ethernet (MAC) → bits. Матрёшка.
2. Decapsulation снизу вверх. На приёме обратный порядок. Промежуточные устройства разворачивают пакет частично: switch до L2, router до L3, L7 LB до L7.
3. Никто не заглядывает выше. Router не читает HTTP. Switch не читает IP. L4 firewall не читает path. Это архитектурное определение слоя.

«Каждый слой знает только соседей» позволило интернету масштабироваться. Поменять Ethernet на Wi-Fi на 5G, IPv4 на IPv6, TCP на QUIC — HTTP-приложение не заметит.

Что на диаграмме

Три группы — путь HTTP-запроса от sender'а до receiver'а:

• Sender host (слева) — полный 7-слойный стек снизу вверх. На L7 Application висит ADR с обоснованием working model.
• Network path (по центру) — Switch (L2), Router (L3), L4 Firewall / NLB, L7 ALB / WAF / Envoy. Главная группа: показывает, что разные устройства обрабатывают пакет на разных слоях.
• Receiver host (справа) — зеркальный стек, decapsulation снизу вверх.

Edges подписаны тем, что именно едет по проводу: «HTTP body», «TLS record», «TCP segment». Визуально объясняет почему wireshark на L3 показывает «TCP» как payload, а не «HTTP» — HTTP лежит на два слоя выше, внутри TLS внутри TCP.

Сценарии

▶Walkthrough: encap-decap (not found)

Полный путь HTTP-запроса по семи слоям. App пишет GET /index.html. TLS шифрует. TCP оборачивает: src port 54321, dst 443, seq=42. IP оборачивает: src 10.0.1.5, dst 93.184.x.x. Ethernet: dst MAC = next-hop router, не endpoint. NIC модулирует bits.

Switch (L2) видит только MAC, forward'ит. Router (L3) читает dst IP, decrement'ит TTL, переписывает Ethernet header (новый dst MAC) — ключевой момент: MAC переписывается на каждом hop'е, IP — нет. L4 Firewall смотрит на 5-tuple, ACCEPT/DROP без чтения payload. L7 LB терминирует TLS, читает HTTP Host + path, выбирает backend.

На receiver'е симметрично: L1 ловит bits, L2 проверяет MAC, L3 проверяет IP, L4 собирает TCP stream, L6 расшифровывает, L7 handler видит чистый GET /index.html.

▶Walkthrough: l4-vs-l7-lb (not found)

Клиент шлёт два запроса: GET /api/users и GET /static/logo.png на api.example.com.

L4 NLB видит для обоих одно: src 10.0.1.5

→ dst 93.184.x.x, TCP. Payload TLS-encrypted — для L4 это just bytes. Выбирает backend по hash от 5-tuple.

L7 ALB терминирует TLS, читает HTTP. /api/* → api-cluster, /static/* → static-cluster (CDN). Один IP+port, разные backends.

Что не может L4: path routing, sticky sessions по cookie, WAF, JWT validation, header rewriting, retries по HTTP-кодам. Что может L4: любой протокол (gRPC raw, MQTT, mTLS passthrough), миллионы коннектов на µs latency, без сертификатов на LB.

Правило: L7 — если трафик HTTP/gRPC и нужны фичи; L4 — иначе или если важна скорость.

▶Walkthrough: troubleshoot-by-layer (not found)

Методика: снизу вверх, исключая слои.

Симптом 1: curl https://api.example.com/health зависает. L1 cable UP, L2 ARP REACHABLE, L3 ping отвечает. L4 nc -vz host 443 → connection refused. SYN уходит, SYN-ACK нет. Это L4: port закрыт, firewall DROP, или service не listen. ICMP разрешён, TCP 443 — нет. Fix: security group / iptables / ss -tlnp на сервере.

Симптом 2: TCP connect'ится, curl → SSL_ERROR_BAD_CERT. Слои ниже OK. L6 (TLS): openssl s_client -connect host:443 показывает expired cert / wrong SAN / incomplete chain. Fix: обновить cert. Не перезагружай router.

Симптом 3: HTTPS connects, GET /api/x → 502. L1-L6 OK (есть HTTP-ответ). L7 LB не достучался до upstream. Backend down / connection refused. Fix: kubectl logs, /health endpoint, target group health.

90% инцидентов диагностируются за 5 минут такой пробежкой.

Trade-offs (ADR развёрнуто)

ADR на ноде L7 Application фиксирует: учить TCP/IP 4-layer practical stack как working model + знать 7-layer OSI mapping для интервью и vendor docs.

Контекст. OSI разработан в 1980-х как academic reference. Интернет работает на TCP/IP, где OSI 5/6/7 схлопнуты в «Application». В реальном коде ты редко скажешь «это L5» — но cisco/juniper-документация, Tanenbaum и security-литература говорят на семислойном языке. Игнорировать OSI — не понимать половину vendor-доков; учить только OSI — не понимать как реально работает TLS over TCP over IP.

Решение. Working model = TCP/IP 4-layer. Mapping в OSI 7-layer для устных собеседований и старых доков. Главное — «где живёт что»: switch=L2, router=L3, NLB/firewall=L4, ALB/WAF/Envoy/API gateway=L7. Encapsulation сверху вниз, troubleshooting снизу вверх. «Если ping идёт, а curl нет — проблема выше L3».

Что получаем:

• Общий язык с network/security/SRE. Фраза «это L4» сужает поиск с «вся инфра» до «firewall + ports + bind».
• Правильный выбор инструментов. L7 фичи — только на L7 LB. mTLS passthrough требует L4.
• Эффективный debugging. Снизу вверх — 5 минут вместо часа.
• Понимание производительности. L7 балансировщик дороже L4 в десятки раз.

Что платим:

• Когнитивный overhead двух mapping'ов — день на запоминание.
• OSI 5/6 редко самостоятельны — без них не понять старую documentation.
• Реальность размывает границы. QUIC объединяет L4+L6 в один протокол. HTTP/2 multiplexing размывает session-семантику.

Альтернативы:

Подход	Плюсы	Минусы
Только TCP/IP 4-layer	Прагматично	Не читать vendor docs, проваливать интервью
Только OSI 7-layer	Покрывает academic literature	Не отражает реальный стек
Знать оба	Покрывает всё	День на запоминание
«По необходимости»	Минимум усилий	Часами тупишь на инцидентах

Цена — день. Выгода — каждый incident, интервью, design review.

Реальные системы

• AWS NLB — канонический L4. Миллионы коннектов, sub-ms latency, preserve source IP. Используется перед gRPC, базами, mTLS-сервисами.
• AWS ALB — канонический L7. Path/host routing, WAF, HTTP/2, OIDC auth.
• Cloudflare — глобальный L7 reverse proxy + L3-L4 DDoS защита. Magic Transit для L3 защиты /24 сетей.
• Envoy — L7 sidecar, основа Istio. HTTP/1, HTTP/2, gRPC. Retries, circuit breaking на L7-семантике.
• HAProxy — mode tcp (L4) или mode http (L7), переключается.
• Nginx — L7 reverse proxy + LB, с 2015 умеет L4 (stream module).
• iptables / nftables — L3-L4 firewall в Linux kernel.
• AWS Security Groups — L4 firewall, stateful, per-instance. AWS WAF — L7, защита от SQLi/XSS.
• Linux IPVS — L4 в kernel, основа kube-proxy ipvs mode.
• Istio / Linkerd — service mesh, L7-прокси, mTLS на L6/L7.
• API Gateway (Kong, AWS API GW) — L7 с auth, rate limits, request transformation.
• Switch / Router (Arista, Cisco, Juniper) — L2 / L3, в современных DC часто «L3 switch» = switch+router.

Anti-patterns

• «Сеть упала» без слоя. Бесполезный диагноз. Указывай: «L4 connection refused», «L7 5xx», «L3 unreachable».
• L7 LB для не-HTTP трафика. ALB перед raw TCP / Postgres — фичи не работают, латенси как у L7. Используй NLB.
• L4 LB для L7 фич. Хотим sticky sessions по cookie или path routing, а стоит NLB. Переезжай на ALB.
• TLS termination на каждом сервисе при наличии L7 LB или service mesh. Бэкенды должны жить в HTTP. Дублирование = CPU и certificate management hell.
• Путать MAC и IP. «Не пингуется» — L3. «Switch не видит порт» — L2.
• Менять Ethernet, забыв про MTU. VPN/IPSec/VxLAN добавляют headers, MTU 1500 не помещается. Симптом: TCP OK, большие POST зависают. MTU/MSS.
• tcpdump без понимания слоёв. tcpdump 'port 443' покажет TCP+TLS — payload encrypted, HTTP не видно. Нужен SSLKEYLOGFILE или L7 access log.
• ping как proof of life сервиса. ICMP разрешён, TCP закрыт. Используй nc -zv или curl /health.
• L7 retries автоматически безопасны. L7 LB retry'ит POST → если бэкенд успел применить mutation и упасть — double-write. Idempotency keys.
• «Поставим WAF — будет безопасно». WAF (L7) не видит атаки на L3/L4 (DDoS, port scan). Defense in depth.
• mTLS over L7 LB без passthrough. L7 LB терминирует TLS — клиентский cert не доходит до бэкенда. Нужен L4 LB с TLS passthrough.

Когда НЕ использовать

Знание OSI не использовать нельзя — это базовый словарь. Но не каждая задача требует семислойного анализа:

• Personal проект на одном инстансе. Нет балансировщиков, sidecar'ов. Для debugging «почему не работает» — всё равно нужно.
• Чисто application-логика без сети. CLI tool, batch job — нерелевантно.

Где сам OSI как 7-слойная модель уступает TCP/IP:

• Реальный стек — TCP/IP 4-layer. OSI вытаскивается для interview и vendor docs.
• QUIC / HTTP/3 — объединяет L4+L6+часть L7. Семислойная модель плохо описывает.
• WebSocket / gRPC streaming — долгоживущие L7-соединения, классическая «application layer» абстракция не очень.
• Modern eBPF / XDP — L2-L3 в kernel bypass, не вписываются.

Для большинства дискуссий про микросервисы / API / observability — TCP/IP 4-layer и фокус на L7 хватает с головой.

Дальше читать

Книги:

• Tanenbaum, Computer Networks, 5th ed. — классика, глава 1 даёт лучшее объяснение слоёв.
• W. Richard Stevens, TCP/IP Illustrated, Vol. 1 — глубокое погружение с wireshark dumps.
• Kurose & Ross, Computer Networking: A Top-Down Approach — top-down подход.
• Ilya Grigorik, High Performance Browser Networking — https://hpbn.co/, главы 1-4 must-read.

Production docs:

• Cloudflare Learning — OSI Model — короткий точный обзор.
• AWS ELB сравнение NLB vs ALB.
• Envoy Architecture Overview.
• Istio Traffic Management.

RFC:

• ISO/IEC 7498-1 — формальное определение OSI.
• RFC 1122, 1123 — Internet Host Requirements (TCP/IP).
• RFC 9000 — QUIC.

Связанные темы:

• [CONCEPT]tcp-handshake — L4 при установке соединения.
• [CONCEPT]http-protocol — глубже в L7.
• [CONCEPT]load-balancing — L4 vs L7 LB на практике.

Инструменты:

• tcpdump, wireshark — encapsulation своими глазами.
• mtr, traceroute — L3 hop'ы.
• nc -zv, nmap — L4 reachability.
• openssl s_client — debug L6 TLS.
• curl -v — debug L7 HTTP.

Визуализации:

• https://www.practicalnetworking.net/series/packet-traveling/packet-traveling/ — пошагово как пакет идёт через слои с MAC/IP rewriting.