SubnetLayerProtocols

When One Message Needs Many Packets

And why TCP loss underneath is invisible above

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
Every application on the internet needs the same things: get my data there, all of it, in order, even though the network loses packets. Imagine if each one had to solve that itself. Every web server, every mail client, every database driver reimplementing retransmission and ordering — and each getting it slightly wrong. So it is solved once, in TCP, underneath everything. HTTP does not contain a single line of recovery code. It writes bytes and reads bytes, and TCP quietly resends whatever goes missing. The cost is that HTTP also cannot see when that happens, or do anything about it.

✗ Common misunderstanding: One packet carries one HTTP request or response.

Why that's wrong: TCP is a byte stream with no message boundaries. It splits by size and coalesces by buffer state, neither of which knows anything about HTTP.

Correct model: A message is a RANGE in a byte stream. Reassemble the stream first, then find messages in it by their framing.

The packets prove it: The persistent-connection trace carries three complete requests in one packet; the large-response trace splits one response across several.

Watch these fields in the lab: tcp.sequenceNumber

  1. 1The server writes one response. TCP cuts it into segments — the cut falls wherever the size limit lands, usually mid-word.
  2. 2One segment is lost. Nobody is told: not the server, not the client, not either application.
  3. 3Later segments arrive. The client's TCP has them, but they sit after a gap, so it cannot pass them up.
  4. 4The client keeps acknowledging the last byte before the gap. The server's timer eventually fires (or duplicate acknowledgements give it away sooner).
  5. 5The server resends the missing segment.
  6. 6It arrives, the gap closes, and TCP delivers everything at once — the recovered segment and all the bytes that were waiting behind it.
  7. 7HTTP reads one complete, correct message. It has no way of knowing any of this happened.

Watch these fields in the lab: tcp.sequenceNumber · tcp.ackNumber

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why can HTTP not be told that a retransmission happened?

One segment of a ten-segment response is lost. How much of the response is delayed?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.