TCP and UDP: comparing transport protocols

TCP provides an ordered byte stream with acknowledgements, retransmission and flow control. UDP supplies independent datagrams with fewer built-in mechanisms. Choose according to the application's latency, reliability and compatibility requirements.

TCP and UDP serve different application needs

TCP is connection-oriented: SYN, SYN-ACK and ACK form its three-way handshake before an established connection carries data. It detects loss, retransmits missing segments and presents bytes in order. If recovery fails, the application receives a failure rather than a false success. Email protocols such as SMTP and IMAP and file transfers need complete data.

UDP has no transport handshake, retransmission or ordering guarantee. Its header is eight bytes, compared with TCP's twenty-byte base header. Applications can use it for latency-sensitive traffic when they tolerate loss or handle it themselves. The introductory streaming example illustrates that trade-off; it is not a rule that all video must use UDP.

TCP controls a byte stream

Sequence numbers order bytes; acknowledgements and retransmissions handle loss. Receive windows protect the receiver, while congestion control responds to suspected network overload. The application sees a continuous stream rather than the original IP packet boundaries.

Reliability does not automatically mean low delay. Retransmissions and head-of-line blocking can make an application wait after loss. The application still needs timeouts, disconnect handling and its own message framing.

UDP supplies independent datagrams

Low protocol overhead can suit short requests or time-sensitive data. DNS commonly uses UDP for ordinary queries but also uses TCP depending on message size and operation. Reliability, where needed, must come from the application or a protocol above UDP.

Modern protocols make the choice more nuanced. QUIC provides reliable encrypted streams in user space over UDP. Latency, loss tolerance, ordering and network compatibility remain the application-level decision criteria. Buffered streaming can benefit from reliable transfer and firewall compatibility through TCP or QUIC.

Ports identify communication endpoints

A flow is described by protocol, source and destination addresses, and source and destination ports. A server typically listens on a known port while a client uses an ephemeral one. Firewalls and NAT track state using these properties.

Inspect handshake, round-trip time, retransmissions, resets and receive windows. A missing SYN-ACK points toward path, filter or listener problems. If the transport connects but the result is wrong, continue with TLS and the application protocol.

Practical checklist

01
Identify the protocol, source/destination ports and expected listener.
02
For TCP, inspect the complete handshake and any resets.
03
Evaluate delay, loss and retransmissions over time.
04
Check firewall, NAT and return-path state in both directions.
05
Investigate TLS and application behaviour after confirming transport.

Frequently asked questions

Is UDP always faster than TCP?

UDP has fewer built-in mechanisms, but application performance depends on the network, implementation and required reliability. A UDP-based application may implement similar mechanisms itself.

Why does streaming often use TCP or QUIC?

Many services buffer content and benefit from reliable transfer and network compatibility. QUIC combines reliable streams with a UDP-based transport.

TCP and UDP: comparing transport protocols

Knowledge you can put to work.