TCP vs UDP and the Three-Way Handshake

Every message you send makes a tradeoff your gut already understands. A registered letter gets a tracking number, a signature on delivery, and a replacement if it vanishes — slow, but certain. A postcard gets tossed in the mail with no tracking at all — fast and cheap, but if a sorting machine eats it, nobody tells you. Networks face the same choice thousands of times a second: some messages must arrive perfectly and in order, and some — a live voice call, a game — would rather lose a piece than wait for a resend. The trick isn't picking the "better" one. It's knowing that before two computers exchange anything important, they first shake hands and agree on the rules — and that handshake leaves footprints you can read.

Here's the puzzle.

Scenario. A junior admin is troubleshooting a slow file download from the office file server. The download stalled for a third of a second, then recovered on its own. She captured 8 packets on the client and asks you three things: which piece went missing, how can you tell it was lost rather than merely delayed, and should this app have used the postcard instead of the registered letter?

Given artifacts. The lab link (hover any device for details):

Capture: Workstation → FileServer download (8 packets)
  1  0.000  10.0.0.15 → 10.0.0.5  TCP  [SYN] Seq=0
  2  0.002  10.0.0.5 → 10.0.0.15  TCP  [SYN, ACK] Seq=0 Ack=1
  3  0.003  10.0.0.15 → 10.0.0.5  TCP  [ACK] Seq=1 Ack=1
  4  0.010  10.0.0.15 → 10.0.0.5  TCP  Seq=1 Len=1000        (bytes 1–1000)
  5  0.020  10.0.0.15 → 10.0.0.5  TCP  Seq=1001 Len=1000      (bytes 1001–2000)
  6  0.022  10.0.0.15 → 10.0.0.5  TCP  Seq=2001 Len=1000      (bytes 2001–3000)
  7  0.023  10.0.0.5 → 10.0.0.15  TCP  [ACK] Ack=1001         (duplicate ACK)
  8  0.320  10.0.0.15 → 10.0.0.5  TCP  Seq=1001 Len=1000      (retransmission)

Your task: Deliver three things: (1) the packet number of the lost segment, (2) which packet proves it was lost (not just delayed), and (3) one sentence: should this app have used UDP instead — and why?

Workspace: Analyze-and-answer — type your three answers below, then check the commitment box to reveal the worked answer.

☐ I've attempted this challenge and thought it through. (Checking reveals the worked answer in S7 — honor system: the page hides it until you commit.)

The handshake: agreeing before speaking

Before any important exchange, the two computers perform the three-way handshake (a three-packet greeting in which both sides agree on the rules before sending data). It works like this:

1. The client sends SYN (short for synchronize — "I want to talk, and I'll number my bytes starting from 0").
2. The server replies SYN-ACK — the ACK (short for acknowledgment — "message received") confirms the client's SYN, and the server's own SYN says "I'll number my bytes starting from 0 too."
3. The client sends a final ACK — "deal." The conversation is now open.

Why bother? Because everything after this depends on numbering. Each side announces its starting sequence number (a running counter stamped on every piece, saying "these are bytes N through M"), and each reply carries an acknowledgment number (saying "I've received everything up to this point — send me the next byte"). The handshake synchronizes both counters so that later, a missing piece is instantly visible as a gap in the numbers.

Why this matters for the challenge: packets 1–3 of the capture are this exact ritual — and the numbers agreed there are what let you spot the missing piece later.

TCP: the registered letter

TCP (the Transmission Control Protocol — the registered letter of networking: every piece tracked, every delivery confirmed) gives you three guarantees: every byte arrives, arrives exactly once, and arrives in order. The machinery behind the guarantees:

• Numbering: every byte is counted (the sequence numbers from the handshake), so the receiver can spot gaps and duplicates.
• Acknowledgments: the receiver constantly reports the next byte it still needs. Silence means "something's missing."
• Retransmission (re-sending a piece the receiver never confirmed): if a piece vanishes, the sender simply sends those exact bytes again — same sequence numbers, second attempt.

