TCP and UDP: Reliable vs Fast

TCP and UDP: Reliable vs Fast

What you'll learn

• Walk the three-way handshake step by step, with real sequence and acknowledgment numbers
• Explain how sequence numbers, acknowledgments and retransmission turn a lossy network into reliable delivery
• Describe windowing — how TCP sends efficiently without overwhelming the receiver
• Trace the orderly FIN close, and choose TCP or UDP for a given application
• Place QUIC honestly in the 2026 landscape, and capture a real handshake and close in Wireshark

This lesson builds on Chapter 5 of Dr. Tahseen Al-Doori's Network Essentials, the chapter that introduces the TCP/IP suite's two transport personalities and the handshake mechanics you are about to dissect. Everything the book teaches here still holds — TCP's current specification (RFC 9293, published 2022) restates the same machinery — which makes this one of the most durable lessons in the course. The one genuinely new arrival, QUIC, gets its own section near the end.

Two personalities, one layer

Module 2 established what the transport layer does: it takes application data, wraps it into segments, and stamps them with port numbers so the far side can hand the payload to the right program. But how it delivers is a choice, and the TCP/IP suite offers two options with opposite temperaments.

TCP (Transmission Control Protocol) is connection-oriented and reliable. Before any data moves, both ends agree to open a conversation; every byte sent is tracked, acknowledged, and — if lost — sent again; and when the conversation ends, both sides formally say goodbye. All of that care costs time and overhead.

UDP (User Datagram Protocol) is connectionless and makes no promises. It stamps the data with ports, hands it to IP, and walks away. No setup, no acknowledgments, no retransmission, no goodbye. If a datagram vanishes en route, nobody at the transport layer notices or cares. What UDP buys with that indifference is speed and simplicity.

A classic analogy from Dr. Al-Doori's course puts the two on the road: TCP is the sturdy old diesel sedan — never the fastest thing out there, but it always gets where it is going; UDP is the race car — quicker and lighter, with no guarantee it finishes the lap. Neither is "better." They are tools for different jobs, and by the end of this lesson you will pick the right one on sight.

One practical note from the book worth keeping: as a network professional you usually do not choose the transport protocol — the application's developers did, long ago. Your job is to know which one an application uses, what behavior that implies, and how to recognize each on the wire.

The three-way handshake

TCP will not send a byte of data to a stranger. First it establishes a connection — a shared agreement between two endpoints that a conversation is open — using exactly three segments. This is the famous three-way handshake, and the phone-call analogy from Module 2 maps onto it perfectly: dial, answer, "hello — hello."

The segments carry no application data, just TCP headers with particular flags set — single-bit fields that mark a segment's purpose:

1. SYN (client → server). "I want to talk. Let's synchronize." The client picks a random starting sequence number — say 2,714,382,905 — that will number every byte it sends.
2. SYN-ACK (server → client). "Heard you. Let's talk — synchronizing my side too." The server acknowledges the client's number and picks its own independent starting sequence number.
3. ACK (client → server). "Heard you. We're on." The client acknowledges the server's number. The connection is open, and data can now flow in both directions.

Why random starting numbers rather than just starting at zero? Two reasons: segments from an old, dead connection between the same machines must not be mistaken for the new conversation, and an attacker who could guess the numbers could inject fake segments. Randomness protects against both.

Wireshark, mercifully, converts these giant numbers into relative ones — it shows the starting point as 0 so humans can follow along. In relative terms, a handshake reads:

• SYN — the client says Seq=0
• SYN-ACK — the server says Seq=0, Ack=1
• ACK — the client says Seq=1, Ack=1

That Ack=1 hides the single most useful convention in TCP: the acknowledgment number names the next byte the receiver expects, not the last byte it got. "Ack=1" means "I have everything up to byte 0; send me byte 1 next." Even a SYN, which carries no data, consumes one sequence number — which is why the count starts moving before any data does.

