TCP/IP и OSI: фундамент всего

Каждый раз когда открывается веб-страница, браузер выполняет TCP handshake за 20-200 мс, данные проходят через все 7 уровней OSI - дважды. Это происходит так быстро, что незаметно. Но когда что-то ломается: медленный сайт, падающий WebSocket, нерезолвящийся DNS - понимание этих уровней становится единственным способом найти проблему.

• **Cloudflare** обрабатывает 55+ млн HTTP-запросов в секунду - каждый начинается с TCP handshake (или QUIC поверх UDP для HTTP/3)
• **Zoom** использует UDP для видео и аудио - задержка от TCP retransmission (100-300 мс) убивает качество звонка
• **Google** сэкономил миллиарды запросов, переведя трафик на HTTP/3 (QUIC поверх UDP) - прирост 8% скорости при потерях пакетов

Предварительные знания

• How Services Communicate

TCP/IP: рождение в условиях Cold War

В 1974 году Винтон Серф и Боб Кан опубликовали «A Protocol for Packet Network Intercommunication» по заказу DARPA. Ключевое требование от военных: сеть должна продолжать работать при уничтожении части узлов. Этим объясняется packet-switching вместо circuit-switching: нет единой линии связи, которую можно перерезать. TCP/IP стал стандартом интернета в 1983 году, когда ARPANET переключился с NCP на новый стек.

Модель OSI: 7 уровней сети

Cloudflare обрабатывает 55+ млн HTTP-запросов в секунду. Каждый из них проходит через все 7 уровней модели OSI - дважды. В нормальной работе это незаметно. Когда что-то ломается: медленный сайт, падающий WebSocket, нерезолвящийся DNS - понимание уровней становится единственным способом найти проблему.

**OSI (Open Systems Interconnection)** разбивает сетевое взаимодействие на 7 слоёв. Каждый уровень решает одну задачу и ничего не знает о деталях остальных. Как почтовая система: автор пишет письмо (уровень 7), кладёт в конверт (уровень 6), относит на почту (уровень 5), почта сортирует (уровень 4), грузит в машину (уровень 3), машина едет по дороге (уровень 2), дорога существует физически (уровень 1).

На практике чаще используют модель **TCP/IP** с 4 уровнями: Link (1-2), Internet (3), Transport (4), Application (5-7). OSI - теоретическая модель для понимания, TCP/IP - реальная архитектура интернета.

Backend-разработчик работает на уровнях 4-7. REST API - уровень 7 (Application). Выбор TCP или UDP - уровень 4 (Transport). Настройка TLS - уровень 6 (Presentation). Уровни 1-3 обеспечиваются инфраструктурой.

Каждый уровень добавляет свой **заголовок** к данным - это **инкапсуляция**. HTTP-запрос оборачивается в TCP-сегмент, тот - в IP-пакет, тот - в Ethernet-фрейм. На принимающей стороне оболочки снимаются в обратном порядке.

TCP vs UDP: надёжность или скорость

Zoom использует UDP для видео и аудио. Задержка от TCP-retransmission (100-300 мс) убивает качество звонка. Google сэкономил миллиарды запросов, переведя трафик на HTTP/3 (QUIC поверх UDP) - прирост 8% скорости при потерях пакетов. Выбор протокола на уровне 4 - не технический нюанс, а архитектурное решение с бизнес-последствиями.

**TCP (Transmission Control Protocol)** - надёжная доставка. Как заказное письмо: гарантия доставки, уведомление о получении, повторная отправка если потерялось, данные приходят в правильном порядке. Цена - дополнительные задержки.

**UDP (User Datagram Protocol)** - быстрая доставка без гарантий. Как листовка в почтовый ящик: отправил и забыл. Нет подтверждения, нет гарантии порядка, нет повторной отправки. Зато минимальные задержки и overhead.

HTTP/1.1 и HTTP/2 работают поверх TCP. HTTP/3 (QUIC) - революция: работает поверх **UDP**, но реализует надёжность на уровне приложения. Это даёт скорость UDP с гарантиями TCP, без его ограничений (head-of-line blocking).

Выбор между TCP и UDP зависит от того, что важнее: **целостность данных** или **минимальная задержка**. Для API-запроса потерянный пакет = сломанный ответ, поэтому TCP. Для видеозвонка потерянный кадр = микро-заикание, которое лучше пропустить, чем ждать повторной отправки.

