TCP vs UDP Explained: Handshakes, Reliability and Speed

Quick answer: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two main ways programs send data over IP. TCP first opens a connection, then numbers the data, confirms what arrives, resends what is lost and slows down when the network is crowded. It guarantees complete, in-order delivery, but costs a handshake round trip and can stall when packets go missing. UDP skips all of that: it sends independent packets with no setup and no guarantee, which is faster to start and better for real-time traffic like voice, video calls, online games and DNS lookups. Which one you use affects how latency, jitter and packet loss show up in practice.

Where TCP and UDP fit

The internet moves packets between IP addresses, as described in how the internet works. IP alone only offers best-effort delivery: a packet may be lost, duplicated, delayed or arrive out of order, and IP does not tell you which program the packet is for. The transport layer sits above IP and adds two things: ports, which direct data to the right program, and, depending on the protocol, reliability.

A port is a number from 0 to 65,535. Servers listen on well-known ports, such as TCP 443 for HTTPS, TCP 22 for SSH, and port 53 for DNS. Your device chooses a temporary port for each outgoing connection. A connection is identified by four values: source address, source port, destination address and destination port. That is also how the NAT table in your router, described in IP addresses, IPv4, IPv6 and NAT, tells connections apart.

What is TCP?

TCP provides a reliable, ordered byte stream between two programs. The application writes bytes in at one end and receives the same bytes in the same order at the other, and TCP deals with everything that can go wrong in between. To do this it provides:

• Connection setup and teardown through a handshake.
• Sequence numbers, so the receiver can reorder segments and detect gaps.
• Acknowledgements (ACKs), so the sender knows what arrived.
• Retransmission of segments that are not acknowledged in time or are reported missing.
• Flow control, so the sender does not overwhelm a slow receiver.
• Congestion control, so the sender does not overwhelm the network.

Most of the web, email, file transfer, SSH and database traffic uses TCP, because users care that the data is complete and correct more than about a few milliseconds.

The TCP three-way handshake

Before any data flows, the two ends exchange three packets:

1. SYN: the client says "I want to connect" and offers an initial sequence number and options.
2. SYN-ACK: the server acknowledges and offers its own sequence number.
3. ACK: the client confirms. It can send its first data immediately along with, or right after, this packet.

The client waits for the SYN-ACK, so the handshake costs one round-trip time (RTT) before data can be sent. If the RTT to the server is 80 ms, opening the connection takes 80 ms before the first byte of the request leaves your computer. This is the reason round-trip time matters so much to web pages: every new connection pays it. Encrypted connections add their own handshake on top (see the TLS and HTTPS handshake), and newer protocols such as QUIC merge them to save round trips (see HTTP/1.1, HTTP/2, HTTP/3 and QUIC).

Because the handshake time is simply one RTT to the server, it is a clean way to measure latency. Tools that time a TCP connect do exactly that, whereas ICMP ping uses a different protocol, as discussed in ping vs HTTPS latency.

How TCP makes delivery reliable

TCP numbers every byte. The receiver sends acknowledgements saying "I have everything up to byte N". If the sender does not see an ACK within a retransmission timeout (RTO), or sees duplicate ACKs that signal a gap, it resends the missing data. The initial RTO is one second by standard, and it adapts to measured RTT afterwards, with implementations commonly enforcing a minimum around 200 ms. Fast retransmit can resend sooner, after typically three duplicate ACKs, which takes about one RTT.

The price of in-order delivery is head-of-line blocking. If segment 5 of 10 is lost, segments 6 to 10 may already be in the receiver's buffer, but the application cannot see them until segment 5 is retransmitted and arrives. For a web page this appears as a short stall; for a live voice or game stream it appears as a freeze, and this is why those applications avoid TCP.

Flow control and the receive window

The receiver advertises a receive window, the amount of data it is ready to accept that has not yet been acknowledged. The sender must not exceed it. The original TCP header could advertise at most 65,535 bytes; the window scaling option, negotiated during the handshake, lifts that limit to about 1 GB and is enabled by default on modern systems.

The window matters because a sender can only have a window's worth of data "in flight" per round trip. This gives an upper limit on throughput:

maximum throughput = window size / RTT

The same idea gives the bandwidth-delay product (BDP), the amount of data needed in flight to fill a link: BDP = bandwidth × RTT. For a 1 Gbps link with 100 ms RTT it is 125 MB/s × 0.1 s = 12.5 MB. If the window is smaller than that, the link is never filled. More on how this interacts with link speed is in latency vs bandwidth vs throughput.

Congestion control and slow start

Flow control protects the receiver; congestion control protects the network. The sender keeps a congestion window (cwnd) that limits how much it sends before getting ACKs, and adjusts it according to what it observes:

• Slow start: the connection begins with a small window, commonly 10 segments (about 14,600 bytes with a typical 1,460-byte segment payload), and roughly doubles it each RTT while all goes well.
• Congestion avoidance: after reaching a threshold, or after the first loss, the window grows more slowly, about one segment per RTT in classic algorithms.
• Reaction to loss: loss is taken as a sign of congestion and the window is cut, for example halved in the classic algorithm. Modern algorithms such as CUBIC (a common default on Linux) and BBR (which estimates bandwidth and RTT rather than relying on loss alone) behave differently in detail.

Because of slow start, short transfers on high-RTT paths never reach full speed. The connection is still ramping up when the file ends. This is another reason latency, not just bandwidth, determines how fast small and medium downloads feel.

