Как устроена сеть: модели OSI и TCP/IP

← назад к разделу

Когда ваш сервис отправляет HTTP-запрос соседнему сервису, между «дёрнул метод» и «получил ответ» происходит десяток вещей: имя превращается в адрес, устанавливается соединение, данные шифруются, режутся на пакеты, летят через кучу промежуточных узлов и собираются обратно. Держать всё это в голове одной кашей невозможно. Поэтому сеть придумали описывать слоями — каждый слой отвечает за свою задачу и не лезет в чужую.

Есть две такие карты: теоретическая модель OSI (семь слоёв) и практическая модель TCP/IP (четыре слоя), по которой реально работает интернет. Разберёмся с обеими — и дальше вся сеть будет вставать в понятную картину, а не выглядеть магией.

Зачем вообще слои

Идея простая: разбить сложную задачу «передать данные с одной машины на другую» на независимые уровни. Верхний слой не знает и не хочет знать, как работает нижний — он просто пользуется его услугами.

Аналогия — отправка посылки. Вы кладёте вещь в коробку и пишете адрес (это ваша задача). Как коробка доедет — на грузовике, самолёте или велосипеде — вас не волнует, этим занимается служба доставки. А как самолёт держится в воздухе — не волнует уже службу доставки. Каждый уровень доверяет нижнему делать свою работу.

В сети то же самое: ваш код работает с HTTP и JSON, не думая, как байты бегут по проводу. Благодаря этому можно поменять Wi-Fi на кабель, а сервис даже не заметит — сменился только самый нижний слой.

Модель OSI: семь слоёв

OSI (Open Systems Interconnection) — это учебная модель из семи уровней. На практике по ней ничего не построено напрямую, но её знают все, потому что это общий язык: когда инженер говорит «проблема на седьмом уровне» или «это L4-балансировщик», он имеет в виду именно слои OSI.

Слои принято нумеровать снизу вверх: первый — самый близкий к железу, седьмой — к вашему коду. Отсюда и жаргон: «балансировщик четвёртого уровня» работает с портами, «седьмого» — понимает HTTP. Пойдём сверху вниз:

Ваш код живёт на седьмом, прикладном (Application) слое: HTTP, gRPC, SMTP, DNS, запросы и ответы, понятные приложению. Шестой, представления (Presentation), превращает данные приложения в поток байтов и обратно: TLS, кодировки, сжатие; «сертификат не тот» и «кракозябры вместо текста» это здесь. Пятый, сеансовый (Session), поддерживает «диалог» между сторонами и на практике почти растворён в соседних. Четвёртый, транспортный (Transport), доставляет данные между процессами: TCP и UDP, порты; «сервис запущен, а порт закрыт» и «соединение оборвалось посреди ответа» это его слой. Третий, сетевой (Network), это адресация и маршрутизация между машинами, IP; «нет маршрута до хоста» отсюда. Второй, канальный (Data Link), передаёт данные внутри одного участка сети: Ethernet, MAC-адреса, Wi-Fi. Первый, физический (Physical), это провода, радиоволны и оптика, как нули и единицы становятся сигналом; «кабель выдернули» это он.

Запоминать все семь наизусть не нужно. Практически важны четыре: прикладной (ваш HTTP), транспортный (TCP/UDP и порты), сетевой (IP-адреса) и — когда доходит до безопасности — слой с TLS.

Модель TCP/IP: четыре слоя

TCP/IP — это то, по чему интернет работает на самом деле. Она проще и группирует те же задачи в четыре слоя:

Прикладной (Application) слой TCP/IP это HTTP, DNS, gRPC, и сюда же по факту относят TLS: слои 5–7 из OSI, слитые вместе. Транспортный (Transport) это TCP и UDP, ровно четвёртый слой OSI. Межсетевой (Internet) это IP, третий слой OSI. Канальный (Link) это Ethernet, Wi-Fi и драйверы сетевой карты, слои 1–2 OSI вместе.

