We have spent this series following data on its journey. We gave it a network to travel on, a way to travel in packets, layers to pass through, an address to aim for, and a name that resolves to that address. By now, a connection can find its destination anywhere in the world.
But finding the destination is not the whole story. Once two machines are ready to exchange data, they face a decision, and it is one of the most consequential decisions in all of networking. Do they want the exchange to be reliable, where every piece is guaranteed to arrive, in order, no matter what, or do they want it to be fast, where data flies with the least possible delay, even if the occasional piece goes missing?
This is the reliability-versus-speed tradeoff, and it lives at Layer 4, the transport layer from our OSI post. Almost everything that travels the internet is carried by one of two transport protocols that answer this question in opposite ways. TCP chooses reliability. UDP chooses speed. Neither is better. They are two different tools for two different jobs, and knowing which does what, and why, explains an enormous amount about the behaviour of everything you use online.
Let us meet them properly.
The Whole Idea, in One Picture
Before any mechanics, hold this comparison in your head, because everything else is just detail hanging off it.
Imagine you need to send an important series of documents to someone.
TCP is the recorded-delivery courier. It establishes contact with the recipient first, confirms they are ready, and only then begins. It numbers every package, waits for a signed confirmation that each one arrived, and if any package is lost or damaged, it notices and sends another copy. It guarantees that everything arrives, complete and in the right order. That reliability is wonderful, but it has a cost: all that confirming, waiting, and re-sending takes time, and adds overhead.
UDP is the person who writes messages on postcards and drops them in the postbox as fast as they can. No prior contact, no confirmation, no record of what was sent. Most postcards arrive, usually quickly. But if one gets lost in the post, nobody notices and nobody re-sends it. What you lose in guarantees, you gain in raw speed and simplicity.
That is the entire tradeoff. TCP trades speed for reliability. UDP trades reliability for speed. Every other fact in this post is a consequence of that one difference.
TCP: The Reliable One, in Depth
TCP stands for Transmission Control Protocol, and it is described as connection-oriented. That single word is the key to everything it does. Before TCP sends any real data, it establishes a formal connection between the two machines, a shared agreement that both are present, ready, and synchronised. Nothing meaningful is sent until that connection exists.
Building that connection is the job of one of the most famous exchanges in all of networking.
The Three-Way Handshake
When a TCP connection opens, the two machines perform a three-step exchange called the three-way handshake. It is worth understanding step by step, because it appears everywhere, including in the security section later.
Step 1, SYN. The client that wants to connect sends a SYN packet (SYN is short for "synchronise"). This is the opening knock. In it, the client proposes a connection and includes an initial sequence number, a starting count that will be used to keep all the following data in order.
Step 2, SYN-ACK. The server receives the knock and responds with a SYN-ACK packet. This does two things at once: it acknowledges the client's request (the ACK, "acknowledge") and it sends the server's own initial sequence number (its own SYN). The server is saying, in effect, "I heard you, I am ready, and here is my starting count too."
Step 3, ACK. The client sends a final ACK packet, acknowledging the server's response. Now both sides have confirmed they can send and receive, both have exchanged sequence numbers, and both move into the ESTABLISHED state.
Only after these three messages does a single byte of actual application data flow. Notice why three steps and not two: two messages would only confirm that the server can hear the client, not that the client can hear the server. The third message closes that loop, confirming two-way communication and letting both sides agree on where their numbering begins. It also helps prevent old, duplicate connection requests from being mistaken for new ones.
Acknowledgements and Retransmission
Once the connection is established, TCP's reliability machinery goes to work on every piece of data.
TCP breaks your data into numbered segments and sends them. The receiver acknowledges what it has received, but in a clever way: it acknowledges by naming the next byte it expects, not the last one it got. So if the receiver has successfully taken in everything up to byte 1000, it sends an acknowledgement saying "I am now expecting byte 1001."
Here is where the reliability becomes concrete. Suppose the segment carrying bytes 1001 to 1500 goes missing in transit. The receiver never gets it, so it keeps acknowledging "I am expecting 1001," over and over, even as later segments arrive. Those repeated acknowledgements are a signal: a gap has opened. The sender detects the loss in one of two ways, either it receives several duplicate acknowledgements for the same byte, or its own timer for that segment expires with no fresh acknowledgement at all. Either way, it re-sends the missing segment. Nothing is lost, because TCP simply refuses to move on until the gap is filled.
Ordering
Data can take different paths across the internet, so segments sometimes arrive out of order. Because every segment is numbered, TCP can reassemble them into the correct sequence before handing them to the application. And crucially, if a segment is missing, TCP holds back everything that arrived after the gap until the missing piece is retransmitted and slotted into place. The application never sees jumbled or incomplete data. It only ever receives a clean, ordered stream, exactly as it was sent.
Flow Control
There is one more piece of the machinery worth knowing. What happens if the sender is a powerful server and the receiver is a slow device that cannot keep up? Without some control, the fast sender would overwhelm the slow receiver, and data would be dropped simply because the receiver had no room for it.
TCP prevents this with flow control. The receiver constantly tells the sender how much data it is currently able to accept, a value called the window. The sender respects this limit, slowing down or speeding up so it never sends more than the receiver can handle at that moment. It is a continuous negotiation that keeps a fast sender from drowning a slow receiver, and it is another reason TCP is described as reliable: it manages not just loss, but pace.
The Cost
All of this machinery, the handshake, the acknowledgements, the retransmissions, the ordering, the flow control, is what makes TCP dependable. But it is not free. Every connection begins with a full round trip before any data moves. Every segment carries a header that starts at 20 bytes. Every piece of data waits for confirmation. This adds overhead and latency. For most uses that cost is completely worth it, and invisible. But for some uses, as we will see, it is exactly the wrong trade, and that is where UDP comes in.
As a historical note, TCP is one of the oldest protocols on the internet, originally defined in 1981. It has been refined for over four decades, and the current standard, published in 2022, consolidates all those years of fixes into a single modern specification.
UDP: The Fast One, in Depth
UDP stands for User Datagram Protocol, and where TCP is connection-oriented, UDP is connectionless. This is the heart of the difference. UDP performs no handshake, establishes no connection, and keeps no shared state. The sender simply packages data into units called datagrams and fires them at the destination address and port, with no setup and no expectation of a reply.
Everything TCP carefully does, UDP deliberately does not. There is no acknowledgement that a datagram arrived. There is no retransmission if one is lost, a dropped datagram is simply gone, and any recovery is left entirely to the application to handle if it wants to. There is no guarantee of ordering, datagrams may arrive in a different order than they were sent. And there is no flow control.
This might sound like a broken version of TCP. It is not. It is a deliberately minimal design, and its minimalism is the entire point. Because it skips the handshake, the acknowledgements, and the retransmissions, UDP avoids the round trips and the waiting that those mechanisms require. Its header is only 8 bytes, compared to TCP's 20 or more. The result is dramatically lower latency and overhead. UDP nearly always wins on speed, because it is doing so much less.
The key insight is this: for some applications, a lost piece of data is not worth the delay it would take to recover it. Think about a live voice call. If a tiny fragment of audio is lost, you do not want the protocol to stop everything, go back, and re-send that fragment, because by the time it arrived, the conversation would have moved on and you would hear a stutter or a delay. You would much rather it simply skip the lost fragment and keep the call flowing in real time. For live, real-time data, a late packet is often worse than a lost one. That is precisely the situation UDP is built for.
Who Uses Which, and Why
The tradeoff makes the choice almost obvious once you see it. The question is always: for this application, what matters more, that every byte arrives, or that data arrives with minimal delay?
TCP is used where completeness is non-negotiable. Web pages ride on TCP, because a page with missing bytes is broken. Email uses TCP, because a message must arrive whole. File transfers use TCP, because a downloaded file with a missing chunk is corrupt and useless. Anything where the loss of even a single byte would ruin the result uses the courier who guarantees delivery. When you loaded this page, that was TCP doing its careful work, and you never noticed, which is exactly the point.
UDP is used where speed matters more than perfection. Live video streaming and video calls use UDP, because a dropped frame is better than a frozen picture. Voice over IP, the technology behind internet calls, uses UDP for the same reason. Online gaming uses UDP, because the current position of a player is what matters, and a delayed update about where they were a moment ago is useless. And DNS, the phone-book system from our last full post, uses UDP for its quick lookups, because a query and its answer usually fit in a single small packet and speed is essential, though it switches to TCP for larger responses.
Once you internalise the tradeoff, you can often guess correctly which protocol any given application uses, just by asking whether it would rather be complete or fast.
The Security Dimension: When the Design Becomes the Weakness
Here is the thread that runs through this entire series, appearing once again. The very design choices that make these protocols work are also what make certain attacks possible. Understanding TCP and UDP is not just useful for building things. It is essential for understanding a whole category of attacks, because the attacks target the protocols' fundamental mechanics.
The SYN Flood: Weaponising the Handshake
Remember the three-way handshake, and specifically what the server does at step two. When a server receives a SYN, it responds with a SYN-ACK and then waits for the final ACK to complete the connection. While it waits, it holds that connection half-open, setting aside a small amount of memory and a slot in its connection queue for it. This is completely normal, and the half-open connection times out and clears after a short period, roughly a minute, if the final ACK never comes.
An attacker can weaponise this. In a SYN flood attack, the attacker sends a rapid stream of SYN packets, thousands per second, but never sends the final ACK for any of them. Each one forces the server to open another half-open connection and reserve resources for it. If they arrive fast enough, the server's connection queue fills entirely with these incomplete handshakes, and there is no room left for legitimate connections. Real users are turned away, not because the server was flooded with overwhelming traffic, but because its handshake mechanism was turned against it. It is an elegant and nasty attack precisely because it abuses TCP working exactly as designed.
The primary defence is a clever technique called SYN cookies. Instead of reserving memory the moment a SYN arrives, the server encodes the connection information into the sequence number it sends back in the SYN-ACK, and allocates no resources yet. Only when a legitimate final ACK returns, carrying that encoded information back, does the server actually set up the connection. This means a flood of SYNs that never complete costs the server almost nothing, because it was never holding state for them in the first place. Other mitigations include rate-limiting incoming SYNs, enlarging the connection queue, and recycling the oldest half-open connections to make room.
UDP Amplification: Weaponising Connectionlessness
UDP's defining feature, that it is connectionless and requires no handshake, creates a different and equally serious weakness. Because there is no handshake to prove who you are, it is trivial to lie about your own address. An attacker can send a UDP request while forging the source address, so the reply is sent not to the attacker but to whoever they named. This is called spoofing, and connectionless protocols make it easy, because nothing ever verifies that the sender is who they claim to be.
Now combine that with a second idea. Some UDP-based services reply to a small request with a much larger response. An attacker exploits this by sending many small requests to these services, each one forged to appear to come from the victim's address. The services dutifully send their large responses to the victim, who is buried under a flood of traffic they never asked for. This is a reflection and amplification attack, and the numbers are staggering. A DNS-based amplification can multiply the attacker's traffic by roughly 28 to 54 times. Using misconfigured time servers, the NTP protocol, the amplification can reach over 500 times. And exploiting exposed memcached servers, the factor can exceed fifty thousand times, meaning a trickle of attacker traffic becomes a torrent aimed at the victim.
A famous real-world demonstration of this class of attack came from the Mirai botnet, which harnessed vast numbers of insecure internet-of-things devices, the cheap cameras and routers we discussed segmenting away in the subnetting post, to launch some of the largest denial-of-service attacks ever recorded. It is a direct illustration of how these transport-layer weaknesses, combined with poorly secured devices, translate into real and massive disruption.
Defences against amplification focus on the root causes: network operators filtering traffic with forged source addresses so spoofing becomes harder, operators securing or closing the exposed services that do the amplifying, and dedicated mitigation services absorbing and scrubbing the flood before it reaches the target. As always in this series, no single fix is complete, and defence is layered.
The lesson is consistent with everything we have seen. These are not bugs in TCP or UDP. They are the direct consequences of the exact design choices, the handshake and the connectionless simplicity, that make the protocols useful. To defend a system, you have to understand the mechanics of what it is built on.
Commands to See It Yourself
Both protocols are visible on your own machine with the right tools.
See active TCP connections and listening ports:
netstat -ant (shows all TCP connections and their state)
ss -t (a modern Linux equivalent)
Look at the state column. You will see connections in the ESTABLISHED state, the same word from the handshake. You may also see states like TIME_WAIT, part of the connection teardown that mirrors the setup handshake.
Watch a three-way handshake happen live:
sudo tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' -c 10
With this running, open a website in your browser, and you will see the SYN, SYN-ACK, and ACK packets fly past in real time, the handshake we described, captured on your own connection. Few things make the concept as concrete as watching it occur.
See UDP traffic, including DNS:
sudo tcpdump -i any udp port 53 -c 5
Then trigger a DNS lookup, for example by visiting a new site, and watch the UDP DNS queries and responses appear, connectionless and quick, with no handshake preceding them. You are seeing the contrast from this post directly: TCP's careful setup versus UDP's fire-and-forget.
What You Now Understand
You began with a single question that every connection must answer, reliability or speed, and you now understand the two protocols that answer it in opposite ways.
You understand TCP in real depth. It is connection-oriented, opening with the three-way handshake of SYN, SYN-ACK, and ACK to synchronise both sides before any data flows. It numbers its segments, uses acknowledgements that name the next expected byte, and retransmits anything lost, detected either by duplicate acknowledgements or by a timeout. It reorders segments so the application sees a clean, ordered stream, and it uses flow control so a fast sender never overwhelms a slow receiver. All of this guarantees delivery, at the cost of overhead and latency.
You understand UDP just as clearly. It is connectionless, with no handshake, no acknowledgements, no retransmission, no ordering, and no flow control. That is not a flaw, it is a deliberate design for situations where speed matters more than completeness, and where a late packet is worse than a lost one, like live calls, video, gaming, and quick DNS lookups.
You can now reason about which protocol an application should use, just by asking whether it needs every byte or needs minimal delay. And you understand how this all connects to security: the SYN flood that weaponises the handshake, defended by SYN cookies, and the spoofing and amplification attacks that exploit UDP's connectionless trust, capable of multiplying an attacker's traffic thousands of times over. These attacks are not flaws in the protocols. They are the shadow side of the very features that make the protocols work, which is the lesson this series returns to again and again.
In the next post, we climb one layer higher, to where these transport protocols are actually put to use by the applications you interact with directly. We will look at HTTP and HTTPS, the protocols of the web itself, how a request for a web page actually works on top of the TCP connection you now understand, and what that crucial S in HTTPS is really doing to keep you safe. That is Post 7.
This is Post 6 of the Networking Foundations series. If the TCP and UDP distinction finally makes sense, and you can see the tradeoff behind it, share it with someone who has only ever memorised the two as a list of differences. New here? Start with Post 1, and Post 5 on DNS leads into this one. Subscribe to our newsletter to get each new post as it publishes.
Comments