What Happens When You Open a Website?

You type routelearn.net or https://routelearn.net and press Enter. The browser splits the URL (Uniform Resource Locator) into parts:

If you typed only the name, the browser assumes HTTPS (or tries HTTP first and is redirected to HTTPS).

Learn more: HTTP: How the Web Talks · Common Ports to Know

Fetching from the network is slow compared with reading from memory, so the browser first looks for things it already has:

• Page cache: a saved copy of the page or its files (images, stylesheets). If a copy is still marked fresh, it can be used without asking the server at all.
• DNS cache: a stored IP address for routelearn.net, kept by the browser and the operating system.
• Open connections: an existing TCP and TLS connection to the same server that can be reused.

On this first visit, nothing is cached, so the browser must go to the network for everything.

Computers connect to IP addresses, not names. DNS (Domain Name System) works like the internet's phone book. The operating system sends a small query to its configured DNS resolver (learned from DHCP) asking for the A record (IPv4 address) of routelearn.net.

The query normally travels over UDP to port 53, from a random high source port. The resolver is on another network, so this query itself goes through steps 5 to 12 below. If the resolver doesn't already know the answer, it asks the root servers, then the .net servers, then the domain's own authoritative servers.

The operating system stores the answer in its DNS cache for the record's TTL and passes 198.51.100.10 to the browser. From now on, the network only uses this IP address. The name appears again only inside TLS and HTTP. If DNS fails here, none of the later steps can happen.

Learn more: DNS Problems

The laptop applies its subnet mask to 198.51.100.10. It is not in 192.168.1.0/24, so the server is remote and the packet must go to the default gateway. This is exactly the decision described in Different-subnet communication. (For a website on the internet, the server is practically always remote.)

To put the packet in a frame, the laptop needs the router's MAC address. It checks its ARP cache; if the entry is missing, it broadcasts an ARP request for 192.168.1.1. In practice, the entry is almost always cached already, because the DNS query in step 3 needed the same gateway. The laptop never sends an ARP request for 198.51.100.10, because the server is not on its local network.

Learn more: ARP for Local and Remote Destinations

The laptop encapsulates the first packet, a TCP SYN (step 14), layer by layer:

• TCP header: source port 51000 (a temporary "ephemeral" port the operating system picks for this connection), destination port 443.
• IP header: source 192.168.1.50, destination 198.51.100.10, TTL 128.
• Ethernet header: source 02:00:00:00:00:aa, destination 02:00:00:00:00:01 (the gateway), plus an FCS (frame check sequence) trailer.

Learn more: Port Numbers and Sockets · The Ethernet Frame

The switch learns the laptop's MAC address on the port it arrived on, finds the router's MAC address …:01 in its MAC address table, and forwards the frame out of that one port, unchanged. On Wi-Fi, the access point does a similar job, then passes the frame onto the wired network.

Learn more: How a Switch Learns MAC Addresses

The home router is several devices in one box. In order:

1. Router, Layer 2: the destination MAC address is its own, so it accepts the frame and removes the Ethernet header.
2. Router, Layer 3: it looks up 198.51.100.10 in its routing table. The only match is the default route (0.0.0.0/0, "everything else"), pointing to the ISP router 203.0.113.1. The TTL drops to 127.
3. Firewall: a stateful firewall checks its rules. Connections started from inside are normally allowed. It records this connection in its state table, so the reply will be let back in while uninvited traffic from outside is blocked.

Learn more: Routers · Firewall Basics

192.168.1.50 is a private address. Private addresses are not routed on the internet, so the server could never reply to it. The router therefore performs PAT (Port Address Translation, the common form of NAT):

• It replaces the source IP 192.168.1.50 with its own public IP 203.0.113.25.
• It may replace the source port too (here 51000 → 40001). Many routers keep the original port when it is free; either way, the port is what tells the conversations apart.
• It writes the mapping into its NAT table so it can reverse it later (step 19).
• It builds a new frame for the ISP link, from its WAN MAC to the ISP router's MAC.

Every device in the home shares that one public IP address.

Learn more: Why NAT Exists

