How does a web page reach you? The journey of packets on the internet

You tap a link on your phone and the page opens in less than a second. Yet that page may live on a computer hundreds or thousands of kilometres away. There is no single cable in between; there are dozens of networks, fibre-optic cables running under the sea and, at every junction along the way, devices that make decisions. What is more, the page does not travel in one piece: it is split into small packets, the packets travel without knowing about one another, and they are put back together on your device. In this post we follow that journey step by step, and in the middle there is a sorting plant you can play with yourself.

First the address: DNS works like a directory

You type a name such as example.com into your browser, but devices on a network talk in numbers, not names: in IP addresses. The system that turns a name into an address is called DNS (the Domain Name System). It works like a phone directory: you look up the name and find the number.

Your device first asks a resolver, usually a server run by your internet provider or by a service you have chosen. If the resolver does not know the answer, it asks in turn the root servers, the servers for an ending such as .com and finally the server responsible for that domain name. The answer is kept in a cache for a while, so the second time you visit the same site this question and answer usually does not happen at all. A DNS lookup normally takes milliseconds, but a slow resolver can visibly delay a page.

The message is split into packets

Once the address is found, the real work starts. A web page is not sent as one large block; it is cut into small pieces. On Ethernet, which is common in home and school networks, a packet can carry at most 1500 bytes. The IP and TCP headers take up about 40 bytes, which leaves around 1460 bytes of actual data per packet. So a 1-megabyte page is split into roughly 700 packets.

Why split it? Because the network does not reserve a whole path for a single conversation. In old telephone exchanges, the line between two people was set aside for them while they talked (circuit switching). The internet uses packet switching instead: packets from millions of people take turns on the same cable at the same time, and nobody holds the path alone. If a packet is lost, it is enough to resend that packet rather than the whole message.

The idea was developed in the 1960s in two places, independently. In the United States, Paul Baran at the RAND Corporation designed a distributed communication network that could keep working even when parts of it were damaged; in Britain, Donald Davies at the National Physical Laboratory reached the same idea and named the pieces “packets”. ARPANET, which started working in 1969, was the first large-scale trial of the idea.

IP address: the label on every packet

Every packet begins with a header, much like the writing on the outside of an envelope. The two most important pieces of information are the sender’s and the receiver’s IP address. In IPv4, the most common version today, an address is a 32-bit number written as four numbers separated by dots, such as 203.0.113.7. That allows about 4.3 billion different addresses; because this is not enough for today’s devices, the move to IPv6, which uses 128-bit addresses, is under way.

The header also has a time to live (TTL) field. Every router the packet passes through lowers this number by one; if it reaches zero, the packet is thrown away. That way, a badly configured network cannot produce packets that circle forever.

A note: most sites today open over HTTPS. In that case the data inside the packet is encrypted, and the devices along the way cannot read the content of the page. But they have to read the address label to take the packet to the right place, so the header stays readable.

Routers: one decision at every junction

At every junction on the packet’s journey there is a router. The modem in your home is a small router; in the centres of internet providers, large routers handle millions of packets per second.

A router’s job is simpler than you might think: it looks at the packet’s destination address, finds the best exit for that address in its own routing table and passes the packet through that door to the next device. It does not know the packet’s whole path; it only knows “for this address, hand it to that neighbour”. The path is the sum of these small decisions made at every junction.

The tables are not fixed. Routers constantly exchange information with their neighbours; between the internet’s large networks this is done by a routing protocol called BGP. When a cable breaks or a path gets clogged, the news spreads and traffic shifts to other paths. Learning the new path takes a while, and in the meantime packets sent down the broken path may be lost.

In the figure below we have built this world as a small sorting plant. On the desk on the left, the message waits split into numbered cartridges, the packets. At the first router, a turning switch arm sends each packet onto the upper or the lower line. At the stations on the lines, packets may wait their turn because of other traffic. On the right, the receiver drops each packet into the slot with its number. Press Send, tap a station to cut its line, type in your own message size (in KB or packets), loss rate and line delay, and watch how the numbers change.

Packets arrive out of order

If you send the message a few times in the figure, you will see that the order of arrival is a little different each time: packet 5 may arrive before packet 4. There are two reasons. First, packets may take different paths, and the paths have different lengths. Second, every router has a queue; if other packets are passing at that moment, the packet waits. The waiting time changes from moment to moment.

In real networks, the packets of one connection usually take the same path, because routers deliberately try to keep packets of the same connection on the same path. The path changes when there is a failure or a shift in load, and that is when out-of-order arrival becomes common. In the figure, the first router spreads packets one by one over the two lines so that the effect is easy to see.

