TCP vs UDP: What Each Guarantees and Costs

When a network connection fails or performs poorly, the first question is often whether the application uses TCP or UDP. The two protocols handle data delivery in fundamentally different ways, and the choice explains many symptoms: a video call that breaks up but never stalls, a file transfer that stalls but never corrupts, a game that shows rubber-banding instead of a disconnected message. This page explains what each protocol guarantees, what those guarantees cost, and how to recognize which one is in use from a packet capture.

The Core Difference: A Guarantee vs. a Gamble

TCP (Transmission Control Protocol) provides a reliable, ordered, byte-stream connection. Every byte sent is acknowledged, and if one is lost, it is retransmitted. The receiver gets the data in the exact order it was sent, without gaps or duplicates. This is achieved through sequence numbers, acknowledgments (ACKs), and a retransmission timer.

UDP (User Datagram Protocol) provides a connectionless, best-effort datagram service. Each datagram is sent independently, with no acknowledgment, no retransmission, and no ordering. If a datagram is lost, it is gone. The application receives whatever arrives, in whatever order it arrives.

The difference is not that UDP is “worse”—it is that TCP makes promises that UDP does not, and keeping those promises costs time and bandwidth. For some applications, that cost is unacceptable.

What TCP Actually Costs

TCP’s reliability comes with several overheads:

• Handshake: Before any data flows, TCP performs a three-way handshake (SYN, SYN-ACK, ACK). This adds one round-trip time (RTT) before the first byte of data is sent.
• Acknowledgment overhead: Every segment (or group of segments) must be acknowledged. The receiver sends ACK packets, and the sender must process them.
• Retransmission delay: If a segment is lost, the sender must wait for a timeout or receive duplicate ACKs before retransmitting. This adds at least one RTT to the delivery of that data.
• Head-of-line blocking: Because TCP delivers data in order, a single lost segment can hold up all subsequent data until it is retransmitted. The receiver’s buffer fills, and the application sees a pause.
• Congestion control: TCP actively reduces its sending rate when it detects packet loss, to avoid overwhelming the network. This is essential for network stability but means throughput can drop dramatically under loss.

These costs are invisible in a healthy network with low latency and zero loss, but they become severe when latency is high (e.g., satellite links) or loss is present (e.g., Wi-Fi interference).

What UDP Gives Up and What It Gains

UDP has no handshake, no acknowledgments, no retransmission, and no ordering. Each datagram is sent immediately, with a minimal 8-byte header (vs. TCP’s 20-byte minimum). The gains are:

• Low latency: No handshake, no waiting for ACKs. Data is sent as soon as the application writes it.
• No head-of-line blocking: A lost datagram does not delay subsequent ones. The application can process what arrives, even if it is out of order.
• No congestion control: UDP will keep sending at the application’s chosen rate, regardless of network conditions. This is dangerous for the network but perfect for real-time media that must maintain a constant bitrate.

The price is that the application must handle loss, ordering, and duplication itself—or simply accept them, as real-time media does.

When to Use UDP: Real-Time and Loss-Tolerant Applications

UDP is the choice when a late or missing packet is worse than a lost one. The classic examples are voice and video calls, online gaming, and live streaming. In these applications, data is time-sensitive: a packet that arrives too late is useless. If TCP retransmitted a lost voice packet, the call would stall while the retransmission arrived, and the listener would hear a gap. With UDP, the packet is simply missing, and the codec can interpolate or mute for a few milliseconds, which is far less noticeable.

Similarly, in a fast-paced game, a player’s position update that arrives late is worse than one that never arrives. A late update can cause the game to show the player in a wrong position, leading to rubber-banding. A missing update is simply skipped, and the next one corrects the position.

UDP is also used for DNS queries, DHCP, and streaming protocols like RTP (Real-time Transport Protocol) and QUIC (which runs over UDP but adds its own reliability on top).

When TCP Is the Right Choice

