TCP vs UDP: Which Protocol Has Lower Latency?

By PingTester · August 10, 2026 · 7 min read

TCP and UDP are the two main transport protocols that carry traffic across the internet. They both run on top of IP and both deliver data from one host to another, but they make opposite trade-offs. TCP prioritizes reliability and ordered delivery; UDP prioritizes speed and minimal overhead. The protocol you choose — or that your application chooses for you — has a direct, measurable effect on the latency you experience.

This article compares the two protocols and explains why UDP has a lower base latency, when TCP latency compounds, and which use cases fit each.

Overview of TCP and UDP

Both TCP and UDP sit at layer 4 of the network stack, multiplexing many application streams over a single IP connection. From there they diverge sharply.

TCP is connection-oriented. Before any data flows, the two hosts perform a three-way handshake (SYN, SYN-ACK, ACK) to establish state. Once data flows, TCP numbers every byte, acknowledges received data, retransmits lost segments, and enforces in-order delivery to the receiving application. It also runs congestion-control algorithms that throttle sending rates when the network shows signs of loss.

UDP is connectionless. There is no handshake, no acknowledgment, no retransmission, and no enforced ordering. A UDP packet is sent, arrives (or does not), and the application deals with whatever happens next. This is austere, but it is also extremely fast: nothing stands between the application and the wire.

TCP: Connection-Oriented, Handshake Overhead, Reliable Delivery

TCP's reliability is its defining feature — and the source of its latency overhead. The three-way handshake itself adds a full round trip before the first byte of payload can be sent. For a short request over a 100ms link, that is 100ms of setup cost before any application data moves. TCP then adds acknowledgment traffic for every received segment, which inflates total packet count and can introduce queuing delay on congested links.

Reliable, in-order delivery also means TCP must buffer out-of-order packets until the missing one arrives. If packet 5 of 10 is lost, packets 6 through 10 wait in a receive buffer until packet 5 is retransmitted and arrives. The application does not see any of packets 6 through 10 until the gap is filled. This behavior, called head-of-line blocking, is one of TCP's biggest latency costs on lossy paths.

TCP also runs congestion-control algorithms (Reno, Cubic, BBR, and others) that deliberately reduce sending rate when they detect loss or rising delay. This is good for network stability but means that under congestion, TCP throughput drops and per-packet latency rises — by design.

UDP: Connectionless, No Handshake, No Guaranteed Delivery

UDP strips away everything TCP adds. There is no handshake, so the first UDP packet a sender transmits carries application data — zero setup latency. There are no acknowledgments, so a lost packet is simply missing; the sender does not retransmit unless the application layer explicitly does so. There is no in-order enforcement, so an application that receives packets 6 through 10 while 5 is missing can process them immediately if it chooses.

The cost of this lean design is that reliability becomes the application's problem. A protocol on top of UDP — QUIC, WebRTC, DNS, DHCP — must implement its own acknowledgment, retry, or forward-error-correction logic if it needs those guarantees. Many real-time applications choose not to: a voice call where a 50ms audio frame is lost is better served by playing silence for that frame than by waiting 200ms to retransmit and replay it out of order.

Latency Comparison: Why UDP Has Lower Base Latency

UDP's base latency advantage comes from removing every delay that TCP adds by design. No handshake means no setup round trip; no acknowledgments mean no extra packets adding to queue depth; no retransmission means a lost packet does not stall subsequent packets; no congestion control means the sender does not deliberately slow down.

Protocol performance studies referenced at grahammiranda.network suggest UDP can reduce initial connection latency by 50-100ms compared to TCP in suboptimal network conditions. On a clean, low-loss wired connection the gap is much smaller — sometimes only a few milliseconds — because TCP's overhead is mostly relevant when something goes wrong. The worse the network, the larger UDP's advantage becomes, because TCP's reliability machinery activates exactly when latency is already degrading.

Head-of-Line Blocking in TCP

Head-of-line blocking is the single most consequential source of TCP latency on lossy links. When TCP detects a lost packet (typically via a duplicate ACK or a timeout), it stops delivering data to the application until the lost packet is retransmitted and arrives. Every packet behind the lost one is held hostage.

On a connection with 1% packet loss and 100ms RTT, a single dropped packet can stall the application for an additional 100-200ms while TCP retransmits and reorders. With 2% loss, this happens roughly twice per 100 packets, and the average latency the application sees balloons well beyond the base RTT. UDP has no such stall; a lost packet is just missing data, and the application decides whether to skip, interpolate, or wait.

When TCP Latency Compounds

TCP latency is not just additive; it compounds under stress. Three mechanisms drive this:

• Retransmission timeouts. When TCP's fast-retransmit heuristic does not catch a loss (because too few duplicate ACKs arrive), it falls back to a retransmission timeout (RTO). The RTO is conservatively set to at least 1 second by default and only decays slowly. A single RTO event is a catastrophic latency spike.
• Congestion control. After any loss, TCP halves its sending window (in Reno/Cubic) or reduces its pacing rate (in BBR). Smaller windows mean fewer in-flight packets, which means higher per-packet latency as the sender waits for ACKs to release window space.
• Slow start after idle. If a TCP connection sits idle for a while, congestion windows reset. The first packets after idle go out slowly, ramping back up over several RTTs.

The combined effect: on a healthy connection, TCP latency is close to base RTT; on a stressed connection, TCP latency can be multiples of base RTT, and the worse it gets, the worse it gets.

Use Cases: When to Pick Each Protocol

The right protocol depends on what the application needs.

• UDP for gaming, streaming, and voice. Real-time applications tolerate a missing packet far better than they tolerate a delayed one. Online games use UDP because the position of a player 100ms ago is useless; retransmitting it wastes bandwidth and adds latency. Voice and video over WebRTC use UDP for the same reason — a dropped frame is a brief glitch; a delayed frame is out-of-sync audio.
• TCP for web, email, and file transfer. When correctness matters more than immediacy, TCP is the right choice. Web pages, file downloads, and email all need every byte to arrive intact and in order, and they are not meaningfully latency-sensitive at the per-packet level. The handshake cost is amortized over a long-lived transfer.
• QUIC — UDP carrying reliable delivery. HTTP/3 and QUIC are interesting because they run over UDP but reimplement many of TCP's reliability features in user space. The motivation is to escape TCP's head-of-line blocking: QUIC multiplexes independent streams over a single UDP connection so a lost packet in one stream does not stall the others. This is a major reason modern web stacks are migrating toward QUIC.

Measuring Protocol Latency Differences

If you want to measure TCP vs UDP latency yourself, the simplest approach is to compare tools that target each protocol. For raw network latency, ping (ICMP) gives you the protocol-independent baseline. For TCP-specific latency, tools like hping3 --syn or tcptraceroute measure the time to complete a TCP handshake to a specific port. The difference between the ICMP RTT and the TCP handshake RTT is the protocol overhead. For a deeper primer on running these measurements, see our beginner's guide to running a ping test; for context on what each component contributes, see understanding network latency.

Summary

TCP and UDP trade latency for reliability in opposite directions. TCP adds handshake overhead, acknowledgment traffic, in-order buffering, and congestion control — all of which improve reliability but compound latency under stress, especially via head-of-line blocking. UDP strips all of that away, giving the application immediate access to the wire at the cost of handling reliability itself. Choose UDP when immediacy beats completeness (gaming, voice, streaming); choose TCP when completeness beats immediacy (web, file transfer, email). Modern stacks increasingly use QUIC over UDP to get TCP-like reliability without TCP's head-of-line stalls.