Главное различие: гарантия доставки или минимум накладных расходов
TCP и UDP работают на транспортном уровне и отвечают на один вопрос: как доставить данные от программы на одном узле к программе на другом. TCP сначала устанавливает соединение, нумерует байты, подтверждает получение и повторно отправляет потерянное. Приложение получает упорядоченный поток без пропусков.
UDP ничего этого не делает. Он берёт датаграмму, добавляет короткий заголовок с портами и отправляет её. Дойдёт она или нет, в каком порядке придёт, не задвоится ли, протокол не проверяет. Всю ответственность за это, если она нужна, берёт на себя программа.
Отсюда следует главный компромисс: TCP платит за порядок и надёжность дополнительными подтверждениями и ожиданием, UDP отдаёт контроль приложению и почти не добавляет задержки.
Скорость и задержка: где TCP проигрывает и почему
Само по себе «UDP быстрее» верно лишь отчасти. Пропускная способность на длинных передачах у TCP может быть очень высокой: он подбирает скорость под состояние канала. Но у него есть механизмы, которые создают паузы. Рукопожатие занимает как минимум один обмен туда и обратно до передачи первых данных. Потерянный пакет задерживает всё, что идёт после него, пока не придёт повтор, это называется задержкой из-за очереди (head-of-line).
Для голосового звонка или игры такая пауза хуже, чем пропавший пакет: звук с задержкой в секунду бесполезен, а короткий провал почти незаметен. Поэтому там, где важна свежесть данных, а не полнота, выбирают UDP.
В то же время у UDP нет встроенного контроля перегрузки. Приложение, которое шлёт слишком много, может забить канал и мешать другим, если разработчик не реализовал собственный контроль.
Безопасность, сетевые устройства и совместимость
С точки зрения шифрования протоколы равны: защиту обеспечивают надстройки, например TLS поверх TCP или DTLS и QUIC поверх UDP. Сам транспорт данные не прячет.
Различается поведение сетевых устройств. Межсетевые экраны и NAT хорошо знают TCP: соединение имеет начало и конец, его состояние отслеживается. Для UDP устройство держит запись о «псевдосоединении» ограниченное время, поэтому долгое молчание может привести к её удалению и потере ответов. Программам приходится отправлять периодические пакеты для поддержки.
Есть и практический момент: в некоторых корпоративных и общественных сетях UDP ограничивают или пропускают только отдельные порты, например для DNS. Сервисы, работающие поверх UDP, часто предусматривают запасной вариант через TCP.
Кто что использует на практике
Веб-страницы, электронная почта, передача файлов и удалённый доступ традиционно строятся на TCP: здесь важна целостность. Ошибка в одном байте загруженного архива недопустима.
UDP выбирают для запросов DNS (короткий вопрос и короткий ответ, повтор проще самого рукопожатия), для голосовой и видеосвязи, онлайн-игр, потокового вещания в реальном времени. Современный HTTP/3 строится на протоколе QUIC, который работает поверх UDP, но реализует собственную надёжность и шифрование в пространстве приложения.
То есть граница размывается: UDP всё чаще служит основой для протоколов, которые сами добавляют то, что нужно, и лишь то, что нужно.
Как выбрать при разработке или настройке
Если вы пишете приложение, задайте себе три вопроса. Нужна ли каждая порция данных? Если да, берите TCP или готовый протокол поверх UDP с подтверждениями. Устареют ли данные, пока идёт повторная отправка? Если да, UDP. Готовы ли вы поддерживать логику повторов и контроль скорости? Если нет, не изобретайте её, используйте существующие библиотеки.
Если вы настраиваете сеть или игровую службу, смотрите на документацию сервиса: какие порты и какой протокол ему нужны. Открывать «весь UDP» ради одной игры обычно не требуется.
Если соединение нестабильно, полезнее проверить потери пакетов и задержку, чем менять протокол: обе технологии одинаково страдают от плохого канала, просто проявляется это по-разному.
Типичные ошибки при выборе транспорта
Первая ошибка: считать UDP «ускорителем» и переносить на него передачу, где важна целостность, без собственной проверки. Часть данных потеряется, и приложение будет вести себя непредсказуемо. Вторая ошибка: ставить TCP для потока телеметрии, где нужны только свежие значения, и получать очереди из устаревших измерений при малейшей потере.
Третья ошибка связана с эксплуатацией: открыть порт по одному протоколу и удивляться, что служба не работает, потому что ей нужен другой. Четвёртая: не учесть, что ответы по UDP могут быть отброшены экраном, если приложение долго молчало. При диагностике полезно проверить, какой именно протокол и порт использует сервис, и убедиться, что правила пропускают оба направления.