TCP и UDP: в чём разница и когда какой протокол выбирать

Обновлено 28 сентября 2026 г.

8 сентября 2026 г.

Александр Иванов

Автор статьи

TCP и UDP работают на транспортном уровне поверх IP и по-разному решают задачу доставки данных. TCP гарантирует, что данные дойдут целиком и в исходном порядке, и платит за это задержкой. UDP отправляет данные сразу и ничего не гарантирует. Разбираем, как устроены оба протокола, сравниваем их по девяти критериям и показываем, какой выбрать для приложения, сервиса в облаке и балансировщика нагрузки.

Главное

Выбирайте TCP, если потеря или перестановка данных недопустима: базы данных, API, передача файлов, почта. Выбирайте UDP, если важнее низкая задержка, а потерю отдельного пакета приложение переживёт: голос, видеозвонки, игры, DNS-запросы.
TCP перед передачей данных устанавливает соединение за один круг обмена (round trip), подтверждает каждый сегмент и повторно отправляет потерянные. UDP отправляет датаграмму без соединения и не узнаёт, дошла ли она.
Заголовок TCP занимает минимум 20 байт, заголовок UDP всегда 8 байт.
QUIC и HTTP/3 работают поверх UDP и сами обеспечивают надёжность, шифрование и контроль перегрузки. Поэтому UDP сегодня несёт и веб-трафик, который раньше шёл только по TCP.

Как работает TCP

TCP (Transmission Control Protocol) впервые описан в RFC 793 в 1981 году. Действующая спецификация RFC 9293 вышла в 2022 году и заменила RFC 793.

Перед обменом данными TCP устанавливает соединение через трёхстороннее рукопожатие (three-way handshake): клиент отправляет SYN, сервер отвечает SYN-ACK, клиент подтверждает ACK. Данные начинают передаваться только после этого.

TCP дает приложению четыре гарантии:

Надёжная доставка. Получатель подтверждает принятые данные через ACK. Если подтверждение не пришло, отправитель передаёт сегмент повторно.
Порядок. По номерам последовательности получатель собирает данные в исходном порядке, даже если сегменты пришли вразнобой.
Контроль потока. Механизм скользящего окна (sliding window) ограничивает объём данных, которые отправитель передаёт без подтверждения. Медленный получатель не захлёбывается.
Управление перегрузкой. Алгоритмы медленного старта и предотвращения перегрузки (congestion avoidance) снижают скорость, когда сеть загружена. Для приложения TCP выглядит как непрерывный поток байтов. Границ сообщений в нём нет: если отправитель записал в сокет два сообщения по 100 байт, получатель может прочитать их одним блоком в 200 байт или тремя кусками. Разделять сообщения должен протокол приложения, например HTTP через заголовок Content-Length.

Как работает UDP

UDP (User Datagram Protocol) описан в RFC 768 в 1980 году. Он отправляет датаграммы без установления соединения, каждую независимо от других.

UDP не гарантирует доставку, порядок и отсутствие дублей. Если датаграмма потерялась, отправитель об этом не узнает и повторять её не будет. Зато UDP сохраняет границы сообщений: одна отправленная датаграмма приходит как одна датаграмма или не приходит вовсе.

Заголовок UDP фиксированный, 8 байт: порт отправителя, порт получателя, длина и контрольная сумма. Всё остальное, что нужно приложению (подтверждения, порядок, повторы), оно реализует само.

TCP и UDP: сравнительная таблица

Сравнение основано на спецификациях IETF: RFC 9293 для TCP, RFC 768 для UDP.

Критерий	TCP	UDP
Соединение	Устанавливается рукопожатием до передачи данных	Не устанавливается
Гарантия доставки	Есть: подтверждения и повторная передача	Нет
Порядок данных	Сохраняется по номерам последовательности	Не сохраняется
Модель данных	Поток байтов без границ сообщений	Отдельные датаграммы, границы сохраняются
Контроль потока и перегрузки	Встроен	Нет, реализует приложение
Размер заголовка	От 20 до 60 байт	8 байт
Задержка до первого байта данных	Минимум один круг обмена на рукопожатие, плюс TLS	Данные уходят с первым пакетом
Broadcast и multicast	Нет, только соединение двух узлов	Поддерживает
Что работает поверх	HTTP/1.1, HTTP/2, SSH, SMTP, протоколы СУБД	DNS, DHCP, RTP, NTP, QUIC и HTTP/3

Ограничения обоих протоколов

TCP

Задержка на установку соединения. С TLS 1.3 до первого байта полезных данных проходит минимум два круга обмена: один на TCP, один на TLS.
Блокировка очереди (head-of-line blocking). Если один сегмент потерян, TCP держит все следующие данные, пока не получит его повторно. Для HTTP/2, где много запросов идут по одному соединению, потеря одного пакета тормозит все запросы сразу.
Каждое соединение хранит состояние на сервере. Миллионы коротких соединений требуют памяти и тюнинга ядра.

UDP

Надёжность, порядок и контроль перегрузки придётся писать самостоятельно или брать готовый протокол вроде QUIC.
Датаграмма больше MTU пути фрагментируется на уровне IP. Если потерялся один фрагмент, теряется вся датаграмма. Поэтому протоколы поверх UDP ограничивают размер: для DNS с 2020 года рекомендуют буфер не больше 1232 байт (DNS Flag Day), а QUIC не отправляет пакеты больше 1200 байт, пока не проверит MTU пути.
UDP используют для DDoS-атак с усилением (amplification): злоумышленник отправляет короткий запрос с поддельным адресом жертвы, а сервер (DNS, NTP, memcached) отвечает жертве в десятки раз большим объёмом.
Часть корпоративных сетей и NAT-шлюзов ограничивает или блокирует UDP. Приложению нужен запасной путь через TCP.

