Networking · The big picture

The journey of a packet: how two machines talk across the internet

Follow one request from a laptop to a server on the other side of the world and back: the name lookup, the five envelopes, the first hop, NAT, the routers in between, and the bill in round trips.

Updated 2026-09-08

On this page

You are on a sofa in Bangalore. You type https://example.com and press Enter. Under a second later a page appears, served by a machine in Virginia, 14,000 kilometres away. In that second your laptop found the machine, agreed on a secret with it, asked a question, and got 40 kilobytes back, through your Wi-Fi, your router, your ISP, a few cables on the ocean floor, and a dozen routers that had never heard of either of you. This page follows the packet the whole way. Every step is simple. There are just a lot of them.

The map

Read this first when short on time. Every branch is a section below.

Figure 1. The whole article on one page. Every branch is a section below; fold what you know, open what you do not.

Before anything moves: turning a name into an address

A packet needs a number to go to, not a name. So the first thing your laptop does is ask what example.com means. Most of the time the answer is already sitting in a cache and this step costs nothing. The first time, it is a small journey of its own.

sequenceDiagram
  autonumber
  participant L as Laptop
  participant R as Resolver (ISP)
  participant T as Root and .com
  participant A as example.com DNS
  L->>R: what is example.com?
  R->>T: who handles .com? who handles example.com?
  T-->>R: ask these servers
  R->>A: what is example.com?
  A-->>R: 93.184.216.34, cache it for 1 hour
  R-->>L: 93.184.216.34

Figure 2. A cold lookup. The resolver does the walking and remembers every answer. The second person on the same ISP to ask gets the reply straight from step 6.

The browser checks its own cache, then asks the operating system, which checks /etc/hosts and its own cache.
If nothing is cached, the OS sends a UDP packet to its resolver, the address in /etc/resolv.conf: usually your ISP's, or a public one like 8.8.8.8 or 1.1.1.1.
The resolver, if it does not know either, asks a root server for who handles .com, asks a .com server who handles example.com, and asks that server for the address.
Every answer comes with a time to live. The resolver caches it for that long, and so does your OS.

The whole chain is a few UDP packets, one question and one answer each, which is exactly what UDP is good at; the UDP article explains why DNS chose it. The resolver hierarchy, anycast, and what a CDN does with DNS are in the networking and edge article. For this story, the outcome is one number: 93.184.216.34.

In the wild

1.1.1.1 and 8.8.8.8 are resolvers with the same address in every city, so your query reaches a nearby copy. That is anycast.
systemd-resolved on Linux is a local cache at 127.0.0.53, which is why /etc/resolv.conf often points at your own machine.
A 60-second TTL is what lets a company move a service to a new address in a minute; a 24-hour TTL is why some users see the old one for a day.

Resolver: The DNS server your machine asks. It does the recursive lookup and caches the results.
TTL (DNS): Time to live on an answer: how long a cache may keep it.

Five envelopes: how the request is wrapped

Your request is a few hundred bytes of text: GET / HTTP/1.1 and some headers. Before it leaves the machine it is put inside four more envelopes, each with its own address on the front. Every layer only reads its own envelope.

Figure 3. One packet on the wire. Each layer adds a header in front of the one inside. A switch reads the outer one, a router the next, and only the server opens the last two.

Layer	Header says	Who reads it	Article
HTTP	What you want: the path, the host, your cookies	The server program	HTTP
TLS	Which encryption, and then bytes nobody in between can read	The two ends	security
TCP	Which program: port 443. Sequence numbers, ACKs, window	The two kernels	TCP
IP	Which machine: the destination address. TTL, length, protocol	Every router on the path	this page
Ethernet	Which device on this local link: the MAC address of the next hop	The switch and the next hop only	this page

The sizes matter. An Ethernet frame carries at most 1500 bytes, the MTU. IP and TCP headers take 40 of them, TLS a few more, so a full packet holds about 1400 bytes of your data. A 40 KB page is about 30 packets. Your request fits in one.

