Packets, how a 10 MB download becomes a million tiny pieces and back

Field note. Every chunk send, chat message, and block break in your game crosses the wire as packets. Understanding the trip explains why distant players see lag spikes even when your CPU isn't busy.

Data on the internet doesn't move as a single stream. It moves as a series of small, discrete chunks called packets. Every webpage you load, every video you stream, every game position update: all of it is millions of small packets, sent and received and reassembled.

Understanding packets unlocks how the internet works at the lower levels and why it behaves the way it does.

Why not stream the whole thing?

If you have a 10 MB file to send, why not just send it as one big chunk?

Several reasons, all important:

Sharing the wire. If you sent your 10 MB file as a single uninterrupted transmission, nobody else could use the wire during that time. By breaking it into small packets, your transmission interleaves with everyone else's. The wire is "fairly" shared.

Error recovery. If a 10 MB chunk gets corrupted, you have to resend all 10 MB. If 1500-byte packets get corrupted individually, you only resend the bad ones.

Routing flexibility. Each packet can take a different path. If one path becomes congested, later packets can take a different route. Streams couldn't do this.

Buffering. Routers can hold individual packets briefly while waiting for the right moment to forward them. Streams would require infinite buffer if the destination slowed down.

So data gets chopped up. The chopping is done by the protocols (IP, TCP, UDP) at various layers.

What a packet actually contains

An IP packet has two parts:

Header. A structured set of fields, about 20 bytes for IPv4.