Keeping the promise: sequence, acknowledgment, retransmission

Once the connection is open, TCP earns its "reliable" title with three cooperating mechanisms — the header fields the book walks through, now in action:

Sequence numbers label every byte's position in the stream. If the network delivers segments out of order — and across multiple routes it can — the receiver uses the numbers to reassemble the data exactly as sent. The application above never knows the shuffle happened.

Acknowledgments flow constantly back to the sender: "expecting byte 5,206 next" tells the sender everything before that point arrived safely. The sender keeps a copy of everything unacknowledged.

Retransmission closes the loop. If an acknowledgment fails to arrive within an expected time — or the receiver keeps repeating the same "expecting byte X" while later data arrives around a gap — the sender concludes a segment died and sends its copy again. This is the machinery behind the book's summary claim: TCP either delivers, or you find out there was a problem. A file that arrives, arrives whole.

Which is exactly why TCP suits some traffic and not others. A downloaded program with one wrong byte may not run at all — every byte matters, so TCP's guarantees are worth the wait. A live voice call is the opposite: a syllable that arrives two seconds late, retransmitted, is worse than useless — the conversation has moved on. Guarantee-hungry data wants TCP; deadline-hungry data wants UDP.

Windowing: efficiency without flooding

Imagine TCP acknowledged one segment at a time: send, wait, ack, send, wait, ack. On a connection to another continent, most of the time would be spent waiting. The cure is the window.

In every segment's header, the receiver advertises a window size: "I have room for this many bytes right now." The sender may keep up to that much data in flight — sent but not yet acknowledged — before it must pause. But the advertised window is only one of two limits: TCP also keeps its own congestion window, a self-imposed cap that starts small and grows as acknowledgments prove the path can carry more. What actually governs is whichever is smaller — the receiver's capacity, or the network's. That is why a fresh connection ramps up instead of instantly filling a large advertised window. As acknowledgments arrive, the window slides forward and the sender releases more. One acknowledgment can cover many segments at once, so the pipeline stays full and the per-segment wait disappears.