The addresses on the envelopes change at different rates. The IP addresses, yours and the server's, stay the same for the whole trip. The MAC addresses are rewritten at every hop, because a MAC address only means something on one local link. This is the single most useful thing to remember about how the internet is put together.

In the wild

Wireshark shows exactly this stack for every packet: Ethernet, IP, TCP, TLS, and HTTP if it can decrypt it.
Jumbo frames of 9000 bytes are used inside data centres to cut header overhead; the public internet stays at 1500.
VPNs add another envelope, an encrypted UDP packet around the IP packet, which is why a VPN lowers the usable MTU to around 1400.

Encapsulation: Putting one layer's packet inside the next layer's, with a header in front.
MTU: Maximum transmission unit. The largest frame a link carries. 1500 bytes on Ethernet.
MAC address: The hardware address of a network card. Meaningful only on the local link.

The first hop: getting off the sofa

Your laptop now has an IP packet for 93.184.216.34. It cannot deliver that itself. It has to hand the packet to something on its own network that knows the way. The rule is one comparison.

The laptop's address is 192.168.1.20 with a mask of /24, meaning "everything starting 192.168.1 is on my link". 93.184.216.34 does not start that way, so it is not local. The routing table says what to do with everything non-local: send it to the default gateway, 192.168.1.1, your home router. The Linux sockets article shows that table.

But the Ethernet envelope needs a MAC address, and the laptop only knows the router's IP. So it shouts on the local network:

sequenceDiagram
  autonumber
  participant L as Laptop
  participant W as Wi-Fi (everyone)
  participant R as Router
  L->>W: ARP: who has 192.168.1.1? tell 192.168.1.20
  W->>R: (broadcast reaches every device)
  R-->>L: ARP: 192.168.1.1 is at a4:2b:8c:11:22:33
  L->>R: frame to a4:2b:8c:11:22:33, IP packet to 93.184.216.34 inside

Figure 4. ARP. The laptop asks the whole local network for the router's hardware address, caches the answer, and only then can it send the frame. The frame is addressed to the router; the packet inside is addressed to Virginia.

That is the trick in miniature. The frame says "to the router". The packet inside says "to 93.184.216.34". The router opens the frame, sees a packet that is not for it, and forwards it. Every hop from here to Virginia will do the same: new frame, same packet.

On Wi-Fi the steps are identical. The radio replaces the cable, the access point is the switch, and the frame format is slightly different, but ARP, the gateway and the MAC address all work the same way. Your phone on cellular skips ARP because there is no shared link, but it still hands everything to a gateway.

In the wild

ip neigh on Linux and arp -a on macOS show the cache of MAC addresses learned this way.
"Connected, no internet" is usually this step or the next failing: the laptop has an address but the gateway does not answer ARP, or answers and then drops everything.
A duplicate IP address on a network makes two devices answer the same ARP question, and traffic flips between them at random.

Subnet mask: The part of an address that identifies the local network. /24 means the first 24 bits.
Default gateway: The router that gets every packet not addressed to the local network.
ARP: Address Resolution Protocol. A broadcast question that turns an IP address into a MAC address on the local link.

Out the door: the home router and NAT

Your router has a problem. Your laptop's address, 192.168.1.20, is a private address. Millions of homes use the same one. Nothing on the internet can route a reply to it. The router has exactly one public address from the ISP, say 203.0.113.7, and it has to make every device in the house look like that one machine.

flowchart TD
  A["Laptop sends: from 192.168.1.20:51234 to 93.184.216.34:443"] --> B["Router rewrites: from 203.0.113.7:40001 to 93.184.216.34:443"]
  B --> C["Router remembers: 40001 means 192.168.1.20:51234"]
  C --> D["Reply arrives: to 203.0.113.7:40001"]
  D --> E["Router rewrites: to 192.168.1.20:51234, forwards to the laptop"]

Figure 5. Network address translation. The router swaps your private address and port for its public ones, keeps a note, and undoes the swap on the way back. The server only ever sees 203.0.113.7.