The frame crosses the access link (DSL, cable, fibre or mobile, usually through a modem or fibre terminal) to the ISP's first router. That link may not use Ethernet at all, but the idea is the same: a Layer 2 header for this one link, wrapped around the unchanged IP packet. The ISP router removes that header, looks up 198.51.100.10 and sends the packet on.

The internet is made of thousands of separate networks, run by different companies and connected together. Each router on the way does exactly what R1 did in Different-subnet communication: remove the frame, look up the destination, lower the TTL by one and build a new frame for the next link. A typical path crosses 8 to 20 routers.

How do they know the way? Large networks tell each other which addresses they can reach using a routing protocol called BGP (Border Gateway Protocol). You don't need the details here; the CCNA course covers it. You can watch the hops yourself with traceroute.

Learn more: Where BGP Fits

The last router delivers a frame to the server's MAC address. The server de-encapsulates it: its own MAC address, its own IP address, and TCP destination port 443, where the web server software is listening. Note that the server sees the home's public address 203.0.113.25, never 192.168.1.50.

Large sites rarely run on a single server. The address usually belongs to a load balancer or a content delivery network (CDN) edge server close to you, which passes the request to one of many servers behind it. The steps from your side look the same.

The packet you just followed was a SYN, the first of three messages that open a TCP connection. TCP makes the connection reliable: it numbers every byte, resends anything lost and puts the data back in order. Each side picks a random starting sequence number.

TLS (Transport Layer Security) is what puts the "S" in HTTPS. Before any web content is sent, the browser and the server use TLS to:

• Agree on encryption keys without ever sending the keys themselves across the network.
• Prove the server's identity: the server sends a certificate for routelearn.net, signed by a certificate authority the browser trusts. The browser checks that the name matches, the signature is valid and the certificate has not expired.
• Agree on the application protocol, for example HTTP/2.

With TLS 1.3, this takes one round trip. You can check any site's certificate with the SSL Checker.

Learn more: HTTPS and TLS

The browser sends an HTTP request through the encrypted TLS channel. Decrypted, it looks roughly like this:

GET / HTTP/2
:authority: routelearn.net
user-agent: Mozilla/5.0 (...)
accept: text/html
accept-language: en-GB

On the wire, routers see only the IP addresses, the ports and encrypted bytes. The URL path and the HTTP headers are hidden. The packet follows the same route as the SYN: steps 7 to 13 again, including NAT.

The web server finds (or generates) the home page and replies with a status code and the content:

HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: public, max-age=0, must-revalidate

<!DOCTYPE html><html> ... the page ... </html>

200 means OK. Other common codes are 301 (moved), 404 (not found) and 500 (server error). A page larger than one packet is split across many TCP segments, which the laptop acknowledges as they arrive.

The reply simply swaps the source and destination. It is addressed to the public address 203.0.113.25:40001, because that is the only address the server ever saw. Internet routers forward it hop by hop, as in step 12. The return path doesn't have to use the same routers as the outgoing path, and often doesn't.

The home router receives a packet for 203.0.113.25:40001. It looks in its NAT table and finds that port 40001 belongs to 192.168.1.50:51000, and the firewall confirms that the packet belongs to a connection started from inside. The router rewrites the destination, routes the packet onto the LAN and builds a new frame from …:01 to the laptop's …:aa (using its own ARP cache for 192.168.1.50).

The frame goes through the switch to the laptop, which unwraps it from the bottom up:

1. Ethernet: the destination MAC address is mine and the FCS is good → pass up to IP.
2. IP: the destination 192.168.1.50 is mine → pass up to TCP.
3. TCP: port 51000 belongs to the browser's connection. TCP acknowledges the data and puts the segments back in order.
4. TLS: decrypts the bytes and checks that they were not changed on the way.
5. HTTP: passes the status code, headers and HTML to the browser.

The browser reads the HTML and builds the page structure. The HTML refers to more files (stylesheets, scripts, fonts, images), so the browser requests those too. Files from routelearn.net reuse the existing TCP and TLS connection; files from other domains need their own DNS lookup and connection (steps 3 to 20 again). Finally, the browser lays out the page and draws it on the screen, usually in well under a second.