What is UDP?

UDP sends datagrams: self-contained packets with a tiny 8-byte header carrying source port, destination port, length and checksum. That is all. There is no handshake, no connection state, no acknowledgement, no retransmission, no ordering and no congestion control. A program sends a datagram and does not know whether it arrived. If it matters, the application must build its own checks.

This minimalism is the point. UDP adds no waiting: the first datagram can be sent immediately, a lost datagram does not hold back later ones, and the sender decides the pace. UDP is used for:

• DNS queries, which are a single small request and reply (see DNS explained).
• Voice and video calls (VoIP, WebRTC), where late audio is useless.
• Online games, which send frequent state updates.
• Live streaming and some video delivery where timeliness matters.
• QUIC, the transport used by HTTP/3, which builds reliability, encryption and multiplexing on top of UDP.
• VPNs such as WireGuard, and discovery or time protocols like NTP.

TCP vs UDP at a glance

Property	TCP	UDP
Connection setup	Three-way handshake, one RTT	None
Delivery guarantee	Yes, retransmits lost data	No
Ordering	Yes, in-order byte stream	No, datagrams may arrive in any order
Header size	20 bytes minimum, plus options	8 bytes
Flow and congestion control	Built in	None; application must provide it
Behaviour under loss	Delay and slowdown, no missing data	Missing data, no automatic delay
Typical uses	Web, email, file transfer, SSH, databases	DNS, voice, games, streaming, QUIC, VPNs

Worked examples

Example 1: How RTT caps a single TCP transfer

Assume a receive window of 64 KB (65,535 bytes, no scaling) and a 100 ms RTT. Maximum throughput = 65,535 bytes × 8 / 0.1 s = about 5.2 Mbps, no matter whether the link is 100 Mbps or 1 Gbps. At 10 ms RTT the same window allows about 52 Mbps. With window scaling and a 4 MB window at 100 ms, the limit becomes 4,194,304 × 8 / 0.1 = about 335 Mbps. Modern operating systems tune windows automatically, so this limit normally shows up only with old systems, misconfigured devices or very long paths.

Example 2: Slow start on a small download

You download a 100 KB file over a connection with 50 ms RTT, with an initial window of 10 segments (14.6 KB). The handshake takes 50 ms. Then the sender can transmit 14.6 KB in the first round, 29.2 KB in the second (cumulative 43.8 KB) and 58.4 KB in the third (cumulative 102.2 KB). The transfer needs three data rounds, so about 50 + 3 × 50 = 200 ms, ignoring serialisation time and server delay, even if the link could carry the whole file in a few milliseconds. On a 10 ms RTT path the same download takes about 40 ms.

Example 3: Packet loss on TCP

A widely used approximation (the Mathis formula) says TCP throughput is roughly proportional to MSS / (RTT × √loss). With a 1,460-byte segment, 50 ms RTT and 1 percent loss, that gives about 3 Mbps, regardless of how fast the line is. At 0.01 percent loss, the same path would allow about ten times more, around 30 Mbps. Real behaviour depends on the congestion control algorithm, but the lesson holds: even small loss rates hurt long-distance TCP badly. See packet loss explained.

Example 4: A lost game update

A game sends a position update every 16 ms. Over UDP, if one datagram is lost, the next arrives 16 ms later with newer information and nothing stalls. Over TCP, the lost update would be retransmitted after about one RTT or more, and all updates behind it would wait. With a 40 ms RTT the stall could be 40 to 80 ms or more, with stale data delivered after the fresher data was already waiting. That is why gaming uses UDP.

Measuring TCP and UDP latency

Every protocol has a minimum cost of at least one RTT. ICMP ping measures one RTT using a separate protocol. Timing a TCP connect measures the handshake. Timing an HTTPS request, as the GlobeLatency test does from your browser, includes DNS if needed, the TCP handshake, the TLS handshake and the server's response, so its numbers are application-level round trips and are a bit higher than raw ICMP. When a connection is reused for later passes, TCP and TLS setup is not repeated, which is part of why the best pass is often lower than the first. The monitor shows how those numbers vary over time, which is where retransmission delays after packet loss show up as occasional spikes.

Common mistakes and myths

• "UDP is always faster." It starts faster and avoids stalls, but for bulk data it needs the same congestion control that TCP has built in. Raw UDP blasting at full speed can harm other traffic.
• "TCP is slow." TCP is fast when it has room to grow. Slowness usually comes from high RTT, packet loss or small windows, not from the protocol being inefficient.
• "UDP is unreliable so apps lose data." Many UDP applications, QUIC included, add their own reliability where needed, in a way that fits their use better than TCP's strict ordering.
• "A bigger plan fixes slow downloads from far away." A single TCP connection over a long path can be limited by RTT, window and loss rather than by line speed.
• "Ping uses TCP." Classic ping uses ICMP, which is a different protocol with no ports.
• "Blocked UDP means the internet is down." Some corporate and hotel networks restrict UDP, which can break calls and games and force a fallback to TCP while web browsing still works.

What to do next

To see how a TCP connection is secured, read the TLS and HTTPS handshake, then HTTP/1.1, HTTP/2, HTTP/3 and QUIC for how newer protocols cut waiting time. If your games or calls stutter, packet loss explained and jitter explained cover the symptoms that UDP traffic reveals. To measure your own round-trip times, run a free latency test.