TCP guarantees delivery, order and integrity by opening a connection, numbering bytes and retransmitting losses. UDP guarantees none of that and sends a datagram with an eight byte header. TCP when losing data is worse than waiting, UDP when waiting is worse than losing data.
- TCP header 20 bytes, UDP 8
- TCP costs one round trip before any data
- One lost packet stalls a TCP stream
- UDP has no congestion control at all
- QUIC rebuilt TCP guarantees on top of UDP
On this page
What TCP givesWhat TCP actually does for you
TCP is often described as reliable, which is true and unhelpfully vague. It provides five specific services, and each one has a cost.
A connection. Before any data moves, the two ends exchange three packets: a request to open, an acknowledgement of it, and an acknowledgement of that. This is the three way handshake, and it costs one full round trip before the first byte of anything useful. On a link with 100 milliseconds of latency, that is 100 milliseconds spent agreeing to talk.
Ordered delivery. Every byte is numbered. Packets that arrive out of order are held until the missing ones arrive, then passed up in the right order. The application never sees the reordering.
Error checking and retransmission. Every segment carries a checksum, so corruption is detected. The receiver acknowledges what arrived intact, and anything the sender does not see acknowledged within a timeout is sent again. This error recovery is why a TCP transfer survives a lossy link, and why its speed drops on one.
Flow control. The receiver advertises how much it can accept, so a fast sender cannot overwhelm a slow receiver.
Congestion control. The sender infers the state of the network from losses and delays and adjusts its rate. This is the part that makes the internet work at all, and it is also why one lost packet slows a whole transfer.
The last two are the underrated ones. Without congestion control the network collapses under its own load, which is a thing that actually happened in the nineteen eighties and led to the algorithms in use today.
What UDP givesWhat UDP does instead
UDP does almost nothing, deliberately, and the list of what it does not do is the specification.
UDP adds four fields to an IP packet: source port, destination port, length, and a checksum for error detection. That is the entire eight byte header. There is no connection, no sequence number, no acknowledgement, no retransmission, no ordering and no congestion control, so error recovery is left to the application.
What that buys is threefold.
No setup. The first packet carries data. There is no round trip spent agreeing to communicate, which matters enormously for a protocol like DNS where the whole exchange is one question and one answer.
No head of line blocking. In TCP, one lost packet stalls everything behind it until it is retransmitted, because delivery must be ordered. In UDP a lost datagram is simply missing, and the ones after it arrive on time.
For live audio, a missing twenty milliseconds is a small glitch and a two hundred millisecond stall to recover it is much worse.
No state. A server holding a million UDP conversations holds no per connection state in the kernel, which is why UDP scales differently.
The catch is that anything the application actually needs, it has to build itself. Every serious protocol on top of UDP ends up implementing some retransmission and some ordering, which is a genuine argument that most of them should have used TCP.
Who uses whatWhich protocols use which
Most TCP vs UDP decisions are already made for you by the protocol you are using, so the list is worth knowing as a shortcut to the reasoning.
TCP carries the web, email, file transfer, remote desktop, database connections, and anything with the word transfer in its name. If truncated data would be a corruption rather than a glitch, it is TCP.
UDP carries DNS lookups, voice and video calls, live streaming, online gaming, network time, logging, and network monitoring. If the data has a shelf life measured in milliseconds, it is UDP. Gaming is the clearest case: a player position from 200 milliseconds ago is worse than useless, because a newer one has already arrived.
Both appear in some protocols. DNS uses UDP for ordinary queries and switches to TCP when a response is too large or when the transfer is a zone transfer. This is why a firewall that permits DNS on UDP only breaks in unusual and hard to diagnose ways.
The exceptions worth knowing
Video streaming is mostly TCP now. Netflix and its peers deliver over HTTPS, which is TCP, because buffering a few seconds ahead makes reliability free and a content delivery network is easier to build on the web stack. Live streaming with sub second latency is a different problem and does use UDP.
VPNs are usually UDP. Tunnelling TCP inside TCP produces two congestion control loops fighting each other, and a lossy link makes both back off. This is the classic TCP over TCP meltdown, and it is why IPsec and WireGuard use UDP and why an SSL VPN offers a UDP mode you should prefer.
QUIC put TCP's guarantees on UDP. The protocol under HTTP/3 runs on UDP and rebuilds reliability, ordering and congestion control in userspace, plus encryption and multiple independent streams. The reason is that a stream that loses a packet should not stall the others, which TCP cannot express.
It is not an argument that UDP is better; it is an argument that TCP's guarantees are the right ones and its implementation is stuck in the kernel.
In a captureReading a packet capture
The two are easy to tell apart once you know where to look, and the fields explain the behavior.
A TCP segment carries sequence and acknowledgement numbers, a window size, and a set of flags. The flags name the phase: SYN opens, SYN with ACK answers, ACK confirms, FIN closes politely, RST refuses or aborts.
A capture that shows SYN with no reply is a firewall dropping it. A capture that shows SYN and then RST is something actively refusing, which usually means nothing is listening on that port.
A UDP datagram carries the four fields and nothing else. There is no state to observe, so troubleshooting means looking at the application protocol inside rather than at UDP itself.
Two symptoms that come up constantly:
Retransmissions in a TCP capture mean packets are being lost somewhere. A few are normal. A pattern of them, with the window shrinking, is a link with a problem.
Duplicate acknowledgements mean the receiver got something out of order and is asking for the missing piece. Three of them in a row triggers a fast retransmit without waiting for the timeout.
PitfallsWhere people go wrong
Assuming UDP is simply faster. It has less overhead and no setup, which is not the same as more speed. On a good link a TCP transfer will saturate it just as well, and the performance difference disappears. What UDP avoids is waiting, not bandwidth.
Permitting a protocol on the wrong one. A firewall rule for DNS on UDP only works until an answer exceeds what a single datagram carries, and then queries fail intermittently for reasons nobody connects to the rule.
Blaming UDP for loss. UDP does not lose packets. The network does, and TCP hides it by retransmitting. A voice call with dropouts is reporting a network problem that a file transfer over the same link would have concealed.
Tunnelling TCP inside TCP. Two congestion control loops on one path fight, and throughput collapses on a lossy link. Use the UDP mode of the tunnel.
Forgetting that UDP has no back pressure. An application that sends as fast as it can over UDP will happily flood a link and hurt everything else on it, because nothing tells it to slow down. That responsibility moved to the application and is often forgotten.
ComparisonTCP and UDP, guarantee by guarantee
| Criterion | TCP | UDP |
|---|---|---|
| Connection | Established first, three way handshake | None, send and forget |
| Header size | 20 bytes minimum | 8 bytes, fixed |
| Delivery guaranteed | Yes, by retransmission | No |
| Order guaranteed | Yes | No |
| One lost packet | Stalls everything behind it | Affects only itself |
| Congestion control | Built in, and it is what keeps the internet stable | None, the application must behave |
| Time to first byte | One round trip of setup first | Immediate |
| State on the server | Per connection, in the kernel | None required |
| Broadcast and multicast | Not possible | Supported |
| Best fit | Anything where a missing byte is a bug | Anything where a late byte is useless |
FAQFrequently asked questions
What is the main difference between TCP and UDP?
TCP establishes a connection and guarantees that data arrives, intact and in order, retransmitting what goes missing. UDP sends datagrams with no connection and no guarantees.
Is UDP faster than TCP?
It has lower overhead and no setup delay, so the first byte arrives sooner and a lost packet does not stall the rest. Raw speed on a healthy link is similar, and the difference in performance shows up under loss and latency rather than in bandwidth.
Why does TCP need a handshake?
To agree that both ends are present and willing, and to exchange starting sequence numbers. It costs one round trip before any data moves.
What is head of line blocking?
In TCP, one lost packet holds up everything behind it, because data must be delivered in order. UDP has no such rule, which is why live media prefers it.
Which one does DNS use?
UDP for ordinary queries, and TCP when the answer is too large for one datagram or for a zone transfer. Permitting only UDP breaks DNS in confusing ways.
Which does video streaming use?
Most on demand streaming is TCP over HTTPS, because a few seconds of buffer makes reliability free. Low latency live video uses UDP.
Why do VPNs prefer UDP?
Because TCP inside TCP produces two congestion control loops that fight each other, and throughput collapses on a lossy link.
What is QUIC?
A protocol running on UDP that rebuilds reliability, ordering and congestion control in the application, with encryption built in. It carries HTTP/3, and it exists so that one lost packet does not stall unrelated streams.
How big are the headers?
TCP is 20 bytes minimum and can reach 60 with options. UDP is always 8.
Can UDP be used for broadcast?
Yes, and TCP cannot. Broadcast and multicast require a protocol with no connection, which is one of UDP's genuine exclusives.
What does a RST mean in a capture?
Something refused or aborted the connection. Immediately after a SYN it usually means nothing is listening on that port.
Does UDP have error checking?
It has a checksum, optional on IPv4 and required on IPv6. It detects corruption and does nothing about it, since there is no retransmission. Any error recovery has to be built by the application.
What is the full form of TCP and UDP?
The TCP UDP full form is Transmission Control Protocol and User Datagram Protocol. Both are transport layer protocols that run on top of IP. TCP sets up a connection and guarantees ordered delivery. UDP sends independent datagrams with no connection and no guarantee.
Keep readingRelated concepts
Read next · Remote access VPN vs Proxy The choice of transport is why a VPN offers a UDP mode you should prefer. Open this next13 min- Remote access · 11 min What Is an IPsec VPN? A tunnel that runs on UDP, for the reason described in the exceptions above.
- Infrastructure · 12 min What a Load Balancer Does, and the Two Decisions Behind It The transport the layer 4 case works on.
- Routing · 12 min What Is BGP? The transport BGP chose, and what it buys over the alternative.
- Infrastructure · 11 min Quality of Service, and the Condition It Needs to Do Anything Why inbound QoS works for one and not the other.
- Addressing · 9 min What Is DHCP? The protocol underneath DHCP, and why it is the one without a handshake.
- Ports · 12 min What Is a Port Number? The number inside those headers that decides which application receives the data.
- Cabling and connectivity · 10 min Cat6 vs Cat6a The cable those protocols run across, and the distance at which it stops working.
- Diagnostics · 11 min Ping and Traceroute The transport underneath the probes these commands send.
- Routing · 10 min BGP States, and Why Only Three of the Six Ever Appear on Screen A protocol whose failure states are TCP failure states.
- Protocols · 10 min The TCP Header, Field by Field, and What to Read in a Capture Why the eight byte alternative exists at all.
- Ports · 10 min Port 53, and Why DNS Needs TCP as Well as UDP The two transports, and why this protocol uses each of them.
- Diagnostics · 11 min Packet Loss vs Latency, and Why They Feel the Same to Users The two transports, and why they react to loss so differently.
- Remote access · 11 min NAT Traversal, and Why One Way Audio Is Always the Same Bug Why these protocols are built on the transport they are.
- Ports · 9 min SNMP Ports 161 and 162, and the Firewall Rule That Is Half Right A protocol where a dropped datagram means a lost alert, on two ports facing opposite ways.
- Network fundamentals · 9 min TCP Window Size, and Why It Caps Your Throughput The protocol comparison behind TCP flow control.