How the Internet Works: From DNS to HTTP

You type github.com into your browser and half a second later the page loads. Looks simple. Under the hood, a chain of operations just ran across at least four distinct protocols, multiple servers spread around the planet, and a fair number of things that can go wrong at any step. Understanding what happens in that half second isn't academic — it's what separates debugging a real timeout from spending an hour looking in the wrong place.

What an IP address is and why you need one

Before talking about DNS, you need to understand the problem it solves.

Every machine connected to the internet has an IP address — a number that works like a postal address on the network. In IPv4, that number looks like 203.0.113.42. In IPv6, it's a longer sequence like 2001:db8::1. Your home router has an IP. GitHub's server has an IP. For two machines to communicate, one needs to know the other's IP.

The problem is obvious: nobody memorizes 140.82.112.3 to access GitHub. DNS exists to solve that.

What DNS is and what happens during a lookup

DNS stands for Domain Name System — the system that translates human-readable names (github.com) into IP addresses (140.82.112.3).

When you type an address into the browser, the first thing that happens is a DNS query. The process follows a hierarchy:

1. Local cache. The operating system checks if it resolved this name recently. If so, it uses the cached result and skips the rest.

2. Recursive resolver. If there's no cache, the query goes to the DNS resolver configured on your network — usually your ISP's, or a public one like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare).

3. Root nameserver. The resolver asks one of the 13 root nameserver clusters: "who handles .com?" The root server responds with the address of the TLD servers.

4. TLD nameserver. The resolver asks the .com server: "who handles github.com?" That server responds with GitHub's authoritative nameservers.

5. Authoritative nameserver. Finally, the resolver asks GitHub's own nameserver: "what's the IP for github.com?" This server has the definitive answer.

This entire process happens in milliseconds. The result is cached for a period defined by the record's TTL (Time to Live) — could be 5 minutes or 24 hours, depending on how the domain is configured.

Browser
  → Local cache (no result)
    → Recursive resolver (8.8.8.8)
      → Root nameserver (. → .com)
        → TLD nameserver (.com → github.com)
          → Authoritative nameserver (github.com → 140.82.112.3)
        ← IP travels back up the chain
  ← Browser now has the IP

Worth noting: for most everyday requests, steps 3 and 4 are skipped because the resolver already has the nameservers for popular domains cached. In practice, many DNS lookups complete in under 20ms.

TCP/IP: how bytes get from one place to another

With the IP in hand, the browser needs to establish a connection. This is where TCP and IP come in — two protocols that operate at different layers.

IP (Internet Protocol) handles addressing and routing: takes a packet of data, puts source and destination addresses on it, and sends it. IP is best-effort — it tries to deliver, but doesn't guarantee the packet will arrive, or that it'll arrive in order.

TCP (Transmission Control Protocol) solves the problems IP doesn't. TCP is connection-oriented and guarantees:

