The received knowledge that UDP is faster than TCP is, in general, valid. However the brevity of this nugget of truth belies the complexity of the reasons for UDP's speed advantage, and some essential factors that must be considered when comparing it with TCP.

First of all, it is worth clarifying what is meant by "fast": the speed of a transport mechanism such as TCP or UDP has two related but independent dimensions, namely throughput and latency:

  • Throughput is the rate at which data can be transported by the mechanism, and is quantified as a bit-rate.
  • Latency is the time taken to transmit data, from when data is sent to when that data is received, and is quantified as a timespan.

The throughput that TCP and UDP can achieve is limited by the slowest link in the physical network carrying the packets, and the latency is also constrained by physical factors, being at least the sum of the latency across all network devices and links along the path connecting the hosts.


There are two apparent advantages that UDP has over TCP when it comes to throughput:

  1. Firstly, UDP uses a smaller packet header, fixed at eight bytes, than TCP, which uses at least twenty bytes and often more. In principle, this should allow UDP to make more efficient use of the bottleneck link than TCP, but actually the apparent advantage is illusory: at the standard MTU of 1500 bytes, this translates to a difference of less than 1%. Even then, an application using UDP would need to be very carefully written to segment its data to reach the MTU. Typical UDP applications will instead use segment sizes corresponding to individual application messages, or maybe groups of messages, without too much regard for packet-header overheads.
  2. The flow control mechanism in TCP will rate-limit the throughput to no more than the advertised window divided by the network round-trip time, whereas UDP imposes no such speed limit. However this apparent speed advantage can again be illusory: an application that pushes data over UDP at speeds exceeding what TCP achieves will need to deal with the packet-loss that can result from overrunning buffers in the receiver or the network in between. If this loss of data cannot be tolerated, then the application will need to implement its own retransmission mechanisms - it is very difficult to build these to be more efficient than TCP.

Given the difficulty of achieving better throughput than TCP delivers, it is very rare to see applications using UDP or other protocols for bulk transfers. This is also the reason that the speed advantages of UDP over TCP are generally considered to be in the latency dimension.


In comparing the latency of UDP with that of TCP, there are at least three different regimes that are important to consider:

1. Latency of isolated packets

The simplest measurement of the latency of network transport uses isolated packets; that is, we leave the full system idle, trigger the transmission of a single packet, and wait until it arrives before doing anything else. This allows us to probe the very minimum latency achievable, and avoids the confounding factors that congestion in the operating system or network can induce.

Some recent experiments discussed here were conducted on a LAN with fairly standard hardware and Linux hosts. For isolated packets, these experiments showed median one-way latencies of about 16us over TCP and 12us over UDP. The physical path was the same in both experiments, and the only change in the application software was the selection of the kind of socket to use, and so the consistent difference in latency is due to the simplicity of UDP. TCP provides extra guarantees that UDP does not, and has extra work to do to check for lost and out-of-sequence packets.

While the 4us advantage of UDP seen in this experiment is marginal over wide-area or internet connections, it is significant in low-latency environments, and UDP remains an important place in high-performance networking.

2. Latency under load

Matters become interesting if we raise the application data-rates to the point where we start to cause congestion: over TCP, flow-control limits the volume of data in flight in the network to what that receiver's buffers can accommodate, and congestion avoidance reacts to any loss occurring in the network. When the rate at which the application tries to send data exceeds the throughput that TCP can achieve, that data will end up queuing in the socket, causing the end-to-end delay to skyrocket.

Over UDP, none of this queuing occurs, and the end-to-end latency will usually remain much the same as for isolated packets. The problem of course is that, without any flow-control and buffering, huge packet loss will occur instead. Some applications, such as VoIP and streaming video, can tolerate moderate level of packet-loss, but most applications cannot afford any. Thus, as in the case of throughput, the apparent latency advantage of UDP over TCP under load is chimerical.

3. Connection setup latency

So far, we have only considered the latency of an individual datagram, without taking into account the time required to set up a TCP connection. Since this is nearly universally done using the classic three-way handshake, UDP has a latency advantage here: it takes TCP at least three network transits between the client and server to transfer the first piece of data, while UDP can do so in just one.

As before, the overheads that TCP imposes are valuable, helping to ensure that the server is actually ready to receive the data the client sends, and any application using UDP will have to implement them itself.

However the potential advantages are significant enough that alternatives to the full three-way handshake have been implemented for TCP: one early attempt was T/TCP (or Transactional TCP, RFC 1644), which enables a client to open a connection, transmit data, and close the connection all with a single packet. Because of security weaknesses in T/TCP, it was replaced with TFP (or TCP Fast Open, RFC 7413); this too can reduce the latency of the initial data transfer to a single transmission, without losing any of the benefits of TCP.

Another use of this approach is in the QUIC protocol, developed at Google and now on track to become an IETF standard. QUIC is actually layered on top of UDP, but provides TCP-like reliability with UDP-like latency. Security protocols usually impose another full network round-trip to exchange keys before data can be securely transmitted, and so standard TLS requires two full round-trip times - one for the TCP handshake and another for key-exchange. QUIC cannot completely bypass the need to exchange keys, but can reuse the security context already established by a pair of endpoints in a previous session to eliminate unnecessary network round-trip latencies.


In summary, UDP is generally a little faster than TCP, sometimes a lot faster, and how much faster depends on what aspect of speed you're interested in. Furthermore, any speed advantage that UDP provides comes with important caveats and the need to reimplement the guarantees that TCP provides.