Why not just send the whole thing at once?
In the last guide we saw that the Internet is a network of networks, with hosts at the edge and switching gear in the core. Now picture sending a 10-megabyte photo from your laptop to a friend across the world. The obvious plan is to open a clean wire all the way there and pour the whole file down it in one unbroken stream. That is roughly how the old telephone network worked, and it has a tidy name: circuit switching. The trouble is that it wastes the wire and breaks badly when anything goes wrong.
With circuit switching, the network first reserves a fixed slice of capacity end to end — a dedicated path — before you may send a single bit. Imagine booking an entire highway lane from your house to your friend's house just to drive one car over: the lane sits empty whenever you pause, yet nobody else may use it. Worse, if one link on that reserved path fails, your whole call drops, because there is exactly one path and it is gone. Reserving works beautifully for a steady voice call, but real computer traffic is bursty — a flurry, then nothing — so a reserved lane mostly sits idle.
So the Internet does something almost rude: it chops your photo into many small chunks called packets, and sends each one off on its own. No path is reserved in advance. Each packet finds its own way, and the receiver glues them back together at the end. This is packet switching, and the whole rest of this subject is essentially the consequences of that one decision.
A packet is a postcard with an address
The cleanest way to picture a packet is a postcard. The middle of the card is the message — a slice of your photo, say a few hundred to about 1500 bytes of it. Around that message the sender writes a header: who it's from, who it's going to, and a few housekeeping notes. The post office never opens the message to read it; it just reads the address and shoves the card toward the right next town. Each packet is fully self-describing, so it can travel completely independently of its siblings.
That self-describing structure is no accident — it follows a protocol, the agreed rulebook we met earlier. A protocol fixes three things: the format of the message (which bits mean the address, which mean the length), the order of exchange (this message, then that reply), and the actions taken on each message (if the address isn't mine, forward it). Because every device agrees on the same rulebook, a packet written by a phone in Taipei is perfectly readable by a router in Frankfurt that has never heard of that phone.
Store-and-forward: hold the whole card, then pass it on
A packet rarely reaches its destination in one hop. It hops from switch to switch across the core, and at each one something specific happens called store-and-forward. The switch must receive the entire packet and store it in memory before it sends the first bit onward. It cannot start forwarding the front of the packet while the tail is still arriving — it has to have the whole card in hand first, partly so it can check the packet wasn't corrupted in transit.
Here is why chopping data into many small packets pays off. Suppose a file must cross three links in a row. If you sent it as one giant blob, link two sits idle until link one has swallowed the whole thing. But split into packets, the front packet can already be racing across link two while the next packet is still crossing link one — the links work in parallel, like an assembly line. Small packets also limit the damage from any single error: if one postcard is smudged, you resend that one card, not the whole album.
The cost of store-and-forward is that each switch must hold packets in a buffer — a waiting line. When packets arrive faster than the outgoing link can drain them, they queue. This is the most important and most variable source of delay in the whole network, and it is the direct reason a network can feel snappy one second and sluggish the next. We give it a name in the next section: queuing delay.
Where does the time go? The four delays
When a packet crosses one hop, the delay it suffers is really four separate things added together. It helps enormously to keep them apart, because they behave completely differently. Think of mailing a letter from a busy post office: standing in line, the clerk reading your address, physically loading the truck, and the truck's drive across the country.
- Processing delay — the switch reads the header and decides where to send the packet. This is the clerk glancing at your address. Today it's tiny, often microseconds.
- Queuing delay — the packet waits in the buffer behind other packets headed out the same link. This is the line of people ahead of you. It swings from zero to large depending on how busy the link is, which is why it's the hardest to predict.
- Transmission delay — the time to push every bit of the packet onto the link, equal to packet size divided by the link rate. This is loading the truck: a fatter parcel takes longer to load. A 12000-bit packet onto a 100 Mbps link takes 12000 / 100000000 = 0.12 milliseconds.
- Propagation delay — the time for those bits, once on the wire, to physically travel to the far end at roughly two-thirds the speed of light. This is the truck's actual drive. Across a fiber spanning a continent, this alone is tens of milliseconds, and no amount of money makes light go faster.
Three words that aren't the same: bandwidth, throughput, latency
People say a connection is "fast," but that single word hides three different ideas that beginners (and adverts) constantly blur together. Bandwidth is the maximum rate of a link, measured in bits per second — say 100 Mbps or 1 Gbps. Picture the width of a pipe: a wide pipe can carry more water per second. Bandwidth is a property of the link itself, the ceiling, not the speed you actually get.
Throughput is the rate you actually achieve, here and now, end to end. A chain is only as strong as its weakest link, so over a path of two links running at rates R1 and R2, your throughput is min(R1, R2) — the narrowest pipe in the chain decides everything downstream. If your home link is 1 Gbps but the server you're downloading from can only push 20 Mbps, you get about 20 Mbps. The widest pipe in the world can't help if water is dripping in from a narrow one upstream.
Latency is something else entirely: the time for one packet to make the trip, dominated by the propagation and queuing delays above. Here is the misconception worth burning into memory: buying more bandwidth does NOT cut latency. A wider pipe lets more bits flow per second, but each individual bit still has to physically travel the distance at the speed of light. Upgrading from 100 Mbps to 1 Gbps does nothing for the round-trip time to a game server on another continent — that delay is set by geography and physics, not by the size of your pipe.
Nested envelopes: layering and encapsulation
One question remains: how does a packet ever get its address, length, and error-check filled in without one giant tangled program doing everything? The answer is the single biggest idea in networking — layering. We split the job into a stack of layers, each handling one concern and offering a tidy service to the layer above. The application worries about your photo; the transport layer worries about reliable delivery; the network layer worries about addresses across the whole Internet; the link layer worries about the next hop. Each layer trusts the one below to do its part and never peeks at how.
The mechanism that makes layering physical is encapsulation: nested envelopes. Your data starts as a bare message. The transport layer wraps it in an envelope with a port number; the network layer wraps that in a bigger envelope with IP addresses; the link layer wraps that in yet another with hardware addresses. Each layer adds only its own header and never touches what's inside. At the destination the envelopes are opened in reverse order, outermost first, each layer reading only its own header. The diagram below shows your bytes growing a header at each step down the stack.
Going DOWN the stack at the sender (each layer adds its own header):
Application: [ your photo bytes ]
Transport (TCP): [ TCP hdr | your photo bytes ]
Network (IP): [ IP hdr | TCP hdr | your photo bytes ]
Link (Ethernet): [ Eth hdr | IP hdr | TCP hdr | photo | Eth trailer ]
^outermost: read first by the next hop
Going UP the stack at the receiver: strip Eth, then IP, then TCP,
hand the bare photo bytes to the application. Reverse order.Two layered blueprints organize this. The seven-layer OSI model is a teaching reference — clean, complete, and great for naming where a problem lives. But the real Internet actually runs the leaner TCP/IP model: application, transport, network, link. When an engineer says "that's a layer-3 problem," they mean the network (IP) layer. Hold both in mind, but remember which one the wires really obey. We unpack OSI versus TCP/IP, side by side, in guide five of this rung.