System Design Fundamentals

0% completed

TCP vs. UDP

On This Page

Where TCP and UDP Fit

TCP

The Three-Way Handshake

How TCP Makes Delivery Reliable

Flow Control and Congestion Control

The Costs of TCP

When to Use TCP

UDP

Why Real-Time Apps Choose UDP

When to Use UDP

TCP and UDP Side by Side

Key Takeaways

Practice Questions

You are on a video call while a large file downloads in the background. Both use the same network, but they need very different things.

The download must arrive perfectly. If one byte is wrong, the file is broken. The call must arrive quickly. A voice that arrives two seconds late is useless, even if every piece of it is correct.

The internet has two main protocols for these two needs: TCP and UDP. This lesson explains how each one works, what each one costs, and how to choose between them.

Where TCP and UDP Fit

Data travels across the internet in small pieces called packets. The Internet Protocol (IP) moves each packet from one machine to another, using IP addresses to find the machines.

IP does not promise much. A packet can be lost, arrive twice, or arrive out of order. IP also knows only machines, not the programs running on them.

TCP and UDP run on top of IP, and they add two things.

Ports. A port is a number that identifies one program on a machine. For example, a web server usually listens on port 443, so the operating system knows which program should receive each packet.
Rules for delivery. TCP adds strong promises about delivery. UDP adds almost none.

Applications then run on top of TCP or UDP. For example, HTTP/1.1 and HTTP/2 run on top of TCP, and most DNS lookups run on top of UDP.

TCP

TCP stands for Transmission Control Protocol. It is connection-oriented, which means the two sides set up a connection before any data moves. It delivers a stream of bytes that is reliable, ordered, and error-checked.

The Three-Way Handshake

A TCP connection starts with a three-way handshake.

SYN. The client sends a packet that asks to open a connection.
SYN-ACK. The server agrees and acknowledges the request.
ACK. The client acknowledges the server's reply. The connection is now open.

The client sends SYN, the server answers SYN-ACK, and the client sends ACK, which opens the connection before any data moves

The handshake costs one round trip, which is the time for a message to go to the server and come back. If a round trip takes 100 ms, the client waits about 100 ms before it can send its first request.

How TCP Makes Delivery Reliable

TCP gives each byte a sequence number, which is its position in the stream. TCP uses these numbers in several ways.

Acknowledgements. The receiver tells the sender which data has arrived. These messages are called acknowledgements, or ACKs.
Retransmission. If the sender gets no acknowledgement for some data in time, it sends that data again. So lost or damaged packets are replaced.
Ordering. Packets can arrive out of order. The receiver puts them back in order by sequence number before it passes the data to the application.
Error checking. Each packet carries a checksum, a small value calculated from its contents. If the contents were damaged on the way, the checksum does not match, and the packet is thrown away and sent again.

Packet 2 is lost, so the receiver holds packet 3, the sender resends packet 2, and the application receives 1, 2, and 3 in order

Flow Control and Congestion Control

TCP also controls how fast it sends.

Flow control stops a fast sender from overwhelming a slow receiver. The receiver keeps reporting how much more data it can accept right now.
Congestion control stops the sender from overloading the network. A new connection starts by sending slowly and speeds up step by step. When packets are lost, TCP takes that as a sign the network is busy, and it slows down.

The Costs of TCP

All of these promises add work and delay.

The handshake adds a round trip before any data moves.
Every piece of data waits for acknowledgements, and lost data waits for retransmission.
Congestion control slows the sender down when the network is busy.
The TCP header is at least 20 bytes on every packet.

There is one more cost, called head-of-line blocking. TCP delivers data only in order. So if one packet is lost, every packet after it waits, even if those packets already arrived. The application sees nothing new until the lost packet is sent again. The next lesson shows how this problem led to changes in newer versions of HTTP.

When to Use TCP

Use TCP when accuracy matters more than speed. Common examples are below.

Web browsing, with HTTP and HTTPS.
Email, with SMTP, POP3, and IMAP.
File transfer, with FTP, and any download.
Database connections and most calls between services.