The router changes the source address to its own public one, and usually the source port too, so that two devices using the same port do not collide. It writes the pair in a table. When a packet comes back to that port, it looks up the table, restores the private address, and forwards the packet inside. This is NAT, and it is the reason the IPv4 internet did not run out of addresses twenty years ago.

Two consequences follow. Nobody on the outside can start a connection to your laptop, because there is no table entry until you send something first; that is a free firewall, and also why hosting a game server at home needs "port forwarding". And table entries expire when idle, a minute or so for UDP and much longer for TCP, which is why long-idle connections sometimes die quietly. The netfilter section shows the same mechanism on a Linux box, where it is called masquerade.

In the wild

Every home router does this. Many ISPs do it a second time on their side (carrier-grade NAT), so your packet may be rewritten twice before it reaches the open internet.
AWS NAT gateways do the same for private subnets: instances with 10.x addresses reach the internet through one public address.
IPv6 gives every device a public address and needs none of this, which is the main reason it exists. On IPv6 the router only forwards.

Private address: 10.x, 172.16 to 172.31, 192.168.x. Reused in every home and office, never routed on the internet.
NAT: Network address translation. Rewriting addresses and ports so many private machines share one public address.

Across the internet: routers, hops and the ocean floor

From the ISP onward the packet is in the hands of routers, and a router does exactly one thing with it: look at the destination IP, find the best matching entry in its table, and hand the packet to the next router. It does not know or care what is inside. It does not know where the packet came from. It has never heard of the server. It only knows which neighbour is closer to 93.184.216.34.

flowchart TD
  A["Home router 192.168.1.1 · TTL 64"] --> B["ISP edge router, Bangalore · TTL 63"]
  B --> C["ISP core, Mumbai · TTL 62"]
  C --> D["Submarine cable landing, Mumbai · TTL 61"]
  D --> E["Marseille, then Frankfurt · TTL 59"]
  E --> F["Transatlantic cable, New York · TTL 57"]
  F --> G["Ashburn, Virginia · TTL 55"]
  G --> H["Data centre router, server rack · TTL 53"]

Figure 6. A plausible path. Eleven hops, each one a router that read the destination address and forwarded. The TTL counts down by one per hop so a looping packet dies instead of circling forever.

The routing table in a big router has about a million entries, one per block of addresses in use on the internet. It finds the most specific one that matches, the longest prefix, exactly like your laptop did with its two-line table. The entries come from BGP, the protocol that networks use to tell each other "I can reach these addresses". The internet is about 75,000 such networks, called autonomous systems, and BGP is the gossip between them. Your ISP, the cable operator, and the data centre's network each speak it to their neighbours. No single router has a map of the whole thing; each just knows the next step.

Two safety features ride along in the IP header. The TTL starts at 64 on Linux and every router subtracts one; at zero the packet is dropped and the router sends back an error, which is how traceroute draws the path, as the ICMP article explains. And the header carries a checksum so a corrupted address is dropped rather than misdelivered.

Physics sets the floor for the time this takes. Light in glass fibre moves at about 200,000 km per second, two thirds of its speed in vacuum. Bangalore to Virginia by cable is roughly 20,000 km of fibre, so about 100 ms one way, 200 ms for a round trip, before any router or queue adds anything. Nothing you do in software changes that number. Everything about making the web feel fast is about making fewer of those trips, or making them shorter by putting the server closer.

One more thing that surprises people: the reply does not have to come back the same way. Each router chooses its next hop for the destination in front of it, and the server's ISP may prefer a different cable than yours did. Paths are often asymmetric, and traceroute only ever shows you the outbound half.

In the wild

mtr example.com shows every hop, its latency and its loss, live. The big jumps in latency are the cables.
Submarine cables carry nearly all intercontinental traffic. A ship's anchor cutting one is a real event that reroutes a country's internet within minutes, through BGP.
A BGP mistake can announce addresses a network does not own and pull traffic into a black hole, or withdraw a network's own routes so nobody can reach it; a withdrawal of that kind took a large social network offline for hours in 2021.
Google and Cloudflare avoid most of these hops by having a building in nearly every city, which is the CDN idea in the edge article.