Когда выбирать TCP

TCP подходит, когда целостность данных важнее скорости:

базы данных и репликация;
REST и gRPC API;
передача файлов, резервное копирование в объектное хранилище;
почта (SMTP, IMAP), SSH, удалённое администрирование;
веб-трафик по HTTP/1.1 и HTTP/2.

Когда выбирать UDP

UDP подходит, когда задержка важнее гарантий доставки или когда нужен собственный транспорт поверх него.

DNS. Запросы по умолчанию идут по UDP на порт 53. Если ответ не помещается в датаграмму, сервер ставит флаг TC (truncated), и клиент повторяет запрос по TCP. Передача зон между DNS-серверами идёт только по TCP.

Голос и видео в реальном времени. Пакет с кадром, который уже должен был отобразиться, получателю не нужен: повторная передача только увеличит задержку. Поэтому медиапотоки передают по RTP поверх UDP, в том числе в WebRTC.

Онлайн-игры. Актуальное состояние игры важнее каждого промежуточного пакета. Игровые движки обычно используют UDP и сами решают, какие сообщения подтверждать, а какие можно потерять.

Служебные протоколы. DHCP использует UDP-порты 67 и 68 для выдачи сетевых настроек, NTP синхронизирует время по UDP на порту 123, TFTP передаёт файлы (например, образы для сетевой загрузки) поверх UDP.

QUIC и HTTP/3: надёжность поверх UDP

QUIC (RFC 9000, 2021) работает поверх UDP и берёт на себя то, что раньше давал TCP: подтверждения, повторную передачу, порядок и контроль перегрузки. Шифрование TLS 1.3 встроено в протокол, поэтому соединение с шифрованием устанавливается за один круг обмена вместо двух, а при повторном подключении данные можно отправить сразу.

Главное отличие от TCP: внутри одного соединения QUIC передаёт независимые потоки. Потеря пакета задерживает только свой поток, остальные продолжают работать. HTTP/3 (RFC 9114, 2022) использует QUIC как транспорт и тем самым решает проблему блокировки очереди, которая была у HTTP/2 поверх TCP.

QUIC работает в пространстве пользователя, поэтому его обновляют вместе с приложением или браузером. Если сеть блокирует UDP на порту 443, браузер возвращается к HTTP/2 по TCP.

стек HTTP/2 поверх TCP и HTTP/3 поверх QUIC и UDP

Как проверить, какой протокол использует приложение

Какие порты слушает сервер и по какому протоколу: bash

ss -tulpn

Флаг -t показывает TCP, -u показывает UDP, -l оставляет только слушающие сокеты, -p выводит процесс. Отправить DNS-запрос по UDP и по TCP:

dig cloud.vk.ru
dig +tcp cloud.vk.ru

Посмотреть трафик DNS на интерфейсе:

sudo tcpdump -ni any 'port 53'

Проверить, открыт ли UDP-порт на удалённом сервере:

nc -vzu 203.0.113.10 5060

Важно знать

Важно знать. Проверка UDP-порта через nc ненадёжна: UDP не отвечает на пустые датаграммы, и «порт открыт» часто означает лишь, что ответ об ошибке не пришёл. Надёжнее отправить запрос на уровне приложения, например dig для DNS.

TCP и UDP в облаке

В облаке выбор протокола влияет на настройку сети и балансировки.

Группы безопасности. Правило задаёт протокол явно. Открытый TCP-порт 53 не пропустит DNS-запросы по UDP, для DNS нужны оба правила.
Балансировщик нагрузки. Load Balancer в VK Cloud построен на OpenStack Octavia и балансирует HTTP, HTTPS, TCP и UDP. Для TCP доступен proxy-протокол, который передаёт серверу IP-адрес клиента. Подробности в документации.
Проверки доступности. Проверка TCP-порта не подтверждает, что UDP-сервис отвечает на запросы. Для UDP-приложений нужна проверка на уровне самого сервиса.

Нужны целостность и порядок данных: TCP.

Нужна минимальная задержка, отдельные потери допустимы: UDP.

Нужны и надёжность, и низкая задержка, и много параллельных потоков: QUIC и HTTP/3.

Разворачиваете сервис в облаке: укажите в группах безопасности и порт, и протокол, и выберите протокол слушателя в балансировщике нагрузки.

Оставьте заявку, чтобы получить консультацию

Наши специалисты свяжутся с вами в ближайшее время и ответят на все вопросы.

FAQ

Чем TCP отличается от UDP простыми словами?

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

Что быстрее, TCP или UDP?

UDP быстрее начинает передачу и не тратит время на подтверждения. Но при потерях приложению поверх UDP всё равно придётся что-то делать, поэтому итоговая скорость зависит от задачи и качества сети.

Какой протокол использует DNS?

По умолчанию UDP на порту 53. Если ответ слишком большой или идёт передача зоны, используется TCP на том же порту.

Могут ли TCP и UDP использовать один номер порта?

Да. Порты TCP и UDP независимы: TCP-порт 53 и UDP-порт 53 это разные точки подключения, и DNS-сервер слушает оба.

Работает ли HTTP/3 по UDP?

Да. HTTP/3 использует протокол QUIC, который работает поверх UDP и сам обеспечивает надёжность и шифрование.

Безопасен ли UDP?

Ни TCP, ни UDP не шифруют данные: шифрование добавляют TLS, DTLS или QUIC. Специфический риск UDP связан с атаками с усилением, поэтому публичные UDP-сервисы нужно защищать ограничением частоты запросов и фильтрацией трафика.