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:
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:
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.