UDP или TCP: выбираем transport contract

Overview

TCP и UDP нельзя выбирать по слогану «надёжно против быстро». Это разные transport contracts. UDP сохраняет datagram boundary и не создаёт connection lifecycle, но не обещает delivery, ordering или duplicate protection. TCP создаёт connection и предоставляет reliable ordered byte stream, однако не хранит application message boundaries и может задерживать более поздние bytes, пока восстанавливает потерянные более ранние.

Один и тот же payload «Привет» занимает 12 bytes в UTF-8. В UDP один sendto() делает его частью одной datagram. В TCP application сначала добавляет framing, затем передаёт bytes циклом send(); receiver накапливает произвольные recv chunks и восстанавливает frame. Правильный выбор начинается с требований к semantics, maximum size, deadline, retry и observability.

Components

• application requirements — нужные boundary, ordering, reliability, latency budget, fan-out и допустимая сложность protocol state.
• UDP sendto()/recvfrom() — message-oriented API с destination/source address для datagram.
• UDP datagram — отдельная transport unit при доставке; retry и duplicate semantics в неё не встроены.
• TCP send/recv loops — stream API, где partial I/O является нормальным результатом.
• ordered byte stream — TCP contract без встроенных application messages.
• segments, ACK, retransmission — mechanism, который даёт ordered reliable stream, но может добавлять delay.
• application framer — length prefix, delimiter with escaping или другой unambiguous способ вернуть message boundaries поверх TCP.

Scenarios

1. UDP: message boundary. Datagram сохраняется как единица, если доставлена; application принимает ответственность за loss и duplicates.
2. TCP: ordered byte stream. Transport восстанавливает порядок bytes, application framing восстанавливает сообщения.
3. Неверный contract assumption. One send ≠ one recv в TCP, а UDP loss не запускает transport retry.

Failure modes

• Выбирать UDP только потому, что его header меньше, не определив retry, idempotency, MTU и overload policy.
• Выбирать TCP и считать, что reliable byte stream автоматически делает operation exactly-once.
• Парсить каждый positive recv() как одно сообщение и ломаться на split/coalesced chunks.
• Считать UDP datagram гарантированно целой независимо от receive buffer и fragmentation path.
• Игнорировать head-of-line delay TCP при real-time требованиях или, наоборот, реализовывать поверх UDP плохо протестированную копию TCP.
• Не измерять actual loss, RTT, queueing и application deadlines перед выбором transport.

References

• RFC 768: User Datagram Protocol
• RFC 8085: UDP Usage Guidelines
• RFC 9293: Transmission Control Protocol
• Microsoft Learn: send function
• Microsoft Learn: recv function
• Microsoft Learn: sendto function
• Microsoft Learn: recvfrom function