TCP и UDP работают на транспортном уровне модели TCP/IP поверх IP, но решают задачу доставки данных противоположными способами. TCP жертвует скоростью ради надёжности и порядка, UDP жертвует надёжностью ради минимальных накладных расходов.
Ни один из протоколов не лучше другого. Выбор зависит от задачи: базе данных нужна гарантия, что ни один байт не потеряется, а видеозвонку важнее не тормозить, даже если пара кадров пропадёт.
TCP (Transmission Control Protocol) впервые описан в RFC 793 в 1981 году. Актуальная спецификация — RFC 9293 от 2022 года, заменившая RFC 793.
Перед передачей данных TCP устанавливает соединение через трёхстороннее подтверждение (three-way handshake): клиент отправляет SYN, сервер отвечает SYN-ACK, клиент подтверждает ACK. Только после этого начинается обмен данными.
Протокол обеспечивает четыре гарантии:
Все эти механизмы делают TCP надёжным. Плата за надёжность — задержка: время уходит на установление соединения, подтверждения и повторные передачи.
UDP (User Datagram Protocol) определён в RFC 768 в 1980 году как протокол передачи датаграмм без установления соединения.
В этом ключевое отличие от TCP: UDP не устанавливает сессию, а отправляет датаграммы независимо друг от друга. Протокол не гарантирует ни доставку, ни порядок, ни защиту от дублирования пакетов. Если датаграмма потеряется в сети, UDP не заметит и не станет её пересылать.
Взамен UDP предлагает минимальный фиксированный заголовок — 8 байт, без handshake, подтверждений и повторных передач. Если приложению нужна надёжность, порядок или защита от дублирования, эту логику приходится реализовывать самостоятельно на уровне приложения.
| Параметр | TCP | UDP |
| Заголовок | минимум 20 байт (без опций) | фиксированные 8 байт |
| Соединение | с установлением сессии (handshake) | без сессии |
| Надёжность доставки | гарантирована (ACK, повторная передача) | не гарантируется |
| Порядок данных | сохраняется (номера последовательности) | не сохраняется |
| Задержка | выше из-за handshake и подтверждений | ниже за счёт отсутствия handshake и подтверждений |
TCP нужен там, где недопустима потеря или искажение данных: передача файлов, электронная почта, работа с базами данных. HTTP и HTTPS до появления HTTP/3 работали именно над TCP.
Общее правило: если целостность данных важнее скорости доставки, выбор — TCP.
UDP подходит там, где важна низкая задержка, а отдельные потери данных не критичны.
По умолчанию используют UDP на порту 53. Протокол переключается на TCP, только если ответ не помещается в датаграмму (об этом сигнализирует флаг TC — truncated).
Устаревший пакет с уже прошедшим моментом видео не нужен получателю — важнее не задерживать поток. RTP, протокол передачи аудио- и видеопотоков в реальном времени, как правило работает над UDP.
Задержка критичнее, чем гарантированная доставка каждого пакета состояния игры.
Использует UDP-порты 67 и 68 для обмена сообщениями между клиентом и сервером при получении сетевых настроек.
Простой протокол передачи файлов, также построенный на UDP.
Современные протоколы всё чаще строят гарантии доставки над UDP, а не используют TCP напрямую. Показательный пример — QUIC: транспортный протокол, работающий поверх UDP и обеспечивающий встроенное шифрование и надёжность доставки (RFC 9000).
QUIC реализует надёжность и шифрование поверх UDP, избегая издержек классического TCP-handshake. HTTP/3 использует QUIC как транспорт вместо TCP. Результат: низкая задержка UDP и гарантии доставки TCP в одном протоколе.
Наши специалисты свяжутся с вами в ближайшее время и ответят на все вопросы.
Будем держать в курсе новостей и облачных трендов
