TCP vs UDP: Pick TCP by Default, UDP for Deadlines

TCP wins for most applications because it provides an ordered, reliable byte stream and handles retransmission, flow control, and congestion control. Choose UDP only when meeting a deadline matters more than recovering every lost packet, or when the application already supplies the missing machinery.

That rule is more useful than the familiar reliability-versus-speed shorthand. Reliability does not automatically make an application slow, while a connectionless protocol that adds acknowledgments, sequencing, congestion handling, and retransmission may recreate much of the other transport badly.

Use the connection-oriented protocol for web APIs, remote shells, email, database connections, software updates, and ordinary file transfers. In these applications, corrupted order or missing data is worse than waiting for a retransmit. The current TCP specification↗ defines connection establishment, acknowledgments, retransmission, flow control, and ordered delivery.

Use datagrams for live voice, multiplayer position updates, telemetry samples, service discovery, and some real-time video. UDP is ideal for when you want quick updates and an old message has no remaining value. If a player-position packet disappears, sending a newer position is usually better than pausing the conversation to recover stale data.

• Choose TCP when every byte must arrive intact and in order.
• Choose it when the development team does not intend to build transport behavior.
• Choose UDP when data expires faster than retransmission can help.
• Choose datagrams for multicast where the network supports it.
• Choose a purpose-built protocol such as QUIC when independent application streams matter.

For HTTP delivery, the version and server stack may decide for you. HTTP/1.1 and HTTP/2 normally use TCP. HTTP/3 uses QUIC over UDP while supplying reliability, encryption, congestion control, and independent streams above it. A CDN's role in content delivery is separate from that choice, although modern CDNs commonly negotiate HTTP/2 or HTTP/3 at the edge.

TCP is connection-oriented, while UDP is connectionless: the former establishes endpoint state and exposes an ordered byte stream, whereas the latter sends separate datagrams without delivery or ordering guarantees. Both are responsible for end-to-end communication, but they give applications sharply different contracts.

Transmission Control Protocol begins a conventional connection with a three-way handshake. Each side tracks sequence numbers, acknowledgments, receive windows, and congestion. Lost packets trigger retransmission, duplicates are discarded, and bytes wait until earlier bytes in the sequence arrive. That protects integrity and order, but packet loss can increase latency.

User Datagram Protocol is narrower. Its header contains source and destination ports, length, and a checksum. It preserves message boundaries but does not guarantee delivery, restore order, suppress duplicates, or regulate the sender against congestion. Those limited UDP protocol semantics↗ make the claim that it is simply faster misleading.

• TCP delivers a stream, so one write does not necessarily equal one read.
• UDP delivers separate messages, provided they arrive.
• The stream protocol detects loss and retransmits data.
• The datagram protocol supplies no acknowledgment or error correction beyond checksum validation.
• The stream protocol includes flow control and congestion control.
• A datagram application must add responsible rate control itself.

A UDP header is 8 bytes. A TCP header starts at 20 bytes before options, and the three-way handshake sends packets before application data flows. On a long file transfer, those bytes matter far less than the congestion window and recovery behavior.

There is another trap. A transport acknowledgment says data reached the receiving network stack, not that the remote application committed a payment or stored a file. That guarantee still requires an application-level response.

UDP wins when late information is worse than missing information, especially in live media, interactive games, DNS queries, and tightly controlled telemetry. It also wins when a purpose-built protocol needs independent streams or custom recovery instead of one ordered byte stream.

Live voice is the clean example. A lost audio packet may produce a tiny gap that concealment can mask, while retransmitting it after its playback deadline merely adds delay. Real-time applications commonly add sequence numbers and timestamps so the receiver can detect loss, reorder a small window of messages, and discard data delivered too late.

Games make the same trade for frequent state updates, but they rarely send everything unreliably. Position snapshots can travel as datagrams because a new snapshot supersedes an old one. Login, inventory, purchases, and match results need reliable delivery, so the game must acknowledge those messages, retransmit them, or maintain a separate reliable channel. The nominal loser wins here because it lets the application decide which data deserves recovery.

QUIC is the stronger modern case. It runs over UDP but implements reliable streams, loss recovery, congestion control, and mandatory cryptographic protection in user space. Because those streams are independent, loss in one does not force delivered data in another to wait as it can when several HTTP/2 streams share one TCP connection. The QUIC transport standard↗ documents this design.

Packet loss is not permission to ignore congestion. An application that sends datagrams at full rate during congestion can worsen loss for itself and everyone sharing the path. Building a public internet protocol this way means implementing rate adaptation, path validation, datagram sizing, protection against spoofing, and recovery rules wherever reliability is required. That is expensive work.

Some enterprise firewalls, carrier systems, and older NAT devices restrict or expire connectionless state aggressively. A service may therefore need a TCP fallback even when UDP better fits the traffic. Test the actual route, not merely localhost.

The final rule is short. Default to TCP; choose UDP only when you can name the deadline, identify which messages may be lost, and explain how the application controls congestion.