TCP vs UDP simulator

A sender produces a small message every 20 ms, the way a voice call produces audio frames. Each message crosses a network that loses a share of packets and delays each one by half the round-trip time plus a random amount of jitter. The two strips show each message as UDP and as TCP delivered it, coloured by whether it arrived in time to be useful; the chart shows how long each one took to reach the application.

Every random draw is shared: a message that UDP lost is also lost on TCP's first try, so the difference between the strips is purely the protocols' behaviour. Things to try:

• At 0% loss, both deliver everything; TCP's first few messages are later because of the handshake.
• At 5% loss with a 150 ms limit, UDP loses about one message in twenty; TCP loses none, but after each loss a run of messages arrives late, because they wait for the resent one.
• Raise jitter to 60 ms. UDP messages start arriving out of order; TCP puts them back in order, at the cost of more waiting.
• Choose no limit, as for a file download, where only completeness matters and TCP is the clear winner.

The model keeps things simple: acknowledgements are never lost, TCP resends each lost segment after its retransmission timeout and doubles the timeout if the resend is lost too, and there is no congestion control. Real TCP would also slow its sending rate after losses, which makes it look worse for live traffic, not better. Fast retransmit, which reacts to duplicate acknowledgements instead of waiting for the timer, makes it look better on busy connections.

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two main transport protocols of the internet. Both carry data between programs, identified by port numbers, on top of IP. The difference is in what they promise. TCP gives the receiving program a reliable stream of bytes, in order, with nothing missing; UDP gives it whichever individual datagrams arrive, as they arrive.

TCP numbers every byte it sends. The receiver acknowledges the bytes it has received, and the sender resends anything not acknowledged in time. The receiver holds back data that arrived ahead of a gap until the gap is filled, so the application always reads bytes in order. TCP also controls how fast it sends: flow control stops it overrunning the receiver, and congestion control backs off when packet loss suggests the network is overloaded.

All of this needs state on both ends, which is set up by the three-way handshake before any data moves and torn down at the end. Because TCP is a stream, it has no idea where one application message ends and the next begins; protocols on top of it add their own framing, such as HTTP's Content-Length header or a length prefix.

UDP adds very little to IP: port numbers, so the datagram reaches the right program, a length, and a checksum, so a corrupted datagram can be thrown away. Its whole header is 8 bytes, and RFC 768, which defines it, is three pages long. There is no connection, no acknowledgement and no retransmission. The sender is not told whether a datagram arrived.

That is a feature as much as a limitation. An application can send its first message without waiting for a handshake, a lost packet never delays the ones behind it, and the application decides for itself what to do about losses: ignore them, resend them, or cover them with error-correcting data. The price is that it must also avoid flooding the network; RFC 8085 sets out the guidelines, such as limiting the sending rate when losses rise.

The simulator's default run: 100 messages, one every 20 ms, over a network with an 80 ms round trip, up to 20 ms of jitter and 5% loss, with messages useful only within 150 ms.

When a TCP segment is lost, the segments after it usually still arrive. TCP keeps them in its receive buffer but cannot hand them to the application, because the application must read bytes in order. Everything waits until the missing segment is resent and arrives, at least one round trip later and often more. This is head-of-line blocking: one lost packet delays data that arrived perfectly well, as the runs of late messages after each loss in the TCP strip show.

It matters most when one TCP connection carries several independent things. HTTP/2 sends many requests over a single connection; one lost packet stalls all of them, even those whose data all arrived. That is the main reason HTTP/3 moved to QUIC.

Not in the sense of moving bytes faster: on an open connection with no loss, both are limited by the same network. UDP is faster in three narrower ways:

• No setup: the first datagram goes immediately; TCP waits one round trip for the handshake, more with TLS on top.
• No waiting after a loss: later datagrams are delivered at once instead of waiting for a retransmission.
• Less work per packet: no acknowledgements, no retransmission timers, a smaller header. This rarely matters on modern hardware.

For bulk transfer, TCP is usually as fast or faster in practice, because it adapts its rate to the network, and operating systems and network cards are heavily optimised for it. A UDP sender that blasts data without congestion control can be "faster" only by causing losses for itself and everyone sharing the link.

QUIC, standardised in RFC 9000 in 2021, runs over UDP and rebuilds what TCP provides, reliable delivery, ordering and congestion control, inside the application rather than the operating system kernel. It adds three things TCP cannot easily offer: independent streams, so a loss stalls only the stream it belongs to; a combined transport and TLS 1.3 handshake, so a new connection is ready after one round trip, or none when resuming; and connection IDs that let a connection survive a change of network, such as a phone moving from Wi-Fi to mobile data. HTTP/3 runs on QUIC.

QUIC uses UDP because new transport protocols cannot get through the many firewalls and NAT devices that only understand TCP and UDP. Building on UDP and encrypting nearly all of its own headers lets it pass through and keeps those devices from depending on its details.

Home routers and corporate firewalls track connections to let replies back in. For TCP they can see the handshake and the FIN; for UDP they can only guess, so they keep a mapping open for a while after the last packet and then drop it. RFC 4787 asks NAT devices to keep UDP mappings for at least two minutes, and RFC 5382 asks for at least two hours and four minutes for established TCP connections, though many devices use shorter times. Long-lived UDP applications, such as VPNs and WebRTC calls, send keepalive packets to hold their mappings open.

TCP and UDP have separate port spaces: TCP port 53 and UDP port 53 are different endpoints, which is how DNS can listen on both.

"What is the difference between TCP and UDP?" is one of the most common networking interview questions. A strong answer goes beyond "reliable versus unreliable":

• Name the mechanisms: handshake, sequence numbers and acknowledgements, retransmission, flow and congestion control, versus none of them.
• Explain the cost: setup latency and head-of-line blocking.
• Give the deciding question, whether late data is still useful, and examples on both sides.
• Mention that reliability can be built on UDP, as QUIC does, and why that is attractive.
• Follow-ups: why DNS uses UDP, how a video call handles loss, what happens to UDP through NAT, and why TCP is a byte stream without message boundaries.