Когда говорят «стек TCP/IP», имеют в виду именно эту четвёрку. Соответствие с OSI держат в голове только чтобы понимать чужой жаргон вроде «L7-роутинг».

Тут вылезает странность: у TLS как будто два адреса. В списке OSI выше он лежит на шестом слое, «Представления», а в TCP/IP оказался прикладным. Противоречия нет — просто TLS придумали много позже OSI, и ни в один её слой он ровно не ложится. Работает он поверх уже установленного TCP-соединения, обычной библиотекой внутри вашего процесса, а не отдельным уровнем где-то в ядре. Поэтому в статьях про соединения и HTTPS вы встретите формулировку «TLS поверх TCP» — это то же самое, сказанное без оглядки на OSI.

Инкапсуляция: как данные проходят слои

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

Возьмём тот самый HTTPS-запрос со схемы:

1. Прикладной: формируется HTTP-запрос — строка GET /orders/42, заголовки, тело.
2. Шифрование (TLS): содержимое запроса зашифровывается, и дальше вниз уходит уже нечитаемый поток байтов.
3. Транспортный: TCP заворачивает это в сегмент и приписывает порты (например, «от порта 51000 к порту 443») и номера для сборки по порядку.
4. Сетевой: IP заворачивает сегмент в пакет и приписывает IP-адреса отправителя и получателя.
5. Канальный: пакет заворачивается в кадр с MAC-адресами для передачи до ближайшего маршрутизатора.

На другой стороне всё разворачивается в обратном порядке: канальный слой снимает свой конверт и отдаёт наверх, транспортный — свой, и до вашего кода доезжает ровно тот HTTP-запрос, что был отправлен. Каждый слой на приёме общается как бы «напрямую» со своим слоем на отправке, не зная про остальные.

Где это применяется

Эта карта — не абстракция ради экзамена, а рабочий инструмент диагностики. Когда что-то сломалось, первый вопрос инженера: на каком слое проблема?

• Сервис не находит другой сервис по имени — это прикладной слой, скорее всего DNS.
• Соединение устанавливается, но обрывается или тормозит — смотрят транспортный слой, TCP и таймауты.
• «No route to host», пакеты не доходят — сетевой слой, IP и маршрутизация.
• Ошибка сертификата — слой TLS, HTTPS.
• Приходит 404 — это уже прикладной слой, сам HTTP: и адрес нашли, и соединение есть, просто такого пути на сервере нет. А вот 502 и 504 отдаёт посредник на пути — он сам не достучался до сервиса или не дождался ответа. И 500 сплошь и рядом значит, что у сервиса упал уже его собственный вызов куда-то дальше. По номеру статуса «сеть тут ни при чём» не заключают.

Слои дают язык и порядок действий: не «всё сломалось», а «давайте проверим снизу вверх». Отсюда же жаргон балансировщиков — L4-балансировщик работает на транспортном слое (раскидывает TCP-соединения, не заглядывая внутрь), а L7-балансировщик понимает HTTP и умеет роутить по URL. Разницу разбираем в статье про балансировщики.

Где спотыкаются начинающие:

• Пытаются зубрить семь слоёв OSI дословно. Практически нужны четыре; остальное — чтобы понимать чужой жаргон.
• Путают TCP и IP. IP (сетевой слой) доставляет пакет до машины; TCP (транспортный) — до конкретного сервиса на ней и следит за целостностью. Это разные задачи на разных слоях.
• Думают, что TLS — это отдельный протокол вместо HTTP. TLS — это слой шифрования под HTTP: сверху всё тот же HTTP, просто в защищённом конверте.
• При отладке хватаются за верхний слой, хотя причина ниже: например, чинят код, когда на самом деле не резолвится имя.

Почему конверты пересобираются на каждом переходе

Именно здесь метафора конвертов превращается в механику, и без неё непонятно, зачем слои вообще разделили.

Пакет идёт от вашей машины до сервера не напрямую, а через маршрутизаторы — обычно десяток-полтора. И на каждом переходе происходит одно и то же: маршрутизатор снимает канальный конверт (тот, в котором указаны адреса соседних устройств), смотрит на IP-заголовок, решает, куда отправить дальше, и надевает новый канальный конверт — с адресами следующей пары устройств.