Hop: One router on the path. Each one rewrites the frame, decrements the TTL and forwards.
TTL (IP): Time to live on a packet: a hop counter that starts around 64 and kills the packet at zero.
BGP: Border Gateway Protocol. How networks tell their neighbours which addresses they can reach.
Autonomous system: One network under one administration, with a number, that speaks BGP: an ISP, a cloud, a university.

Arriving: what the server does before it reads a byte

The packet reaches a rack in Virginia. The server's network card copies it into memory and raises an interrupt. The kernel walks the envelopes inward: the frame is for its MAC, the packet is for its IP, the segment is for port 443, and there is a socket listening there. What happens next is not one exchange but three, stacked.

sequenceDiagram
  autonumber
  participant C as Laptop
  participant S as Server
  Note over C,S: TCP: one round trip
  C->>S: SYN
  S-->>C: SYN-ACK
  C->>S: ACK
  Note over C,S: TLS 1.3: one round trip
  C->>S: ClientHello, my keys
  S-->>C: ServerHello, certificate, keys, Finished
  C->>S: Finished
  Note over C,S: HTTP: one round trip
  C->>S: GET / (encrypted)
  S-->>C: 200 OK, 40 KB in 30 packets

Figure 7. Three handshakes before a page. Modern TLS lets the first request ride along with step 6, so TLS and HTTP share a round trip. Each round trip here is 200 ms.

TCP handshake. The server's kernel answers the SYN itself; the program is not involved yet. When the ACK arrives the connection is placed in the listen queue and accept returns it to nginx. The details are in the TCP article.
TLS handshake. The laptop sends what it supports and a fresh public key. The server replies with its certificate, proving it is example.com, and its own key. Both sides now compute the same secret without ever sending it. Everything after this is encrypted, and routers along the way see only random bytes with a TCP header on the front.
The HTTP request. Now, finally, the text you started with: GET / HTTP/1.1. nginx reads it, finds the file, and writes the response into the socket. The kernel cuts it into 30 segments and TCP paces them out under its congestion window.

Very often the "server" here is not the origin at all but a CDN node a few hundred kilometres from you, holding a cached copy of the page. DNS steered you to it, and the whole journey above happened over a much shorter distance. The origin in Virginia only hears about it when the cache misses.

In the wild

The listen queue is the first thing to fill on an overloaded server: handshakes complete, but accept is slow, and clients time out even though the machine is up. The sockets article shows how to see it.
Certificates are the reason the browser trusts that 93.184.216.34 really is example.com. Let's Encrypt issues most of them, for free, automatically.
Cloudflare and CloudFront terminate TLS at the edge and keep warm connections to the origin, so the expensive handshakes happen close to you.

TLS: Transport Layer Security. The encryption layer under HTTPS. Its handshake also proves the server's identity.
Certificate: A signed statement from an authority the browser trusts that this public key belongs to this name.
Origin: The server that actually holds the content, as opposed to a cache in front of it.

The bill: counting round trips

Add it up. The page needed about four trips to Virginia before the first byte of content came back, and each trip was 200 ms. The transfer of 40 KB was almost free next to the waiting.

Step	Round trips	Typical, cold	How it gets cheaper
DNS lookup	1 to the resolver, more behind it	20 to 100 ms	Caching; almost always 0 ms after the first visit
TCP handshake	1	200 ms	Keep-alive: reuse the connection for the next request
TLS handshake	1 (TLS 1.3), 2 on older versions	200 ms	Session resumption, or QUIC which merges it with the transport handshake
HTTP request and response	1	200 ms plus transfer	A CDN node nearby makes this 20 ms instead of 200
Sending 40 KB	a few, while the window grows	50 to 100 ms	Compression, larger initial window

This is why every trick in web performance is really a trick about round trips. Keep-alive skips the TCP handshake for the second request. TLS resumption skips most of the second. QUIC folds the transport and encryption handshakes into one and can send the request in the very first packet on a repeat visit. A CDN does not remove any trip; it makes each one twenty times shorter by moving the far end into your city. And HTTP/2 puts every image on the same connection so none of them pay for a new handshake, as the HTTP article explains.