TCP is for data that must arrive intact and in order: file transfers, email, web pages, database queries, and any application where a corrupted file or missing transaction is unacceptable. The cost of waiting for a retransmission is trivial compared to the cost of corrupted data.

TCP is also used for streaming video when the content is pre-recorded (e.g., YouTube, Netflix over HTTP). Here, the player can buffer ahead, and a retransmission delay is hidden by the buffer. Live streaming, however, often uses UDP or HTTP over QUIC to minimize delay.

Comparison Table

Recognizing TCP vs UDP in a Capture

In Wireshark, TCP packets are easy to spot: they have a TCP header with source and destination ports, sequence and acknowledgment numbers, and flags like SYN, ACK, and FIN. The first packets of a TCP connection show the three-way handshake: SYN, SYN-ACK, ACK.

UDP packets are simpler: just source and destination ports, length, and checksum. There is no handshake, no sequence numbers, and no flags. A UDP conversation appears as a series of independent packets, each with the same port pair.

One common confusion: a packet capture may show TCP packets for a protocol that is actually UDP-based, because the application uses a TCP control channel (e.g., SIP over TCP for signaling, but RTP over UDP for media). In that case, look at the media stream ports to see UDP.

The Misdiagnosis: “UDP Is Unreliable, So It’s Bad”

A natural mistake is to assume that because UDP does not guarantee delivery, it is inherently inferior. This view leads to the conclusion that any application using UDP must be broken or that switching to TCP would fix problems. The mistake is understandable because TCP’s guarantees sound strictly better. But the guarantees come at a cost that makes TCP unusable for real-time applications. A video call over TCP would stutter and freeze under any packet loss, because a single lost packet would halt the stream until retransmission. UDP’s “unreliability” is actually a feature: it lets the application decide what to do with missing data, and for time-sensitive data, the right decision is often to skip it.

Another misdiagnosis is blaming UDP for packet loss that is actually caused by network congestion or a faulty link. UDP does not cause loss; it simply does not hide it. A UDP-based application may show poor quality under loss, but switching to TCP would not fix the underlying network problem—it would just make the application stall instead of degrade.

How the Choice Shows Up in Real-World Symptoms

• Video call breaks up but never freezes: Likely UDP (RTP). Lost packets cause audio/video glitches, but the stream continues.
• File download stalls but never corrupts: Likely TCP. A lost segment triggers retransmission, causing a pause, but the file arrives intact.
• Game shows rubber-banding: Likely UDP. Position updates are lost or delayed, and the client interpolates, causing the player to snap back.
• Web page loads slowly but completely: Likely TCP. The handshake and congestion control add latency, but the page is delivered reliably.

What People Get Wrong About This

1. “UDP is connectionless, so it’s faster.” UDP is faster in terms of no handshake and no ACK overhead, but the actual throughput depends on the application and network. A UDP application that implements its own reliability (like QUIC) can be slower than TCP.
2. “TCP is always reliable.” TCP guarantees delivery only if the connection stays up. If the connection is reset or times out, data can be lost. Also, TCP does not protect against bit errors in the payload (it uses a checksum, but it is weak).
3. “Switching to UDP will fix my slow network.” If the network is congested, UDP will not fix it; it will just make the congestion worse for other traffic, and the application will still experience loss. The fix is to address the network, not the protocol.
4. “UDP has no flow control.” UDP has no built-in flow control, but the application can implement it. Many UDP-based protocols (like RTP) include sequence numbers and timestamps that allow the receiver to detect loss and jitter, and the sender can adapt.

Conclusion

TCP and UDP are not competing technologies where one is better; they are tools for different jobs. TCP provides a reliable, ordered stream at the cost of latency and overhead. UDP provides a fast, lightweight datagram service at the cost of reliability. The choice depends on whether the application values timeliness over completeness. Understanding this trade-off allows you to predict how an application will behave under network stress and to diagnose issues from a packet capture without guessing.