TCP vs UDP: Differences, Use Cases, and When to Use Each

TCP delivers data reliably and in order using handshakes and retransmission; UDP sends fast, connectionless datagrams. Compare the two and learn when each fits.

Category: Networking · Created: 2026-10-04 · Updated: 2026-10-04 · 3 min read

TCP and UDP are the two main transport protocols of the internet. Both carry data between programs on different computers, using port numbers to tell programs apart. TCP (Transmission Control Protocol) sets up a connection and guarantees that data arrives complete and in order. UDP (User Datagram Protocol) sends independent datagrams with no connection and no guarantees, trading reliability for speed and simplicity. Choosing between them is one of the most common design decisions in networked software.

What does TCP do?

TCP is connection-oriented. Before any data moves, the two sides perform a three-way handshake to agree on starting sequence numbers. After that, TCP presents the application with a continuous, ordered stream of bytes. It numbers every byte, requires the receiver to acknowledge what it has received, and retransmits anything that goes unacknowledged. It also reorders segments that arrive out of sequence, and it uses flow control so a fast sender cannot overwhelm a slow receiver.

TCP also reacts to the network itself. Its congestion control slows the sender when packets are being lost, which keeps the shared internet from collapsing under load. The price is a header of at least 20 bytes, extra round trips at the start, and delays whenever lost data must be resent. TCP was specified in RFC 793 in 1981, and the current consolidated specification is RFC 9293, published in 2022.

What does UDP do?

UDP is deliberately minimal. Its header is only 8 bytes with four fields: source port, destination port, length, and checksum. There is no handshake, no acknowledgement, no ordering, no retransmission, and no congestion control. Each datagram is independent, and it may arrive out of order, arrive twice, or not arrive at all. The protocol was defined by Jon Postel in RFC 768 in 1980, in a specification only about three pages long. If an application needs some reliability on top of UDP, it must build it itself.

TCP vs UDP side by side

Feature	TCP	UDP
Connection	Connection-oriented; handshake first	Connectionless
Reliability	Acknowledgements and retransmission	None built in
Ordering	Bytes delivered in order	Datagrams may arrive in any order
Header size	20 bytes minimum	8 bytes
Flow and congestion control	Yes	No
Data model	Continuous byte stream	Discrete messages
Typical latency	Higher	Lower
Multicast and broadcast	Not supported	Supported
Typical uses	Web pages, email, file transfer, SSH	DNS lookups, voice and video calls, games, streaming

When should you use UDP?

Use UDP when fresh data matters more than complete data. In a voice call, live video stream, or online game sending player positions dozens of times a second, a lost packet is already out of date by the time TCP would resend it, so it is better to skip it and keep going. UDP also suits tiny request-and-reply exchanges. DNS queries normally use UDP port 53, because one packet each way beats paying for a handshake; DNS falls back to TCP for large answers and zone transfers. DHCP and the Network Time Protocol also run on UDP, and multicast and broadcast require it.

TCP is the right choice when every byte must arrive correctly: web pages over HTTP and HTTPS, email delivery (how email works), file transfers, and remote shells all use it.

Head-of-line blocking and QUIC

TCP's strict ordering has a hidden cost. If one segment is lost, everything after it must wait in a buffer until the missing piece is resent. This is head-of-line blocking, and it hurts when many independent streams, such as the images and scripts of a web page, share one TCP connection. QUIC, standardised in RFC 9000 in 2021, is the transport beneath HTTP/3. It runs on top of UDP and implements its own reliability, congestion control, and built-in encryption, with independent streams so a lost packet delays only its own stream. Building a new transport on UDP also avoids waiting for operating systems and network equipment to support a brand-new protocol number. The security layer that QUIC integrates is covered in how TLS works.

Which should you choose?

Start with TCP. Reliable, ordered delivery is what most applications need, and rebuilding it on top of UDP is difficult to get right. Choose UDP when latency matters more than completeness, when messages are small and independent, or when you need multicast, and be ready to handle loss, duplication, and reordering in your own code. In both cases the application above the transport sees the same ports and addresses, so you can often switch protocols without changing how the rest of the program is organised.

More in Networking

All Networking articles

This text may be freely copied, modified, and reused. See Content Reuse.