The window also doubles as flow control — protection for the receiver, not the network. A busy receiver whose buffer is filling advertises a smaller window; the sender slows. A window of zero means "stop entirely; I'll tell you when I can breathe." The two ends negotiate pace continuously, automatically, in every header. (Modern TCP also stretches the window far beyond its original 16-bit limit — a header option called window scaling, agreed during the handshake, multiplies the advertised value so fast long-distance links can stay full. The Win= value Wireshark prints in the Info column already has that multiplier applied — it is the calculated window, not the raw 16-bit header field, which appears separately as "Window size value" in the details pane. That is why an established connection can show a Win= far above 65535, and why the SYN's own window looks small: SYN windows are never scaled.)

Hanging up: the FIN close

The phone call ends with mutual goodbyes, and so does TCP. Each direction of the conversation is closed independently with a FIN ("finished") flag:

1. The side that is done sends a segment with FIN set: "I have nothing more to send."
2. The other side acknowledges it — and may keep sending its own data; the connection is now half-closed.
3. When it too is done, it sends its own FIN.
4. The first side acknowledges, and the connection is fully closed.

Four steps, often compressed into three on the wire when a FIN and an ACK share a segment (you will likely capture exactly that in the lab: FIN, FIN-ACK, ACK). There is also a rude alternative: a segment with the RST (reset) flag slams the connection shut immediately — TCP's version of hanging up mid-sentence. You will see RSTs in real captures when a program exits abruptly or a server refuses a connection; an RST close is normal life, not necessarily an error.

UDP: the art of not promising

Everything above — handshake, sequence numbers, acknowledgments, windows, FIN — UDP simply does not have. Its entire header is four small fields: source port, destination port, length, checksum. Done. Where a TCP header carries at least 20 bytes of machinery, UDP carries 8 bytes of address label.

That minimalism is a feature, and three families of traffic prize it:

• Tiny request-reply exchanges. A DNS lookup (next-but-one lesson) is one small question and one small answer. Opening a TCP connection would cost three segments before the question could even be asked. UDP asks immediately; if no answer comes, the application just asks again — reliability handled above the transport layer, only when needed.
• Live streams. Voice calls, video conferences, game state updates. Late data is worthless, so retransmission is pointless; the stream tolerates small losses (a missing frame, a click in the audio) and simply keeps going.
• Broadcasts and discovery. A machine with no address yet cannot complete a handshake with a server it hasn't found. DHCP — two lessons from now — runs on UDP for exactly this reason.

The decision rule to carry forward: must every byte arrive, eventually? TCP. Must most bytes arrive, on time? UDP.

From the textbook to 2026: QUIC

The book's TCP-versus-UDP world was complete in 2007. Since 2021 there is an officially standardized third option, and it is the one genuine "what's new" of this lesson: QUIC (RFC 9000).

QUIC's trick sounds like a contradiction: it delivers TCP-style reliability — sequenced, acknowledged, retransmitted streams — on top of UDP. Why bother? Three motivations, each a real TCP pain point:

• Faster setup. A TCP handshake plus the TLS encryption setup (Module 7 meets TLS properly) costs multiple round trips before the first useful byte. QUIC merges transport and encryption setup into one round trip — sometimes zero for a returning visitor.
• No head-of-line blocking. In TCP, one lost segment holds up every byte behind it, even bytes belonging to unrelated resources on the same connection. QUIC multiplexes many independent streams; a loss stalls only its own stream.
• Encryption by default. QUIC encrypts its payload and protects almost all of the transport machinery — packet numbers, acknowledgments and flow-control state, every one of which TCP exposes in a cleartext header. A thin outer shell stays visible on purpose, so routers and load balancers can still steer packets: the version and the connection IDs. Middleboxes can forward QUIC; they can no longer meddle with it.

HTTP/3, the newest version of the web's protocol, runs exclusively over QUIC — so your browser very likely speaks it every day with the largest platforms (Google, Meta, Cloudflare all run it at scale).

Now the honesty the course owes you, because this is a live debate rather than a settled fact. QUIC was widely announced as "the future of the web," but the measured present is more modest: as of the 2025 Cloudflare Radar year in review, HTTP/3 accounted for roughly 21% of web requests — about one in five — a share that has stayed roughly flat since 2024, while HTTP/2 over classic TCP still carried about half. The accurate 2026 statement is that QUIC is a substantial, plateaued minority transport: mandatory to know, dominant nowhere outside the big platforms, and no obituary for TCP, which remains the backbone of file transfer, email, remote administration, databases and most of the web. If the balance shifts, it will be measured, not proclaimed — you now know where to look.

Watch: TCP vs UDP Comparison

Why this video earns its place. PowerCert Animated Videos is one of the most widely recommended beginner networking channels — its explainers turn up in university course video lists precisely because the animation style makes abstract mechanics visible. This comparison animates the two temperaments you just studied: connection setup, acknowledgments and retransmission on the TCP side, fire-and-forget delivery on the UDP side. It is short, calm and squarely at this lesson's level.

As you watch, notice:

• The connection being established before any data moves — the three-way handshake you can now narrate with sequence and acknowledgment numbers.
• Acknowledgments flowing back and a lost segment being sent again — the keep-the-promise machinery from our reliability section.
• UDP's deliveries leaving with no setup and no confirmation — and why the video pairs UDP with live streams, exactly matching our decision rule.
• The overhead contrast: every TCP guarantee is paid for in extra segments and header bytes — the diesel-versus-race-car trade in animated form.
• What the video does not cover: it dates from 2016 and therefore predates QUIC entirely. The reliable-equals-TCP, fast-equals-UDP split it presents was the complete truth then; our QUIC section above is the 2026 correction — reliability now also ships over UDP, in a substantial minority of web traffic.

The video reinforces visually what you just learned — the lesson is complete without it.

Lab: Capture a Real Handshake and Goodbye

Module 2's lab taught you to capture and read envelopes; this lab captures a complete TCP life cycle — birth (SYN, SYN-ACK, ACK), life (data with sliding windows), death (FIN exchange) — from your own machine, and has you annotate each phase.

Objective. Capture one full TCP connection, isolate it from the noise, and identify the three handshake segments, the acknowledgment rhythm, and the closing exchange.

Setup. Wireshark installed and working (Module 2's lab covers installation and interface choice). Any browser. A quiet machine helps: close what you can.

Steps.

1. Open Wireshark and start a capture on your active interface (the one with the moving graph).

2. In a browser, visit one website you have not opened today — a news site works well. Let the page finish loading.

3. Close the browser entirely (not just the tab — closing the program encourages tidy FIN goodbyes).

4. Wait about ten seconds, then stop the capture with the red square.

5. Find the connection births. Type this into the display filter bar (the wide box above the packet list) and press Enter — it shows only segments with SYN set and ACK clear, i.e., first-contact segments:

   codeCopy

   tcp.flags.syn == 1 and tcp.flags.ack == 0
   

   Each line is your machine introducing itself to some server. Expect several — modern pages open many connections.

6. Pick any one line. Right-click it → Follow → TCP Stream. A window of raw conversation bytes opens: close it. The important side effect remains — Wireshark has set the display filter to show only this one connection, in order.

7. Read the first three lines. They should follow this pattern (your addresses, ports and window values will differ):

   codeCopy

   No.  Source          Destination     Protocol  Info
   1    192.168.10.57   93.184.216.34   TCP   51742 → 443 [SYN] Seq=0 Win=64240 Len=0
   2    93.184.216.34   192.168.10.57   TCP   443 → 51742 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0
   3    192.168.10.57   93.184.216.34   TCP   51742 → 443 [ACK] Seq=1 Ack=1 Win=131840 Len=0
   

   Annotate for yourself: line 1 the introduction (client's relative Seq=0), line 2 the counter-introduction (server's own Seq=0, acknowledging with Ack=1 — "expecting your byte 1"), line 3 the confirmation. Three segments, Len=0 throughout — pure ceremony, no data yet.

8. Scroll through the middle of the conversation: segments with Len= greater than zero are actual data (mostly labeled TLS — the encrypted web at work). Watch the Ack= values in the return direction climb: that is the receiver's "expecting next" counter advancing, and the Win= values beside them are the live window advertisements from our flow-control section.

9. Scroll to the end and find the goodbye. Look for the FIN flags — typically a compressed pattern like:

   codeCopy

   40   192.168.10.57   93.184.216.34   TCP   51742 → 443 [FIN, ACK] Seq=871 Ack=5205
   41   93.184.216.34   192.168.10.57   TCP   443 → 51742 [FIN, ACK] Seq=5205 Ack=872
   42   192.168.10.57   93.184.216.34   TCP   51742 → 443 [ACK] Seq=872 Ack=5206
   

   Each side declares "nothing more to send," each declaration is acknowledged — notice every FIN, like every SYN, consumes one sequence number (Ack jumps from 5205 to 5206 with no data in between).

10. Save the capture as m5-handshake for your notes.

Expected result. One isolated conversation reading top to bottom: three-segment handshake, a data phase with climbing acknowledgments and fluctuating windows, and a FIN exchange at the end.

Verify. You can point at: the segment where the server first proves it heard the client (the SYN-ACK's Ack=1); the field that would reveal a receiver running out of buffer (Win shrinking); and the segment after which the client had nothing more to say (its FIN).

Questions.

1. In your handshake, the SYN and SYN-ACK both show Seq=0. Are the two zeros the same number underneath? What is Wireshark doing for you?
2. Mid-conversation you see Ack=4381 repeated in three successive segments from your machine while data keeps arriving. What is your machine telling the server, and what should the server eventually do?
3. Your capture's final segments show RST instead of a FIN exchange. Has something gone wrong?
4. Why does the FIN-ACK in line 41 above answer with Ack=872 when line 40's sequence number was 871 and carried no data?

(Answers: 1 — no; each side chose its own random starting number, and Wireshark rebases both to 0 (relative numbering) so humans can follow. 2 — a repeated acknowledgment says "still expecting byte 4381" — a gap: some segment died en route while later ones arrived; the server should retransmit the missing segment. 3 — not necessarily; RST is the abrupt close, common when a program exits with connections open. It is rude, not broken. 4 — a FIN consumes one sequence number even though it carries no data, exactly as the SYN did; acknowledging the FIN means expecting the byte after it.)

If it goes wrong.

• The filter shows nothing. Check for typos — the filter bar turns green when the expression is valid. If valid but empty, your browser may have reused existing connections: repeat with a site you truly haven't visited, or restart the browser first.
• No FIN at the end of your chosen stream. Some connections are held open for reuse and die silently later, and some end in RST. Follow a different SYN from step 5 — with several connections captured, at least one usually closes politely.
• The Info column shows QUIC or UDP instead of TCP. You have live evidence of this lesson's modernization section — that site speaks HTTP/3. Enjoy the sighting, then pick a TCP stream for the exercise.
• Everything is labeled TLS and unreadable. Expected — the web is encrypted. This lab studies the TCP header machinery around the encrypted payload, which is exactly what remains visible.

Reset/cleanup. Stop the capture, close Wireshark. As in Module 2: a capture is a private document — keep m5-handshake for your notes and delete it when the module ends.

Check yourself

1. A colleague's capture of a connection's first three segments shows flags in this order: SYN · SYN-ACK · ACK. In the third segment, what are the relative Seq and Ack values, and why has Seq already moved to 1 when no data was sent?
2. For each application, choose TCP or UDP and give the one-sentence reason: (a) downloading a software update; (b) a live video call; (c) a DNS lookup; (d) sending an email.
3. A file-transfer session across the ocean crawls despite a fast link, and the capture shows the sender pausing constantly with Win=0 arriving from the receiver. Which mechanism are you watching, which side is the bottleneck, and is the network at fault?
4. A segment arrives at a server with the ACK flag set and an acknowledgment number of 9,001. In one sentence, what exactly has the client told the server?
5. True or false, with a correction if false: "QUIC replaced TCP as the web's dominant transport; as of the 2025 measurements most web requests use HTTP/3."
6. Your monitoring shows a connection that ended with FIN, FIN-ACK, ACK, and another that ended with a single RST. Describe what each ending tells you about how the applications behaved.

Answers

1. Seq=1, Ack=1. The SYN itself consumed sequence number 0 — connection-control flags occupy one position in the byte count — so the client's next segment starts at 1; Ack=1 acknowledges the server's SYN the same way.
2. (a) TCP — one corrupted byte can break an executable, so every byte must arrive. (b) UDP — late data is worthless in a live stream; losses are tolerable, delays are not. (c) UDP — one small question, one small answer; a handshake would cost more than the query (the application retries if needed). (d) TCP — mail must arrive complete and is in no hurry.
3. Flow control via the advertised window. The receiver is the bottleneck — it keeps advertising zero buffer space, and the sender obediently pauses. The network is innocent; look at the receiving machine (slow disk, overloaded application).
4. "Every byte up to and including 9,000 has arrived; send byte 9,001 next" — acknowledgments name the next expected byte, not the last received.
5. False on both counts. As of the 2025 Cloudflare Radar year in review, HTTP/3 over QUIC carried roughly a fifth of web requests — a substantial minority, roughly flat since 2024 — while HTTP/2 over TCP still carried about half. QUIC is mandatory knowledge, not the dominant transport.
6. The FIN sequence is an orderly goodbye: each side declared it was finished and confirmed the other's declaration — applications closed cleanly. The lone RST is an abrupt termination: one side slammed the connection shut without ceremony — a program exited, refused, or aborted; common in practice and worth correlating with application logs, but not automatically a fault.

Key terms

• TCP (Transmission Control Protocol) — the connection-oriented, reliable transport: handshake, sequencing, acknowledgment, retransmission, windowed flow, orderly close (current spec: RFC 9293).
• UDP (User Datagram Protocol) — the connectionless, best-effort transport: ports and a checksum, nothing more.
• Three-way handshake — SYN, SYN-ACK, ACK; the three-segment opening ceremony of every TCP connection.
• Flag — a single-bit header field marking a segment's purpose: SYN (synchronize), ACK (acknowledge), FIN (finish), RST (reset).
• Sequence number — the position label on every byte of the stream; starts at a random value per side (shown relative by Wireshark).
• Acknowledgment number — the next byte the receiver expects; everything before it is confirmed delivered.
• Retransmission — resending unacknowledged data after a timeout or repeated duplicate acknowledgments.
• Window (flow control) — the receiver's advertised buffer room; caps how much the sender may have in flight; slides forward as data is acknowledged.
• FIN close — the two-sided goodbye; each direction closes independently, each FIN consuming one sequence number.
• RST — the abrupt, one-segment connection teardown.
• QUIC — the 2021-standardized transport (RFC 9000) providing reliable, encrypted, multiplexed streams over UDP; carries HTTP/3.
• HTTP/3 — the web protocol version that runs exclusively over QUIC; about one-fifth of web requests as of the 2025 Radar year in review.

Summary

• The transport layer offers two temperaments: TCP promises complete, ordered delivery and pays for it in setup and overhead; UDP promises nothing and is instant — the book's diesel-versus-race-car pairing, still exact.
• TCP opens with the three-way handshake (SYN, SYN-ACK, ACK), numbers every byte from a random start, acknowledges by naming the next expected byte, and retransmits what goes unacknowledged.
• The advertised window keeps the pipeline full without flooding the receiver — flow control negotiated silently in every header.
• Connections end politely with a FIN exchange (each direction closed independently) or abruptly with RST — both are everyday sights in captures.
• Choose transports by the data's nature: every-byte-matters traffic takes TCP; on-time-or-worthless traffic takes UDP.
• QUIC layers TCP-like reliability plus encryption over UDP and carries HTTP/3 — as of the 2025 Cloudflare Radar year in review, about 21% of web requests: a substantial, plateaued minority, not TCP's replacement.
• You captured a complete TCP life cycle — handshake, windowed data, goodbye — and can now annotate each phase from the header fields alone.

Next lesson

The handshake you captured was addressed to port 443 — and you never questioned how your machine knew that number, or how the reply found its way back to the right browser tab. The next lesson is entirely about those numbers: the port system, the sockets it builds, and the core set of port numbers every network professional knows by heart.

Sources and further study

• Al-Doori, T., Network Essentials, Chapter 5 — TCP and UDP, the handshake, header fields and the transport comparison this lesson extends.
• RFC 9293, "Transmission Control Protocol (TCP)" — https://www.rfc-editor.org/info/rfc9293/ — the current consolidated TCP specification.
• RFC 768, "User Datagram Protocol" — https://datatracker.ietf.org/doc/html/rfc768 — all of UDP, famously brief.
• RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport" — https://www.rfc-editor.org/info/rfc9000/ — the QUIC standard.
• Cloudflare Radar, "2025 Year in Review" — https://radar.cloudflare.com/year-in-review/2025 — the live measurement behind this lesson's HTTP/3 adoption figures; check the current year's edition.
• Download: OSI and TCP/IP Model Reference (the transport layer's place in both maps — at your elbow for this whole module).