Packets: data travels in pieces

Unit 2 covered what the value 93.184.215.14 is.

An IPv4 address identifying the server machine. Four numbers from 0 to 255 separated by dots is an IPv4 address, as lesson 2-1 established.

Now that the browser has it, this unit answers the next question: how does data actually get to that address, reliably?

Nothing is sent whole

Networks never send a file, a page, or even a long message in one piece. Everything is chopped into packets: small chunks of data, typically around 1,500 bytes each, that travel independently. A 1 MB photo becomes roughly 700 packets.

Each packet carries a header, a small block of bookkeeping in front of the data:

• the source IP address (who sent it)
• the destination IP address (where it is going)
• a sequence number (which piece of the whole this is)

Routers between you and the server read only the destination and pass the packet along, hop by hop. Different packets from the same message can take different routes, arrive out of order, or get lost entirely. That sounds like chaos, and at this layer it is. The next lesson shows how TCP builds reliability on top of it.

Packet thinking pays off in real diagnostics: a "slow" connection is very often a lossy one, where a few percent of packets vanish and everything stalls while they are resent. Tools you will meet later, like ping with its "0.0% packet loss" line, are measuring exactly this.

Chopping a message into packets

This plays the sender's role, splitting a message into fixed-size chunks and numbering them.

message="the quick brown fox jumps over the lazy dog"

i=1
echo "$message" | fold -w 12 | while read -r chunk; do
  echo "packet $i: [$chunk]"
  i=$((i + 1))
done

Output

packet 1: [the quick br]
packet 2: [own fox jump]
packet 3: [s over the l]
packet 4: [azy dog]

fold -w 12 splits the text into 12-character lines, and the loop numbers each chunk the way a sequence number would.

Notice that the split ignores word boundaries entirely. br and own land in different packets, which is exactly how real fragmentation behaves: the network chops at a byte count and has no idea what the bytes mean.

The last packet is short, at 7 characters instead of 12. Only the final chunk of any message is allowed to be undersized, and a receiver uses that to recognize the end of the data.

Reassembling packets that arrived out of order

Now the receiver's role: sort by sequence number, then join.

packets="2:arrives 5:order 1:data 3:out 4:of"

words=$(for p in $packets; do echo "$p"; done | sort -n | cut -d: -f2)

echo $words

Output

data arrives out of order

Reading the pipeline

• for p in $packets; do echo "$p"; done puts each packet on its own line, because sort works on lines and the packets started as one space-separated string.
• sort -n sorts numerically and cut -d: -f2 keeps the part after the colon, so the ordering uses the sequence number and the output uses only the payload.
• echo $words without quotes joins the sorted words with single spaces. That is exactly what TCP's reassembly does with sequence numbers, and it is why the arrival order of packets does not matter to the application.
• Sorting numerically matters. With plain sort, a stream long enough to reach packet 10 would place it between 1 and 2, which is a real bug in this exact shape of script.