TCP и UDP: в чём разница и почему это не вопрос «что лучше»

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

Звучит так, будто UDP хуже. Но за надёжность TCP платят временем: установление соединения, подтверждения, ожидание, повторы. Там, где данные устаревают быстрее, чем их успеют переслать, эта цена бессмысленна — переданный с опозданием фрагмент разговора не нужен никому.

Есть и второй аргумент в пользу UDP: он не хранит состояния. Сервер, обслуживающий десятки тысяч коротких запросов, не обязан помнить о каждом клиенте — это радикально экономит память и позволяет держать нагрузку, при которой TCP давно бы захлебнулся.

Перед передачей данных стороны TCP обмениваются тремя короткими пакетами. Клиент отправляет SYN — предложение установить соединение вместе со своим стартовым номером последовательности. Сервер отвечает SYN-ACK: подтверждает и присылает свой номер. Клиент отвечает ACK. Всё, соединение установлено.

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

Как закрывается соединение

Закрытие устроено симметрично и требует четырёх пакетов: каждая сторона отдельно сообщает, что больше передавать не будет, и получает подтверждение. Поэтому соединение может быть полузакрытым — одна сторона уже всё отправила, вторая ещё досылает. Именно это состояние вы видите в списке соединений как CLOSE_WAIT.

Что это даёт в диагностике

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

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

UDP берут там, где важнее темп: голос и видео, игры, потоковое вещание, телеметрия, синхронизация времени. В разговоре потерянный фрагмент проще пропустить, чем вставить с опозданием. DNS попал в этот список по другой причине — запрос и ответ помещаются в один небольшой пакет, и устанавливать ради этого соединение дороже, чем при неудаче просто спросить ещё раз.

Граница размывается

Классическое деление сегодня уже не такое строгое. Протокол QUIC, на котором работает HTTP/3, построен поверх UDP — но при этом сам реализует надёжную доставку, порядок и шифрование. Разработчики просто вынесли логику из ядра операционной системы в приложение, чтобы её можно было развивать быстрее и не ждать, пока обновится весь интернет.

Практический вывод для администратора: трафик на UDP-порт 443 — это, скорее всего, не подозрительная активность, а обычный браузер. И если QUIC заблокировать, браузеры молча откатятся на TCP, а пользователи заметят только то, что «стало чуть медленнее».

• Потери выглядят по-разному. У TCP они превращаются в падение скорости и подвисания, у UDP — в щелчки в звуке и артефакты в видео. Скорость при этом формально остаётся прежней.

• Правила фаервола не универсальны. Открывая порт, нужно указывать протокол: правило для TCP не пропустит UDP-трафик. Классическая причина «порт открыт, но не работает».

• Проброс портов для игр и голосовой связи. Почти всегда требуется именно UDP — и это первое, что стоит перепроверить.

• Сессии на роутере. Для TCP роутер понимает, когда соединение закрылось. Для UDP такого признака нет, и запись держится по таймауту — отсюда обрывы долгих UDP-сессий, в которых давно ничего не передавалось.

• UDP проще подделать. Соединения нет, состояния нет, адрес отправителя можно указать любой. Поэтому открытые наружу UDP-службы — отдельная тема для размышлений: их регулярно используют для усиления атак.

Вопрос возникает, как только дело доходит до собственного сервиса — от телеметрии с датчиков до обмена данными между серверами. Общее правило простое: берите TCP, пока не появилась конкретная причина взять UDP.

• Данные нужны целиком и в порядке, объём заметный — TCP.

• Короткий запрос и короткий ответ, потерю можно просто повторить — подойдёт UDP.

• Поток реального времени, устаревшие данные бесполезны — UDP.

• Нужна отправка сразу многим получателям — только UDP, у TCP многоадресной рассылки нет.

Выбрав UDP, учтите: всё, что TCP делает за вас, придётся делать самому. Нумеровать сообщения, если важен порядок. Повторять отправку, если ответ не пришёл. Следить за темпом, чтобы не забивать канал. Это не страшно, но объём работы обычно недооценивают — и в итоге получают собственный, менее надёжный TCP.

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