What goes wrong, and where

Symptom	Usually	Where in the journey
Name does not resolve	Resolver down, or a typo, or a TTL that has not expired after a move	Step one
Connects, then hangs	A lost packet being retransmitted, or a firewall silently dropping	Anywhere; TCP hides it as delay
Small requests work, large ones hang	Path MTU discovery broken: a firewall eats the "too big" message	The routers; see the ICMP article
Idle connection dies after a while	A NAT table entry expired	The home router or the ISP
Works on Wi-Fi, not on cellular	Carrier NAT, or UDP blocked	The first hop
Slow from one country only	A long cable path, or a peering dispute between two networks	The routers and BGP
Certificate warning	Clock wrong, name mismatch, or a middlebox intercepting TLS	Arrival

In the wild

Browser devtools show the waterfall for every request: DNS, connect, TLS, waiting, download, as separate bars. It is this table drawn as a chart.
curl -w with the timing variables (time_namelookup, time_connect, time_appconnect, time_starttransfer) prints the same numbers from a terminal.
A satellite link has a 600 ms round trip, and a page needing four trips takes over two seconds before showing anything, which is why Starlink flies low and geostationary satellites feel slow.

Round trip time: The time for a packet to go there and a reply to come back. The unit everything else is measured in.
Keep-alive: Reusing one TCP connection for several HTTP requests instead of opening a new one each time.

Recap

The name is resolved first, by a resolver that walks root, TLD and authoritative servers, and caches everything. Usually it costs nothing.
The request is wrapped five deep: HTTP in TLS in TCP in IP in Ethernet. Each layer reads only its own header.
IP addresses stay the same end to end. MAC addresses change at every hop and only mean something on one link.
The first hop is decided by the subnet mask: not local means send to the default gateway, whose MAC is found with ARP.
NAT rewrites your private address and port to the router's public ones and reverses it for replies. Nothing outside can connect in unprompted, and idle mappings expire.
A router reads only the destination IP, finds the longest matching prefix, and forwards to the next router. BGP fills those tables across about 75,000 networks.
TTL counts down per hop so loops die. The reply may take a different path.
Light in fibre is about 200,000 km per second; a round trip across the world is about 200 ms and no software makes that shorter.
At the server the kernel unwraps the envelopes and three handshakes happen: TCP, TLS, then the HTTP request.
A cold page load is about four round trips before the first byte. Caching, keep-alive, TLS 1.3, QUIC and CDNs all exist to cut that number.
Most failures map to one step: DNS, first hop, NAT, path MTU, routing, or TLS.

Questions

Try answering each one out loud before opening it. Lead with the one-line answer, then a couple of points, then one extra detail.

What happens when you type a URL and press Enter, end to end?

The browser resolves the name to an IP through a cache or a resolver, opens a TCP connection with a three-way handshake, runs a TLS handshake to agree on keys and check the certificate, sends the HTTP request, and receives the response in packets that TCP reassembles; every packet is wrapped in TCP, IP and Ethernet headers and forwarded hop by hop by routers reading only the destination IP.

The first hop is chosen by the subnet mask and reached via ARP; NAT rewrites the source address at the home router.
About four round trips pass before the first byte of the page arrives.

Usually the far end is a CDN node in your region, not the origin server.

Which addresses change along the path and which stay the same?

The source and destination IP addresses stay the same end to end (apart from NAT rewriting the source at the edge of your network); the MAC addresses in the Ethernet frame are rewritten at every hop because they only identify the next device on one link.

Each router strips the frame, decrements the TTL, and builds a new frame to the next router's MAC.
Ports and everything inside TCP are untouched by routers.

This split is why a switch needs no IP knowledge and a router needs no MAC knowledge beyond its own links.

How does your laptop decide where to send the first packet?

It compares the destination IP with its own address under the subnet mask; if they differ it is not local, so the routing table's default route sends it to the gateway, and ARP finds the gateway's MAC address.

ARP is a broadcast "who has this IP" with a unicast reply, cached for a few minutes.
The frame is addressed to the gateway even though the packet inside is addressed to the far server.