TCP Handshake: тройное рукопожатие

HTTP/1.1 на каждый запрос делал новый TCP handshake. При RTT 100 мс (клиент - сервер в другом регионе) - только установка соединения занимала 150 мс до первого байта данных. Это и породило keep-alive, HTTP/2 multiplexing, а потом QUIC. Понять почему - значит понять TCP handshake.

**SYN** - клиент отправляет начальный sequence number. **SYN-ACK** - сервер подтверждает и отправляет свой sequence number. **ACK** - клиент подтверждает sequence number сервера. Теперь оба знают номера друг друга и могут отслеживать порядок пакетов.

**Sequence numbers** генерируются случайно (не с нуля) для защиты от TCP sequence prediction атак. Если бы номера начинались с 0, злоумышленник мог бы подделать пакеты, угадав номер.

Handshake - это overhead. При RTT 50 мс (Москва - Лондон) только установка соединения занимает 75 мс. Поэтому в HTTP/1.1 используется **keep-alive** (переиспользование соединения), а HTTP/2 мультиплексирует запросы в одном соединении.

Сокеты и порты

nginx на порту 443 обрабатывает 10 000 одновременных соединений. При этом сервер занимает ровно один порт. Как? IP-адрес идентифицирует **машину**. Но на одной машине может работать десяток сервисов: веб-сервер, база данных, SSH, почта. ОС понимает, какому процессу отдать входящий пакет, через **порты**.

**Порт** - 16-битное число (0-65535), идентифицирующее конкретный процесс на машине. IP + порт = уникальный адрес процесса в сети. Как номер квартиры в доме: IP - адрес дома, порт - номер квартиры.

**Сокет** - комбинация IP-адреса и порта, endpoint для сетевого взаимодействия. TCP-соединение уникально определяется **4-tuple**: (client_IP, client_port, server_IP, server_port). Один серверный порт (например, 443) обслуживает **тысячи** одновременных соединений - у каждого клиента свои IP и ephemeral port.

При запуске NestJS на порту 3000 создаётся server socket, привязанный к `0.0.0.0:3000`. Каждый входящий HTTP-запрос - новый client socket с уникальной парой (client_ip, client_port).

Сокеты и порты - фундамент для всего, что будет дальше. Каждый HTTP-запрос, gRPC-вызов, WebSocket-соединение - это сокеты на транспортном уровне. Разница только в том, что происходит **внутри** этих соединений на уровне Application.

Ключевые выводы

• **Модель OSI** делит сеть на 7 уровней - backend-разработчик работает на уровнях 4-7 (Transport - Application)
• **TCP** гарантирует доставку и порядок данных ценой дополнительного overhead (handshake, ACK). **UDP** - минимальный latency, без гарантий
• **TCP three-way handshake** (SYN - SYN-ACK - ACK) устанавливает соединение за 1.5 RTT перед передачей данных
• **Socket = IP + Port** - уникальный endpoint в сети. Один серверный порт обслуживает тысячи соединений благодаря 4-tuple

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

TCP/IP - фундамент, на котором строятся все протоколы прикладного уровня:

• Transport Overview — Все транспорты из предыдущего урока работают поверх TCP или UDP
• Serialization — Данные, передаваемые по TCP/UDP, должны быть сериализованы в байты
• DNS and TLS — DNS (UDP) резолвит домены в IP, TLS (поверх TCP) шифрует соединение

Вопросы для размышления

• При запуске локального сервера на порту 3000 и открытии localhost:3000 в браузере - какие шаги TCP handshake происходят, хотя клиент и сервер на одной машине?
• Почему HTTP/3 перешёл с TCP на UDP (QUIC), если TCP надёжнее? Какую проблему TCP это решает?
• При проектировании протокола для IoT-датчиков температуры, отправляющих показания каждую секунду - TCP или UDP? Почему?

Связанные уроки

• bt-01-overview — Обзор транспортов задаёт контекст для понимания TCP/IP
• bt-03-serialization — Сериализация - следующий уровень: что передаётся внутри TCP
• bt-04-dns-tls — DNS (UDP) и TLS (TCP) строятся на понятиях этого урока
• sec-01 — TLS и сетевая безопасность начинаются с понимания TCP handshake
• devops-05 — Диагностика сети в devops: tcpdump, netstat - работа на уровне сокетов
• web-01 — HTTP - application-layer протокол поверх TCP, изученного здесь
• net-15-tcp-basics