TCP vs UDP: how they differ, and when each one is used

Every comparison of these two protocols says the same thing: TCP is reliable, UDP is fast, use TCP for web pages and UDP for video calls. That was good advice for about twenty-five years. It is now wrong in a way that matters, because the web itself has been moving to UDP since 2022 — HTTP/3 runs over QUIC, and QUIC runs over UDP. If you learned the old rule you will misread a packet capture.

So it is worth understanding what the two protocols actually do, rather than memorising which applications sit on top of them.

The handshake is the whole story

Before a TCP connection carries a single byte of your data, three packets cross the network. The client sends a SYN with an initial sequence number. The server replies SYN-ACK, acknowledging the client's number and offering its own. The client sends ACK. Only then does payload move.

That costs you one full round trip. On a link to a server in the same city, maybe 5 ms — irrelevant. On a satellite link at 600 ms round trip, it is most of a second before anything useful happens. This single fact explains most of the design decisions that follow.

Twenty bytes against eight

A TCP header is 20 bytes minimum and can reach 60 with options. A UDP header is 8 bytes, always — source port, destination port, length, checksum. That is the entire protocol.

Twelve bytes sounds trivial, and on a file transfer it is. On voice traffic it is not. A G.729 voice packet carries 20 bytes of audio. Wrapping that in TCP rather than UDP would add more header than payload — and the retransmissions would be useless anyway, because audio that arrives late is audio you have already played silence over. This is why RTP runs on UDP and always will.

Side by side

Where the old rule breaks

TCP's reliability applies to the connection, not to individual streams inside it. HTTP/2 multiplexes many requests over one TCP connection, so a single lost segment stalls all of them while it is retransmitted — including requests whose data already arrived. That is head-of-line blocking, and on a lossy mobile link it is brutal.

QUIC solves it by dropping to UDP and rebuilding reliability per-stream, in user space, where it can be changed without waiting for operating-system kernels to be updated. So HTTP/3 is not "the unreliable web". It is reliability moved up a layer to get better behaviour under loss — and, as a bonus, a secure connection in fewer round trips. When you next capture browser traffic and see a flood of UDP on port 443, that is what you are looking at.

Port numbers worth memorising

CCNA tests these directly, and the two that catch people out are DNS and HTTPS — both appear under TCP and UDP, for different reasons.

Telling them apart on a live device

On IOS, an access list with separate TCP and UDP lines will show you which is actually being matched:

R1# show ip access-lists TRAFFIC-CHECK
Extended IP access list TRAFFIC-CHECK
    10 permit tcp any any eq 443 (18422 matches)
    20 permit udp any any eq 443 (95170 matches)
    30 permit udp any any eq 53 (2011 matches)
    40 permit ip any any

Five times more UDP than TCP on port 443 is not an anomaly — that is HTTP/3 doing its job. A few years ago line 20 would have been almost empty.

Choosing between them

The question is not "do I want reliability" — everyone wants reliability. It is what should happen to data that arrives late.

If late data is still useful, use TCP. A file transfer that finishes a second slowly is fine; a file transfer missing a byte is not. If late data is worthless, use UDP and handle loss yourself. A voice packet that turns up after its playback slot cannot be used no matter how correct it is, so spending a round trip to recover it makes the call worse, not better. Everything else follows from that one question.