Транспортный уровень — TCP и UDP
Транспортный уровень (уровень 4 модели OSI) отвечает за передачу данных между приложениями на разных узлах сети. Два основных протокола этого уровня — UDP и TCP — предлагают принципиально разные модели доставки.
UDP (User Datagram Protocol)
UDP (User Datagram Protocol) — это максимально простой транспортный протокол. Его работа сводится к следующему:
- Берётся сообщение приложения.
- К нему добавляется UDP-заголовок с портами отправителя и получателя.
- IP-уровень ниже отвечает за отправку пакета по IP-адресу.
- UDP отправляет датаграмму и не хранит состояние её доставки.
Что UDP не гарантирует:
- Нет подтверждения доставки. Отправив датаграмму, средствами самого UDP нельзя надёжно узнать, дошла она или нет.
- Нет проверки, слушает ли кто-то на том конце. По указанному адресу и порту может не быть работающего сервиса. Иногда система может вернуть ошибку через ICMP, но UDP не даёт надёжного механизма проверки доступности сервиса.
- Нет повторных отправок (ретраев). Если датаграмма потерялась, UDP сам её не перешлёт.
- Нет контроля порядка. Датаграммы могут прийти в другом порядке, а часть из них может не дойти вовсе.
- Нет гарантии полноты доставки. Если приложение отправило 100 датаграмм, UDP не гарантирует, что получатель получит все 100.
При этом UDP всё же содержит checksum — механизм проверки повреждения данных внутри отдельной датаграммы. Но это не делает UDP надёжным протоколом доставки: checksum помогает обнаружить повреждение, но не гарантирует доставку, порядок или повторную отправку.
В UDP нет понятия соединения в том смысле, как оно есть в TCP. Вы просто отправляете датаграммы — и всё. Не нужно предварительно «договариваться» с получателем.
UDP — это как послание в бутылке при кораблекрушении. Вы написали записку, закупорили бутылку, подписали адрес и бросили в море. Море вроде как попытается доставить бутылку, но в общем случае вы не знаете: дойдёт письмо или нет, получит его адресат или не получит.
Два узла могут обмениваться UDP-датаграммами, просто указывая адреса и порты друг друга. Но:
- Порядок прибытия датаграмм неизвестен.
- Полнота доставки не гарантируется.
- Доставка в принципе не гарантируется.
Если нужна более серьёзная логика — подтверждения доставки, контроль порядка, повторная отправка, управление перегрузкой — её придётся реализовывать поверх UDP самостоятельно. Сам UDP ничего такого не предоставляет.
TCP (Transmission Control Protocol)
Название говорит само за себя — это протокол, который активно контролирует процесс передачи.
Главное отличие TCP от UDP — понятие соединения. Прежде чем передавать данные, два участника — клиент и сервер, два сервиса или два приложения — должны это соединение установить.
Установка соединения: handshake
Установка начинается с трёхстороннего рукопожатия (three-way handshake):
- Клиент отправляет серверу TCP-сегмент с флагом SYN.
- Сервер отвечает сегментом SYN-ACK.
- Клиент подтверждает ответ сегментом ACK.
На этом этапе стороны обмениваются технической информацией, чтобы «договориться» о параметрах соединения.
После успешного handshake:
- У клиента в оперативной памяти сохраняется информация о соединении.
- У сервера — аналогичная информация, плюс выделяются ресурсы для обслуживания соединения.
Физически отдельный провод или канал не появляется — просто с обеих сторон хранятся записи о том, что соединение установлено. По этому соединению затем передаётся поток данных. Также могут передаваться служебные TCP-подтверждения, TCP keepalive или сообщения вышестоящего протокола, например WebSocket ping/pong. Пока соединение существует, оно занимает ресурсы с обеих сторон.
Когда соединение установлено, вышележащие протоколы — HTTP, WebSocket и другие — могут обмениваться данными внутри этого TCP-соединения.
Гарантии, которые даёт TCP
TCP предоставляет приложениям надёжный упорядоченный поток байтов. Это важный момент: приложение работает не с отдельными “пакетами TCP”, а с потоком данных. TCP уже сам разбивает этот поток на сегменты, передаёт их по сети и собирает обратно на стороне получателя.
Главные механики TCP:
- Подтверждение получения данных. Получатель отправляет ACK-подтверждения для полученных байтов. Эти подтверждения могут быть кумулятивными: один ACK может подтверждать получение сразу некоторого диапазона данных.
- Контроль порядка. Данные имеют порядковые номера. Получатель может собрать поток в правильной последовательности, даже если отдельные TCP-сегменты пришли не по порядку.
- Повторная передача. Если отправитель предполагает, что часть данных потерялась — например, по таймауту или другим сигналам, — TCP может отправить эти данные повторно.
- Контроль потока и перегрузки. TCP регулирует скорость передачи, чтобы не перегружать получателя и сеть.
Благодаря этим механикам приложения, работающие поверх TCP, получают данные без пропусков, дублей и в правильном порядке — если соединение остаётся работоспособным. Если доставить данные невозможно, соединение завершится ошибкой, и приложение узнает о проблеме.
Это цена, которую мы платим дополнительными сетевыми взаимодействиями, задержками и затратами ресурсов. Но для большинства задач такая надёжность необходима.
Зачем нужен UDP, если есть TCP?
У нас есть два транспортных протокола: TCP — надёжный, с большим количеством встроенных механизмов, и UDP — который на первый взгляд кажется слишком простым. Возникает вопрос: зачем вообще нужен UDP, если есть TCP?
Ответ: UDP проще и часто даёт меньшую задержку.
На TCP «лежит» дополнительная нагрузка:
- Трёхстороннее рукопожатие перед началом передачи.
- Подтверждения получения данных.
- Ретраи потерянных данных.
- Контроль порядка сборки.
- Контроль потока и перегрузки.
Всё это требует времени, памяти и вычислительных ресурсов. Установка соединения тоже не бесплатна: нужно выполнить handshake, сохранить состояние соединения и поддерживать его с обеих сторон.
UDP не нужно этого делать. Он просто отправляет датаграмму и не занимается дальнейшим контролем её судьбы. Поэтому UDP часто выбирают там, где важны простота, низкая задержка или возможность построить собственную логику доставки поверх протокола.
Есть сценарии, где потеря небольшой части данных может быть некритична:
- Стриминг аудио и видео — пропавший фрагмент можно пропустить, качество немного ухудшится, но задержка останется минимальной.
- Видеоконференции и голосовая связь — лучше иногда потерять небольшой фрагмент звука или изображения, чем ждать повторной передачи и получать заметную задержку.
- Онлайн-игры — для некоторых типов данных важнее получить свежую позицию игрока, чем гарантированно доставить старую.
- Сбор аналитики — например, события о кликах пользователя. Потеря небольшой части событий может быть допустимой, если важнее скорость и простота отправки.
Итог:
- Для надёжной и упорядоченной передачи, где важна каждая часть данных — веб-страницы, файлы, API-запросы — часто выбирают TCP.
- Для низкой задержки и простоты, где допустимы отдельные потери или нужна собственная логика доставки — видео, аудио, онлайн-игры, некоторые виды аналитики — часто используют UDP.
Иногда поверх UDP строят собственные протоколы с нужным уровнем гарантий. Например, так устроен QUIC, на базе которого работает HTTP/3. QUIC использует UDP как основу, но сам добавляет соединения, шифрование, потоки, подтверждения, повторную передачу и другие механизмы.