• Packets arrive (and requests retransmission if they don't)
• They arrive in the correct order
• No duplicate data
• Flow control to avoid overwhelming the receiver

Before any data is sent, TCP establishes the connection with a three-way handshake:

Client → SYN      → Server   ("I want to connect")
Client ← SYN-ACK ← Server   ("ok, go ahead")
Client → ACK      → Server   ("confirmed, connection open")

Only after this handshake does the browser start sending the HTTP request. This adds latency — typically one round-trip before the first byte of data. On high-latency connections, this cost is noticeable.

The IP packet travels through the internet via routers. Each router looks at the destination address and decides where to forward the packet — like a postal system that routes letters through whatever's the most efficient path available at that moment. The route can change between different packets of the same connection.

HTTP: the language browsers and servers speak

With the TCP connection established, the browser makes the HTTP request. HTTP is a text protocol — it's literally a structured text message.

A simple GET request looks like this:

GET / HTTP/1.1
Host: github.com
Accept: text/html
User-Agent: Mozilla/5.0

The server receives it, processes it, and responds:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 12345

<!DOCTYPE html>...

The status code on the first line of the response is what the browser uses to decide what to do. 200 means success. 301 or 302 is a redirect — the browser makes a new request to the URL in the Location header. 404 means the resource doesn't exist. 500 is a server error.

HTTPS and TLS: the security layer

Today virtually all browsing uses HTTPS, not HTTP. The difference is the TLS (Transport Layer Security) layer between TCP and HTTP.

Before sending any data, client and server do a TLS handshake:

1. The server presents its digital certificate, which proves it's who it claims to be (issued by a trusted CA — Certificate Authority)
2. Both sides negotiate cryptographic algorithms and exchange keys
3. From that point on, everything is encrypted

This adds another round-trip before the first byte of HTTP data. Modern connections with TLS 1.3 reduced this to zero additional RTTs on reconnections, but the impact is still relevant on new connections.

The padlock in the browser confirms the certificate is valid and the connection is encrypted. It does not confirm the site is trustworthy — only that communication with it is private.

What came after HTTP/1.1

HTTP/1.1 has a serious problem: head-of-line blocking. On each TCP connection, requests are served in a queue — the second only starts when the first finishes. To load a page with 50 resources (JS, CSS, images), the browser opens multiple parallel TCP connections, which has its own costs.

HTTP/2 solved this with multiplexing: multiple requests and responses flow over the same TCP connection in parallel, as independent streams. A delay in one resource doesn't block the others.

HTTP/3 goes further and replaces TCP with QUIC — a protocol over UDP that implements TCP's reliability without the head-of-line blocking problem at the transport level. QUIC also integrates TLS 1.3, eliminating one RTT from the handshake. It's the protocol Google and Cloudflare already use for most traffic.

Where your IP fits in all this

When GitHub's server receives your request, it sees the outbound IP of your network — not your device's IP. If you're home, it's your router's public IP, assigned by your ISP. If you're behind a corporate proxy, it's the proxy's IP. If you're using a VPN, it's the VPN exit node's IP.

That IP tells the server where the connection originated — at the network level, not the person level. To see your own public IP and what it reveals (ISP, ASN, approximate location), I use IP Address Info — you see in real time what any server sees when you make a request.

Frequently asked questions

Why does a site load slowly even with fast internet?

High bandwidth doesn't fix latency. If the server is physically far away, each round trip adds milliseconds — and the TCP+TLS handshake needs at least 2 RTTs before the first byte of data. CDNs (Content Delivery Networks) exist precisely to put servers physically closer to users and reduce this cost.

What is a dynamic IP and why does it change?

Residential ISPs generally don't assign a fixed IP to each customer — they maintain a pool of addresses and assign them as needed. When the router reconnects, it may receive a different IP. A static (fixed) IP is an additional service, common in business contracts.

Can DNS be hacked?

Yes. DNS spoofing (or DNS cache poisoning) is an attack where a resolver receives forged responses and starts returning wrong IPs for legitimate domains. This redirects users to a malicious server without the domain name changing. DNSSEC adds cryptographic signatures to DNS responses to mitigate this, but adoption is still partial.

Why does ping to a domain sometimes return a different IP than what the site uses?

Many servers use load balancing — DNS returns different IPs for different queries, distributing traffic across multiple servers. ping resolves DNS when it runs and uses that IP. An HTTP request made a second later may go to a different server entirely.

From name to byte: what actually matters

The full chain — DNS, IP, TCP, TLS, HTTP — was designed in independent layers. Each layer solves a specific problem and doesn't need to know how the others work. That's what allows swapping HTTP/1.1 for HTTP/3 without changing how DNS works, or using IPv6 without changing the application protocol.

For debugging network problems, knowing where the bottleneck is makes all the difference. A DNS timeout is different from a TCP connection timeout, which is different from an HTTP 503 error. When you know the problem is in DNS resolution, you won't spend half an hour adjusting connection timeouts. When you know the TLS certificate expired, you won't suspect the database.

The internet looks simple from the outside because each layer does its job well. Under the hood, it's decades of engineering that's still evolving.

Note: the editorial content ends here. What follows is a related tool recommendation.

Related tool

To see your public IP, ISP, ASN, and approximate location in real time — the same data any server sees when you make a request — IP Address Info shows everything in the browser without sending anything to an external server. Particularly useful for confirming what changes when you enable a VPN.