How does the receiver cope with the mix-up? This is where TCP (the Transmission Control Protocol) comes in. TCP puts sequence numbers on the data it sends. In reality these numbers count bytes, not packets, but the idea is the same: the receiver arranges the arriving pieces by number in a buffer and hands the application, your browser, only data whose order is complete. That is why each slot on the receiver’s desk in the figure has a number engraved in front of it.

A lost packet: TCP sends it again

The internet does not guarantee that packets will arrive; the network “does its best”. Packets can be lost. The most common cause is congestion: when a router’s queue is full, it has to drop newly arriving packets. A broken cable, a faulty device or a corrupted signal can also lose packets.

TCP solves this with acknowledgements. The receiver sends the sender an acknowledgement (ACK) for the data it has received. The sender keeps a copy of every packet until its acknowledgement arrives. If the acknowledgement does not come within a certain time, that is, if a timeout runs out, it sends the packet again. This time is not fixed; TCP keeps measuring the round-trip time and sets the timeout from it. And when the receiver asks for the same missing piece several times in a row, the sender can resend it without waiting for the timeout (fast retransmit).

In the figure, cut a line and send the message. Packets sent down the cut line get stuck at the station and fall into the bin. Shortly afterwards the first router learns about the cut and moves the traffic to the other line. Because the lost packets are never acknowledged, the sender sends them again; you can recognise the resent cartridges by their purple labels. The total time grows, but the message is put back together in full. This is one of the internet’s most important features: even if pieces are lost, the whole arrives correctly in the end.

Not every application wants this guarantee. In a video call or an online game, waiting for a late piece of sound is worse than skipping it. Such applications often use UDP, which does no resending. The newer web protocol HTTP/3 uses QUIC, which runs over UDP and provides reliability itself.

Where does delay come from?

A packet’s journey is the sum of four kinds of delay:

• Propagation delay: a signal needs time to travel along a cable. Light travels about 200,000 kilometres per second in optical fibre, which means about 5 milliseconds for every 1000 kilometres. Cables do not run in a straight line either, so the real path is longer.
• Transmission delay: putting the packet’s bits onto the cable also takes time. A 1500-byte packet goes out on a 100-megabit-per-second line in roughly 0.12 milliseconds.
• Queuing delay: waiting in line at a router. The busier the network, the longer it gets, and it is the delay that varies most.
• Processing delay: the router reading the header and making its decision. On modern devices it is usually very short.

Propagation delay is a law of physics; you cannot shorten it by buying a faster connection. Over a link through geostationary satellites, about 36,000 kilometres above the Earth, the signal needs roughly a quarter of a second just to go up to the satellite and come back down, in one direction alone. That is why most data between continents travels through fibre-optic cables under the sea rather than by satellite.

The default times in the figure, by contrast, were not measured on a real connection; they are example values that make these four effects easy to see. You can change the line delay yourself: to try a geostationary satellite link, for example, enter 250 ms and send the message once more with 10 per cent loss. When there is loss and resending, the total time grows noticeably, because the sender first has to wait for the timeout to run out; the longer the delay, the longer the timeout, and the more every loss costs.

Try it yourself: trace a packet’s route

You can see the routers your packets pass through on your own computer. On Windows, open Command Prompt and type:

tracert example.com

On macOS and Linux the command is traceroute example.com. The program uses the time to live (TTL) field: it first sends packets with a TTL of 1; the first router lowers the number to zero, drops the packet and sends back an error message. Then it uses a TTL of 2, then 3, and so on. Each line shows one router and the round-trip time to it. If you see stars (*) on some lines, don’t worry: many routers are set up not to answer these messages. School or work networks may block these commands; in that case try at home. The ping example.com command measures only the round-trip time.

Try two different sites: can you explain the difference in time between a site hosted in a nearby country and one hosted across an ocean using propagation delay?

Summary

• A domain name is first turned into an IP address by DNS; the answer is kept in a cache.
• Data is split into packets of about 1.5 kilobytes; the header of every packet carries the sender’s and the receiver’s IP address.
• Routers choose only the next step for each packet; the path is the sum of these decisions and can change when something fails.
• Packets can arrive out of order because of different paths and queues; TCP puts them back in order with sequence numbers.
• A lost packet is never acknowledged; when the timeout runs out, the sender sends it again.
• Delay is the sum of propagation, transmission, queuing and processing times; propagation delay is limited by the speed of light.