TCP vs UDP: What's the Difference? Reliability vs Speed
TCP and UDP are both sets of rules for delivering data, and both run on top of IP. TCP checks that data arrived, resends what is lost and hands data over in order. So it is used where gaps are not acceptable, such as the web and email. UDP just sends, without checking. With fewer steps, it suits calls, games and short lookups, where delay hurts most.
What you'll learn
- Why IP alone is not enough, and the jobs TCP and UDP take on
- What a port number stands for (ports 80, 443, 53 and others)
- How TCP delivers reliably (greeting, numbers and replies, resending, pacing)
- When UDP is chosen, and QUIC, a newer set of rules built on top of UDP
Prerequisites: none. Reading "How Is Data Sent Over the Internet?" (about packets and routers) first will make this easier.
In everyday life
When you open a web page, you almost never see text missing from the middle. Paragraphs don't show up in the wrong order either. On a video call, though, a voice may cut out for a moment, or the picture may skip.
Both travel over the same internet. What differs is the approach to delivering data. The web values getting everything right, even if it takes a little longer. Calls value having no delay, even if a little is missing. TCP and UDP are the two main examples of these two approaches.
IP alone can't tell whether data arrived
On the internet, data is split into small chunks called packets. Devices called routers pass them along to the destination. This is explained in detail in "How Is Data Sent Over the Internet?" The rules for carrying packets to their destination are called IP. IP focuses on sending packets out. It does not check whether they arrived.
So along the way, things like these can happen:
- A router that is too busy throws packets away (they are lost)
- The route changes, and a packet sent later arrives first (the order gets mixed up)
- The same packet arrives twice (it is duplicated)
It would be a lot of work for every browser and calling app to fix these problems on its own. So one more layer sits between IP and the apps. It is called the transport layer, and TCP and UDP are its main members.
Both are defined in public documents that set out the internet's technical rules, called RFCs. The basic form of UDP was written down in 1980, and that of TCP in 1981. For TCP, a document gathering more than 40 years of improvements came out in 2022.
Port numbers: which app on the device
An IP address is the number that says which device a packet goes to (see "What Is an IP Address?"). But inside one phone, the browser, email and calling apps all communicate at the same time. Which app should get each packet that arrives?
So TCP and UDP write one more number in the header. The header is the part at the start of a packet that holds the destination and similar details. This number, from 0 to 65,535, says which "reception desk" inside the device the data is for. It is called a port number. Together, the IP address and port number get data all the way to an app on the other device.
On servers, the desk numbers are mostly fixed by purpose. The web uses 80 (HTTP) and 443 (HTTPS). DNS, which looks up numbers from names, uses 53. Ports 0 to 1023 are assigned to widely used purposes and are called well-known ports.
On the phone's browser side, a number is picked from the free ones each time a connection starts. Replies come back to that number. So even with two connections to the same server at once, the replies don't get mixed up.
TCP: first a greeting, then a connection
Before sending data, TCP exchanges a short greeting with the other side. It takes three messages:
- The sender says, "I want to start talking. My serial numbers start here." (SYN)
- The receiver replies, "Got it. My numbers start here." (SYN+ACK)
- The sender replies, "OK." (ACK)
SYN and ACK are names of markers: SYN means "I want to start," and ACK means "received." Because it takes three messages, this is called the three-way handshake. Each side confirms where the other starts counting. This prevents mix-ups with old packets still left in the network.
Once both sides have confirmed "I'm talking with this partner," they are in a state called a connection.
The greeting costs one round trip: the time for data to go out and a reply to come back. Between Tokyo and Los Angeles, that is about 0.1 seconds. With HTTPS, setting up encryption comes after this (see "What Does HTTPS Mean?").
Sequence numbers and "got it" replies
TCP gives the data it sends serial numbers. Each number shows a position in the data, counted in bytes from the start. (One byte is eight 0s and 1s in a row.) This number is called the sequence number.
The receiver sends back a reply: "Everything up to here has arrived. Next, please send from this number." This reply is called an acknowledgment, or ACK for short.
The sender does not wait for each reply before sending the next piece. Up to a certain amount, it keeps sending without waiting. If it waited every time, the farther away the other side was, the slower things would get.
No reply? Send it again
If the reply for some data doesn't come within a set time, the sender assumes the data was lost on the way. It then sends the same data again. This is called retransmission.
The waiting time is set by measuring the round-trip time to the other side. Before any measurement, the starting value is 1 second. If a resend still gets no reply, the waiting time doubles. Sometimes later data keeps arriving, yet the same reply, "only up to here," repeats again and again. Then the sender judges that a piece is missing and resends it without waiting.
But resending does not go on forever. If no reply comes no matter how many times it resends, TCP gives up and closes the connection (see "Common myths" below).
Putting data in order and dropping duplicates
The receiver uses the sequence numbers to put the data back in the right order. If data with the same number arrives twice, it throws one copy away. This way, the app gets data in the order it was sent, with nothing missing or doubled.
The trade-off: if even one piece is missing, later data is not passed to the app, even if it has arrived. The later data waits until the resent piece arrives. This waiting is one of the problems that QUIC, covered later, set out to reduce.
Pacing the amount sent: flow control and congestion control
The receiving device has a place to hold arriving data for a while (memory for receiving). If the app can't read data out fast enough, this place overflows. So with every reply, the receiver tells the sender how much room is left: "I can take this much more." This mechanism keeps the sender from going over that amount. It is called flow control.
The network in between can also overflow. When everyone sends a lot at once, routers can't keep up and throw packets away. TCP starts by sending only a little, then sends more while watching how delivery goes. In many versions, lost packets are taken as a sign of crowding, and the amount sent is cut sharply. This mechanism is called congestion control.
Congestion control was added to TCP because of a real problem. In October 1986, a link in the US slowed from 32 kilobits per second to 40 bits per second. It ran between a research lab and a university a few hundred meters apart. Each computer resent what was lost, which crowded the line even more: a vicious circle. Researcher Van Jacobson and others worked out a fix and published it in a 1988 paper.
UDP: send right away, without checking
UDP does no greeting, no checking of replies, no resending and no reordering. It writes the port numbers and a few other details in the header and simply sends the data as it is. So its header is also smaller than TCP's.
Then what happens to data lost on the way? UDP itself does nothing, so the app decides. A calling app gives up on the lost moment of sound and plays the next sound. If needed, an app can also number the data itself and resend only the important parts.
UDP also does not pace the amount sent. So apps that send a lot over UDP need to control their own speed, so they don't crowd the network.
When "no delay" matters most
In a conversation, a long delay makes people talk past each other. The International Telecommunication Union (ITU) gives a guideline on delay in its Recommendation G.114. For most uses, a one-way delay of up to 0.15 seconds is barely noticeable in conversation.
If a call were sent over TCP, a lost piece of sound would also stop the sound after it, while waiting for the resend. By the time the resend arrived, the conversation would have moved on. That is why calls and fast-paced games prefer UDP, which keeps going even when something is lost.
Which is used for what
| Use | Mainly uses | Why |
|---|---|---|
| Web pages (HTTP/1.1, HTTP/2) | TCP | Missing text or images would be a problem |
| Email and file transfers | TCP | A single gap can break the whole thing |
| DNS lookups | UDP (TCP for large answers) | A short exchange done in one round trip |
| Video and voice calls | UDP (TCP when UDP can't get through) | Late sound is useless |
| Fast-paced online battle games | Usually UDP | The newest position is what matters |
| Video streaming (recorded and live) | Mostly HTTP (over TCP or QUIC) | Video is stored ahead before playing, so there is time to resend |
How DNS works is explained in "How Does DNS Work?" To compare the two point by point in a more detailed table, see "TCP vs UDP."
QUIC: reliability and encryption on top of UDP
HTTP/3, the newest version of HTTP used by the web, does not use TCP. Instead, it uses a set of rules called QUIC, built on top of UDP. QUIC does the same jobs as TCP by itself: numbering and replies, resending, and pacing the amount sent. It also builds in TLS, the encryption used by HTTPS, and always encrypts the contents.
Why go to the trouble of building new rules on top of UDP? One reason is the devices along the way. Many home routers and company firewalls block kinds of packets they don't recognize. With UDP, the new rules can pass through today's networks as they are.
Another reason is that it is easier to rebuild. TCP is built into the OS, the basic software of a PC or phone. So improvements take years to reach everyone. QUIC runs inside apps such as browsers, so improvements can arrive with an app update.
QUIC combines TCP's greeting and the encryption setup into a single round trip. TCP plus TLS usually takes two round trips. QUIC also keeps the order separately for each stream of data, such as images and text. So a single gap now holds up unrelated data less often.
QUIC became a standard as RFC 9000 in May 2021, and HTTP/3 as RFC 9114 in June 2022. According to the survey company W3Techs, close to 40% of the websites it checked could use HTTP/3 in 2026. Some networks don't let UDP through. In that case, browsers switch to HTTP/2 or similar over TCP. The differences between versions are summed up in a table at "HTTP/1.1 vs HTTP/2 vs HTTP/3."
Common myths
Myth: UDP is always faster
In fact, what UDP skips is the work of greeting and checking. It does not make the line itself any faster. The time to send a large file depends mainly on the speed of the line.
Sending a lot without checks makes routers throw packets away, so more data goes missing. To deliver reliably, the app has to build its own resending. Depending on how that is built, it can end up slower than TCP. UDP has the edge when you want to keep delay low, or for short exchanges done in one round trip.
Myth: With TCP, data always gets through, no matter what
In fact, TCP promises only this: whatever arrives is handed over in order, with nothing missing or doubled. If a cable comes loose, you move out of Wi-Fi range or the server stops, resending will not get the data through.
If that state continues, TCP gives up and closes the connection. A 1989 standard on requirements for internet devices recommends resending data for at least 100 seconds. The app is told that the connection was lost, and the app decides whether to try again.
Myth: Games and video always use UDP
In fact, most recorded video and live streams are sent over HTTP, the same as the web. A few seconds are stored ahead before playing, so there is time to resend what was lost. YouTube uses QUIC as well as TCP.
For games, too, the choice depends on the type of game. Battle games, where a split-second move decides the match, often use UDP. Games that don't need an instant response often do fine with TCP.
By the numbers
| Item | Number | Date and source |
|---|---|---|
| Header size | TCP 20 bytes, UDP 8 bytes | TCP without extra fields (RFC 9293, RFC 768) |
| Port number range | 0 to 65,535 | 0 to 1023 are well-known ports (IANA) |
| Setup before data can flow | TCP 1 round trip, 2 with TLS added; QUIC 1 round trip | With TLS 1.3 |
| One round trip, Tokyo–Los Angeles | About 0.11 seconds | Monthly average, early 2026 (Verizon) |
| First wait before resending | 1 second (doubling after that) | Starting value before the round-trip time is measured (RFC 6298, 2011) |
| Slowdown from congestion in 1986 | 32 kilobits → 40 bits per second | Paper by Jacobson and others (1988) |
| Year it became a standard | UDP 1980, TCP 1981 (revised 2022), QUIC 2021, HTTP/3 2022 | IETF RFCs |
| Websites that can use HTTP/3 | Close to 40% (37 to 40%) | 2026, W3Techs |
If the round trip to the other side takes 0.11 seconds, cutting setup by one round trip makes data start arriving about 0.1 seconds sooner. The farther away the other side is, the more it pays to cut round trips.
Learn more
- Compare in a table: TCP vs UDP (down to headers, how data is divided and kinds of destinations)
- Try the math: the data transfer time calculator (you can enter the effect of headers and resending as "transmission efficiency")
- Terms for the next step: RTT (the time until a reply comes back), MTU (the largest packet that can be carried at once)
- A security term: firewall (a system that limits traffic in and out by looking at port numbers and similar details)
- From the start of the series: "How Is Data Sent Over the Internet?"