The price: memory and patience. Both sides must remember the conversation — what's been sent, what's been confirmed — and a lost piece pauses everything behind it until the resend arrives. That remembered state is why TCP is called connection-oriented: the "connection" is the shared memory of the conversation.

Why this matters for the challenge: the stall the admin saw was this machinery working — a lost piece, a pause, a resend. The numbers tell you exactly which piece.

UDP: the postcard

UDP (the User Datagram Protocol — the postcard: fast, cheap, no tracking) makes the opposite trade. Each message is a datagram (one standalone message, independent of all others): the sender fires it off and moves on. No handshake, no numbering, no acknowledgments, no resends. If it arrives, great; if not, nobody is told.

What you lose: reliability, ordering, and any notion of a conversation — each datagram stands alone, which is why UDP is called stateless (no memory of past messages), versus TCP's stateful (both sides remember). What you gain: speed and simplicity. No three-packet greeting, no waiting for confirmations, no head-of-line blocking behind a lost piece.

Why this matters for the challenge: part 3 asks whether the postcard would have served this download better — you'll judge that trade with this section fresh in mind.

How the receiver keeps score

The scoreboard is just two numbers, and reading them is the single most useful capture skill in this lesson:

• Seq on a data packet = "these are bytes N through N+length."
• Ack on a reply = "I've got everything before byte N — send me byte N next."

Walk a healthy exchange: sender transmits bytes 1–1000 (Seq=1, Len=1000); receiver replies Ack=1001 ("got them, need 1001 next"). Sender transmits bytes 1001–2000; receiver replies Ack=2001. Now the failure mode: bytes 1001–2000 vanish, but bytes 2001–3000 arrive. The receiver can't acknowledge 3001 — it's still missing 1001 — so it repeats Ack=1001. That repeated number is a duplicate ACK (an acknowledgment restating a number it already sent, meaning "I'm still waiting on the same bytes"). One duplicate ACK says "a piece is missing"; the sender's response is a retransmission of exactly those bytes — recognizable because the Seq numbers match the original.

Why this matters for the challenge: this is the entire part-2 argument — the duplicate ACK is the proof, and now you know what it's proving.

Ports: which program gets the message

Addresses get data to the right machine; ports (numbers identifying which program on that machine should receive the data — the apartment numbers from Lesson 1.2) get it to the right program. A few you'll see constantly:

Notice the pattern: anything where a missing byte corrupts the result (web pages, logins, email) uses TCP; the name lookup — one tiny question, one tiny answer, asked millions of times a second — uses UDP, because re-asking is cheaper than handshaking.

Why this matters for the challenge: the file server's port and TCP go together for a reason — you'll state that reason in your one sentence.

Choosing: web, voice, video, DNS

The decision rule, plainly: if a gap in the data ruins the result, use TCP; if waiting for a resend ruins the result, use UDP.

• Web pages, file downloads, email: every byte matters and order matters — TCP.
• Live voice and video calls: a 200-millisecond pause for a resend is worse than a tiny glitch — UDP, and the app hides the gaps.
• Name lookups (DNS): one question, one answer; if it's lost, just ask again — UDP.
• Online games: positions update 60 times a second; stale resends are useless — UDP.

Neither is "better." The registered letter and the postcard are different tools, and the mark of an engineer is reaching for the right one without hesitation.

Why this matters for the challenge: your part-3 sentence is just this rule applied to a file download.

• The three-way handshake (SYN → SYN-ACK → ACK) lets both sides agree on starting byte numbers before any data moves.
• Every ACK number names the next byte the receiver still needs — a repeated ACK means a piece went missing, not that data is flowing.
• A retransmission is recognizable by identical sequence numbers: the same bytes, sent twice.
• Choose TCP when every byte must arrive in order (files, web pages); choose UDP when waiting would hurt more than losing a piece (live voice, games, name lookups).
• Ports decide which program receives the data; the handshake decides the rules — addresses get it to the machine, ports and connections get it to the program.

Next: DNS: The Internet's Phone Book — You can now read the handshake that starts every web page load; next you'll meet the phone book that turns the name you typed into the address that handshake needs.