Loading a web page is the everyday example. Every stylesheet, script, and image has to arrive complete and in order, or the page breaks.

UDP

UDP stands for User Datagram Protocol. It is connectionless. It sends messages called datagrams without setting up a connection first, and it does not promise delivery or order.

No setup. The first datagram can leave immediately. There is no handshake.
Low overhead. The UDP header is only 8 bytes. There are no acknowledgements and no retransmission.
Unreliable. A datagram can be lost, arrive twice, or arrive out of order, and UDP will not fix it. UDP has a checksum, but a damaged datagram is simply thrown away, not sent again.
No congestion control. UDP does not slow down when the network is busy. It keeps sending at the same rate, and some datagrams may be dropped.

UDP is faster than TCP because it skips the connection setup, the acknowledgements, and congestion control.

Why Real-Time Apps Choose UDP

For some applications, late data is worse than missing data.

Think of an online game that sends each player's position 30 times per second. Suppose one update is lost. With UDP, the next update arrives about 33 ms later, and it replaces the lost one. With TCP, the newer updates would wait until the lost one was sent again. The player would see the game freeze, then jump.

A game sends positions over UDP, update 3 is lost, and the player simply uses update 4, which is newer anyway

The same is true for voice and video calls, and for live streams. A lost packet causes a short glitch. Waiting for a resend would cause a delay that keeps growing.

When to Use UDP

Use UDP when speed matters more than perfect accuracy, and some loss is acceptable. Common examples are below.

Live video and audio streaming.
Online games.
Voice over IP (VoIP) and video calls.
DNS lookups. A lookup is one small question and one small answer. If it is lost, the client simply asks again after a short wait.

Some applications need both speed and reliability. They use UDP and build only the reliability they need on top of it. QUIC, the protocol under HTTP/3, works this way.

TCP and UDP Side by Side

	TCP	UDP
Connection	Set up first, with a handshake	None, sent immediately
Reliability	Lost data is sent again	Lost data stays lost
Order	Always in order	May arrive out of order
Speed and overhead	Slower, 20-byte header or more	Faster, 8-byte header
Flow and congestion control	Yes	No
Good fit	Web, email, file transfer	Streaming, gaming, calls, DNS

TCP fits applications where every byte must arrive, and UDP fits applications where fresh data matters more than complete data

Choosing TCP means accepting some delay. A file transfer must deliver every byte accurately and in order. It needs TCP, and it accepts the extra time for acknowledgements and congestion control. A file with a missing piece is useless.

Choosing UDP means accepting some loss. A live audio stream over UDP gets low latency. Because UDP has no congestion control, it keeps sending at the same rate even when the network is busy. Some packets are dropped instead of delayed. For live audio, a short glitch is better than a delay that keeps growing.

A useful question is: "If one piece is missing, does the result break, or does it only have a small glitch?" If it breaks, use TCP. If it only glitches, UDP is often the better choice.

Key Takeaways

TCP and UDP run on top of IP. They add ports, which identify programs, and their own rules for delivery.
TCP is connection-oriented. It uses a three-way handshake, and it delivers data reliably, in order, and error-checked.
TCP uses sequence numbers, acknowledgements, retransmission, flow control, and congestion control. These make it slower, and a lost packet causes head-of-line blocking.
UDP is connectionless. It sends datagrams with no setup, no acknowledgements, and no congestion control, so it is faster but may lose data.
Use TCP when accuracy matters more than speed, like web browsing, email, and file transfer.
Use UDP when speed matters more than accuracy, like live streaming, online games, VoIP, and DNS lookups.

TCP promises that every byte arrives in order, and it spends time to keep that promise. UDP promises only speed, and the application decides what to do about loss. The next lesson, HTTP/1.0 vs HTTP/1.1 vs HTTP/2.0 vs HTTP/3.0, shows how HTTP changed as it used these protocols in new ways.

Practice Questions

Try each question first, then open the answer.

1. A round trip between a client and a server takes 80 ms. How long does the TCP handshake take before the client can send its first request? How long is the wait if HTTPS with TLS 1.3 runs on top?