A local destination skips the gateway: ARP finds the peer directly and the frame goes straight to it.

Explain NAT and its two main consequences.

The router rewrites the private source address and port to its public address and a chosen port, keeps a mapping, and reverses it for replies, so many devices share one public IP. Consequently nobody outside can initiate a connection to a private device, and mappings expire when idle.

Port forwarding creates a permanent mapping by hand for a home server.
Carrier-grade NAT does it a second time at the ISP.

IPv6 removes the need for it by giving every device a routable address.

What does a router actually do with a packet?

It reads the destination IP, finds the longest matching prefix in its routing table, decrements the TTL, checks the header checksum, and sends the packet out of the interface toward the next hop in a new frame.

It ignores the source address, the ports and the payload.
Its table comes from BGP, which its neighbours use to announce what they can reach.

No router knows the whole path; each knows one step.

Why does a round trip across the world take about 200 ms no matter how good the servers are?

Because light in fibre travels at roughly 200,000 km per second, and the cable path between distant continents is around 20,000 km, so 100 ms each way is physics before any queueing.

Every handshake and request pays that trip, so latency is about counting trips, not bandwidth.
CDNs move the far end into your region, cutting each trip to tens of milliseconds.

Geostationary satellites add 600 ms per trip, which is why low-orbit constellations exist.

What is the TTL in an IP header for, and how does traceroute use it?

It is a hop counter that every router decrements; at zero the packet is dropped and an ICMP time-exceeded message is sent back, so a routing loop cannot circulate a packet forever. traceroute sends packets with TTL 1, 2, 3 and collects the error from each hop to draw the path.

Linux starts it at 64; Windows at 128.
The return path may differ, so traceroute shows only the outbound route.

Hops that rate-limit ICMP show up as stars without meaning loss.

How many round trips does a cold HTTPS page load take before the first byte, and where do they go?

About four: one to the resolver for DNS, one for the TCP handshake, one for the TLS 1.3 handshake, and one for the HTTP request itself; the request can share the TLS trip on the second and later connections.

Older TLS took two trips; QUIC merges transport and TLS into one, and zero on a repeat visit.
Keep-alive and connection reuse remove the TCP and TLS trips for later requests.

The 40 KB transfer itself is a few more trips while the congestion window grows.

What does encapsulation mean, and why does each layer only read its own header?

Each layer wraps the one above in its own header: HTTP inside TLS inside TCP inside IP inside Ethernet. Each device on the path only needs the layer it operates at, so a switch reads MAC addresses, a router reads IP addresses, and only the two endpoints look at TCP and above.

The layering is why the same IP packet can cross Wi-Fi, fibre and satellite links unchanged.
TLS encrypts everything above it, so routers see only a TCP stream of random bytes.

Header overhead is why a 1500-byte frame carries about 1400 bytes of application data.

Why can the reply take a different route from the request?

Because each router chooses its next hop independently for the destination in front of it, and the server's network may prefer different links and peers than yours, so the two directions are routed separately.

traceroute shows only the outbound path.
Asymmetric paths can make one direction lossy while the other is clean.

Network engineers use "hot potato" routing: hand traffic to the next network at the nearest exit, which naturally makes paths asymmetric.

Where does a CDN fit into this journey?

DNS returns the address of a CDN node near you instead of the origin, so the TCP, TLS and HTTP round trips happen over a few hundred kilometres instead of half the planet, and the node serves cached content or fetches from the origin over a warm connection.

Anycast lets one address be answered from many cities.
The origin only sees cache misses.

The full design is in the system design networking article.

Small requests succeed but large uploads hang. What is the likely cause?

Broken path MTU discovery: some link on the path has a smaller MTU, the "fragmentation needed" ICMP message that would tell the sender to shrink its packets is being blocked by a firewall, so full-size packets vanish silently.

Small packets fit under the smaller MTU, so short requests work.
Fixes are allowing ICMP, or clamping the MSS at the router.

VPNs trigger this often because their envelope lowers the usable MTU to around 1400.