How the Internet Actually Works: From Browser to Server

Step 0: What your browser actually needs

Your browser cannot talk directly to domain names, applications, containers, or Kubernetes. It only knows how to talk to IP addresses and ports, using TCP.

So the browser’s very first question is: "What IP address should I connect to?" That is where DNS comes in.

Step 1: DNS — name to IP

From Part 1: DNS is the phonebook of the internet. Your browser asks the operating system, "Do you know the IP for myapp.com?" If it does, you get back an IP like 13.234.56.78 and move on.

• Cache hit: your system already knows the IP, so there is no network request and the response is faster.
• Cache miss: your system asks a DNS resolver, which asks other DNS servers until it gets an IP address.

Step 2: Choosing the port (HTTP vs HTTPS)

The https in the URL matters. It tells the browser to use port 443 and encrypted communication. If it were http://, that would mean port 80. So now the browser knows both the IP and the port:

IP:   13.234.56.78
Port: 443

Step 3: The TCP connection

Before any data is sent, TCP does something crucial: it opens a connection with a handshake. This is why TCP is called connection-based.

If this step fails, you see errors like "connection refused" or "connection timed out" — usually a firewall blocking it, a port that is not open, or a service that is not running.

Step 4: TLS (the HTTPS security layer)

Because this is HTTPS, another step happens. The browser and server agree on encryption, exchange certificates, and set up a secure channel. If TLS fails, you see a "your connection is not private" warning or certificate errors.

Step 5: The HTTP request is sent

Only now does the browser actually send the request:

GET / HTTP/1.1
Host: myapp.com

And here is the key idea: HTTP is inside TCP, TCP is inside IP, and IP is inside the network. Think of it like nested boxes.

[ Network
  [ IP
    [ TCP
      [ HTTP request ] ] ] ]

Step 6: The request reaches the server

On the server side, the OS receives the packet, TCP hands the data to the application, and the web server (Nginx, Node, and so on) processes it. The application logic runs and a response is created:

HTTP/1.1 200 OK

Step 7: The response travels back

The response goes back through TCP, over the network, to your browser. Your browser then parses the HTML, loads the CSS and JS, and makes more requests — which repeat these same steps. One page load is many network requests.

The full flow at a glance

Put every step together and this is the core internet flow — the path of a single request from your browser to the server and back.

Where things usually break

Because the flow is a sequence, each stage is its own failure point. Knowing which stage failed tells you where to look.

Commands mapped to each step

And the tools from Part 1 map directly onto the journey — one command per stage, so you can test exactly where the request stops.