Networking

TCP и UDP

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

Что такое TCP и UDP

TCP (Transmission Control Protocol) и UDP (User Datagram Protocol, в разговоре «удп») — два транспортных протокола, работающих поверх IP. Сам IP умеет только доставить пакет от адреса к адресу: без гарантий, что тот дойдёт, дойдёт один раз и в нужном порядке. Разбираться с этим — задача транспортного уровня, и два протокола решают её противоположными способами.

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

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

TCP/IP («стек TCP/IP») — не третий протокол, а собирательное название всего набора протоколов интернета, названного по двум главным из них.

Установка соединения TCP

Клиент                              Сервер
   │────────── SYN, seq=x ────────────▶│
   │◀──── SYN-ACK, seq=y, ack=x+1 ─────│
   │────────── ACK, ack=y+1 ──────────▶│
   │══════════ данные ════════════════▶│
   │────────── FIN / ACK ─────────────▶│

Три пакета рукопожатия стоят один полный RTT до первого байта данных, а поверх ложится ещё TLS — плюс один-два RTT. Отсюда практический вывод: keep-alive и пулы соединений экономят больше, чем кажется, особенно на межконтинентальных плечах.

Сравнение

TCP UDP
Соединение устанавливается, handshake нет, шлёт сразу
Доставка гарантирована, переспрашивает не гарантирована
Порядок пакетов восстанавливается как придут
Контроль перегрузки есть нет, забьёт канал
Заголовок 20 байт и больше 8 байт
Задержка старта +1 RTT 0 RTT
Broadcast и multicast невозможны штатно
Типичные пользователи HTTP, SSH, SMTP, БД DNS, NTP, VoIP, игры, QUIC

Правило простое: если потеря байта ломает смысл (файл, запрос к БД, SSH-сессия) — TCP. Если данные обесцениваются от ожидания (голос, видео, телеметрия) — UDP: переспрашивать потерянный кусок голоса поздно, его уже никто не услышит.

Порты и состояния

Оба протокола адресуют приложение номером порта, и пространства портов у них независимы: TCP/53 и UDP/53 — разные сокеты.

$ ss -tuln
Netid  State   Recv-Q  Send-Q   Local Address:Port
udp    UNCONN  0       0              0.0.0.0:53
udp    UNCONN  0       0              0.0.0.0:123
tcp    LISTEN  0       511            0.0.0.0:80
tcp    LISTEN  0       128            0.0.0.0:22

UDP-сокеты всегда в состоянии UNCONN — состояния соединения у них попросту нет. У TCP состояний много: LISTEN, ESTABLISHED, TIME_WAIT, CLOSE_WAIT. Тысячи TIME_WAIT — норма для нагруженного веб-сервера, а вот растущий CLOSE_WAIT означает, что приложение не закрывает сокеты за собой.

$ nc -zv example.com 443     # TCP: соединение либо установилось, либо нет
$ nc -zvu 8.8.8.8 53         # UDP: молчание не означает, что порт закрыт

QUIC: UDP, который ведёт себя как TCP

HTTP/3 работает поверх UDP/443. QUIC переносит надёжность, шифрование и контроль перегрузки в userspace: соединение поднимается за 0–1 RTT вместо связки TCP+TLS, а потеря пакета в одном потоке не блокирует остальные. Практический вывод для админа — не резать UDP/443 на файрволе, иначе клиенты будут молча откатываться на HTTP/2.

Связанные термины

Готовы запустить GPU-задачу?

Запустить GPU-сервер