• Version (4 for IPv4, 6 for IPv6)
• Length (how big this packet is)
• Time-to-live (a counter that prevents infinite loops)
• Protocol (TCP, UDP, ICMP, etc.)
• Source IP
• Destination IP
• Checksum
• (some other fields we'll skip)

Payload. The actual data being carried, up to ~1500 bytes for typical networks.

A typical packet looks like a small structured blob:

[ IP HEADER ][ TCP HEADER ][ HTTP REQUEST: "GET / HTTP/1.1..." ]

The IP header tells routers where to send it. The TCP header tells the destination computer which connection and where in the byte stream this fits. The HTTP request is the actual content (in this case, an HTTP request).

Each layer's header is added on top of the previous payload. This is encapsulation.

The MTU

How big can a packet be? It depends on the network.

The MTU (Maximum Transmission Unit) is the largest packet a network can carry. For typical ethernet, MTU is 1500 bytes. For some specialized networks (data center 9000-byte "jumbo frames," tunneled connections with smaller MTUs), it's different.

If a packet is larger than the MTU of any link on its journey, something has to give:

• Fragmentation. The packet is split into smaller pieces, each below the MTU. They get reassembled at the destination. This works but is expensive and increasingly avoided.
• Path MTU Discovery. The sender probes the path to find the smallest MTU along the way, then sends packets at or below that size. This is the modern approach.

When path MTU discovery fails (often due to firewalls eating ICMP messages), connections can mysteriously break: small packets work fine, large ones get dropped silently. This is one of the most annoying obscure networking issues. We have a dedicated MTU article in Series B.

How a 10 MB download becomes packets

When you download a 10 MB file over TCP:

1. The sender chops the 10 MB into TCP segments. Each segment fits in a packet, so each is ~1460 bytes of payload (1500 byte packet, 20 bytes IP header, 20 bytes TCP header).
2. That's roughly 7,000 packets.
3. Each packet has a TCP sequence number indicating its byte position in the original 10 MB stream.
4. Packets travel the network independently. Different packets may take different paths.
5. The receiver receives packets, possibly out of order. It uses the sequence numbers to reassemble.
6. The receiver acknowledges each successfully-received chunk. The sender uses these acks to track what's been received.
7. If some packets are lost (no ack received within a timeout), the sender retransmits.

By the time the 10 MB has been fully received and acknowledged, millions of small interactions have occurred. From the application's perspective, "the file downloaded." From the wire's perspective, thousands of separate packets crossed the network.

Packet loss is normal

It's a common misconception that packet loss is rare or pathological. It isn't. Some packet loss is normal and expected on any real network. The internet's design assumes loss; that's why TCP exists.

Typical packet loss rates:

• High-quality wired connection on a good network: <0.01%.
• Decent wired connection: 0.01% to 0.1%.
• Wi-Fi indoors with weak signal: 0.5% to 5%.
• Congested cellular network: can be 2% to 10%.

TCP handles single-digit-percent loss by retransmitting and slowing down. The connection still completes, just slower.

For UDP-based applications like games, loss means the data is just gone. The application has to decide what to do (often: ignore it; the next packet has fresher information anyway).

Persistent high loss (>5%) is a problem worth diagnosing. It often indicates a bad cable, interference, or a misconfigured router.

Packet inspection

Network engineers and security people sometimes look at packets directly. Tools:

• tcpdump (command line, all platforms): captures and displays packets.
• Wireshark (GUI, all platforms): captures and displays packets with a friendly interface.

A captured packet might look like:

14:23:01.234567 IP 192.168.1.42.51234 > 198.51.100.10.443:
  Flags [S], seq 1234567890, win 64240, length 0

Read: at 14:23:01 (and a microsecond), an IP packet from 192.168.1.42 port 51234 went to 198.51.100.10 port 443, with the SYN flag set (start of a TCP connection), with sequence number 1234567890.

This is how engineers debug network issues. By looking at the actual packets, you can see precisely what happened, in what order, with what timing.

Important: capturing packets requires admin privileges (it's not something a random web app can do). The OS isolates packet capture from normal applications for security reasons.

Encryption and packets

When you load an HTTPS page, the contents of each packet's TCP payload are encrypted. The IP and TCP headers remain visible (routers need to read them to route), but the actual data is gibberish to anyone watching.

Someone snooping the wire can see:

• Source and destination IPs.
• Source and destination ports.
• Packet sizes and timing.
• That you're connecting to some service on some address.

They cannot see:

• What you're sending.
• What you're receiving.

This is the privacy guarantee of HTTPS. It's important and limited. Traffic patterns are still observable; only contents are private.

For game traffic: most games encrypt at least the login flow (HTTPS or TLS). Real-time game traffic varies. Some games encrypt everything; some only encrypt sensitive parts; some don't encrypt much because the data is just position updates and the latency cost of encryption wasn't worth it. This varies by game and version.

Packet flow at scale

A busy server handles enormous packet rates:

• A small website: thousands of packets per second.
• A medium streaming service: millions.
• A major CDN: hundreds of billions per day.

Hardware routers are specialized for packet handling. They use ASICs (application-specific integrated circuits) that can route at line rate, no software involved per-packet. This is why your home router (~1 Gbps) is so much cheaper than a data center router (~400 Gbps or more): different scale of work.

Common packet weirdness

A few oddities worth knowing about:

TTL. Each IP packet has a Time-To-Live counter (initial value 64 or 128 in most OSes). Each router decrements it by 1. If it hits zero, the router drops the packet and sends back a message. This prevents packets from looping forever if routing tables have mistakes. The traceroute tool exploits this: it sends packets with increasing TTLs to discover each hop.

Fragmentation. As mentioned, packets too big for a link get split. Modern hosts try to avoid this. When fragmentation happens, all the fragments must arrive for the original packet to be reassembled. If even one fragment is lost, the whole thing is lost.

Out-of-order delivery. Different packets take different paths. Faster paths can deliver later packets before slower paths deliver earlier ones. TCP handles this; UDP applications have to.

ICMP. Internet Control Message Protocol. The protocol used for ping, traceroute, and various error messages (destination unreachable, fragmentation needed, TTL exceeded). Not technically a transport protocol but it's important. Some lazy firewalls block ICMP, which breaks helpful diagnostics and sometimes causes path MTU issues.

A summary mental model

When you do anything on the internet, data is being chopped into packets, each addressed and timestamped, sent across multiple hops, possibly losing some along the way, and reassembled at the destination.

Higher protocols (TCP, UDP, HTTP, application protocols) build their abstractions on top of this packet substrate. The substrate is genuinely doing the work; the abstractions just make it convenient.

The next time something feels weird about a network connection, the explanation is almost always at the packet level: packets are getting lost, fragmented, delayed, or routed strangely. Tools like ping, traceroute, and mtr expose that level. Even casual familiarity helps you diagnose problems.

Coming up

Next: routers. We've mentioned them throughout. Now we'll cover what they actually do, how they decide where to forward packets, and why this distributed system manages to work despite no central authority.