Отсюда три следствия, которые стоит держать в голове.

IP-адреса едут насквозь, канальные адреса меняются на каждом шаге. Поэтому сервер видит ваш IP-адрес (или адрес вашего NAT), но никогда не видит канальный адрес вашей сетевой карты — он не уехал дальше первого маршрутизатора.

Транспортный слой и выше по дороге не трогают вовсе. Маршрутизатор не знает, что внутри — TCP или UDP, HTTP или что-то своё. Для него это непрозрачное содержимое, и именно поэтому новый прикладной протокол можно придумать, ничего не меняя в сети.

Счётчик переходов. У пакета есть предел числа переходов, и каждый маршрутизатор его уменьшает; дошёл до нуля — пакет выбрасывается, а отправителю может уйти уведомление. Это защита от петель, и на ней же построен traceroute: он посылает пакеты с намеренно маленьким счётчиком и смотрит, кто ответит.

Чем смотрят каждый слой

Карта слоёв полезна тем, что превращается в лестницу диагностики: каждому слою — свой инструмент.

Правило разбора — снизу вверх: нет смысла читать ответ сервера, если до машины не доходят пакеты. Подробно эта лестница разобрана в статье про диагностику, и порядок шагов там ровно такой.

Когда карта перестаёт работать

Три случая, в которых «слои» складываются друг в друга, и разбор начинает путать.

Туннель или VPN. Весь ваш стек — IP, TCP, HTTP — оказывается содержимым внутри чужого IP-пакета. Практическое следствие: полезная длина пакета уменьшается на размер внешнего конверта, и запросы, которые «работают везде, кроме VPN», обычно упираются именно в это. Плюс маршруты становятся двойными: машина может видеть сервис через туннель и не видеть напрямую.

Прокси уровня приложения. Обратный прокси перед вашим сервисом — это отдельное HTTP-соединение до него и второе от него до вас. Значит, всё, что вы считаете «своим соединением», на самом деле два, у каждого свои таймауты, свои keep-alive и свой адрес источника; и сервер видит адрес прокси, а не клиента (отсюда заголовки с переданным адресом).

Шифрование внутри шифрования. TLS внутри VPN, mTLS внутри TLS-прокси: расшифровать трафик можно только там, где есть ключи, и точек расшифровки в цепочке может быть несколько. Это и объясняет, почему «посмотреть трафик» иногда означает «посмотреть на зашифрованный поток и ничего не понять».

Вывод простой: карта слоёв описывает одно соединение. Как только в цепочке появились туннель или прокси, слоёв становится больше, и разбираться надо по участкам — от клиента до прокси, от прокси до сервиса.

Коротко

• Слои существуют, чтобы каждый уровень решал свою задачу и не зависел от соседних: новый прикладной протокол не требует менять сеть.
• Практически важны четыре: канальный (соседние устройства), сетевой (IP, маршруты), транспортный (TCP/UDP, порты), прикладной (HTTP, DNS).
• На каждом маршрутизаторе канальный конверт снимается и надевается заново, IP-заголовок едет насквозь, а транспорт и прикладной слой по дороге не трогают.
• Каждому слою свой инструмент: ip route и ping — сетевой, ss и telnet — транспортный, curl и dig — прикладной; разбираются снизу вверх.
• TLS — не отдельный протокол, а слой шифрования под HTTP; туннели, прокси и вложенное шифрование добавляют слоёв, и тогда цепочку разбирают по участкам.

Что почитать дальше

Дальше логично спускаться по слоям, которые реально трогает backend:

• IP-адреса, порты и NAT — как пакет находит машину и сервис.
• TCP и UDP — транспорт: гарантии доставки и их цена.
• DNS и HTTP — прикладной слой, с которым работают каждый день.
• HTTPS и TLS — шифрование под HTTP.
• Диагностика сети — та же лестница слоёв, но как порядок разбора инцидента.