How the Internet Works: From DNS Queries to TCP/IP Packets and HTTP Requests

Every day, billions of people type a website address like google.com or curiousfolk.me into their browsers. Within milliseconds, a beautiful web page appears. It feels like magic.

But under the hood, this simple action triggers a massive, highly coordinated relay race involving thousands of computers across the globe. Data is chopped into pieces, routed through undersea cables, reassembled on the fly, and translated into what you see on your screen.

Here at Curious Folk, we love peeling back the layers of technology. In this article, we’ll break down this “magic” into easy-to-understand concepts. We’ll follow the journey of a single web request from the moment you hit “Enter” to the moment the page loads.

The Great Snail Mail Analogy

Before diving into the protocols, let’s look at a physical analogy.

Imagine you live in New York, and you want to read a rare 1000-page book stored in a library in San Francisco. However, the library is only allowed to send information through standard envelopes, and each envelope can only hold one page at a time.

Here is how you would get the book:

1. Find the Address: You look up the library’s physical address in a directory (like a phonebook).
2. Establish the Agreement: You call the library to confirm they are open and willing to send the book. They say yes, and you acknowledge that you are ready to receive it.
3. Chop and Ship: The librarian takes the book, tears it into 1000 individual pages, puts each page into an envelope, writes your address on it, and numbers them (e.g., “Page 45 of 1000”).
4. The Post Office Route: The envelopes are handed to the postal service. Some envelopes go by truck through Chicago; others fly by plane through Denver. They take different routes and might arrive out of order.
5. Reassembly: As you receive the envelopes, you arrange them by page number. If Page 45 is missing, you send a letter back saying, “I didn’t get Page 45, please send it again.”
6. Read: Once you have all 1000 pages, you bind them together and read the book.

This is exactly how the internet works! Let’s map these steps to actual computer technologies.

Step 1: DNS Resolution (Finding the Address)

When you type https://curiousfolk.me into your browser, the computer doesn’t know where curiousfolk.me is. Computers only communicate using IP Addresses (e.g., 192.0.2.1 or 2606:4700:3030::ac43:2a7d).

The Domain Name System (DNS) is the phonebook of the internet. It translates human-friendly domain names into machine-friendly IP addresses.

Here is the step-by-step query flow:

[ Your Browser ] ---> 1. Check local cache (Browser, OS, Router)
       |
       +--(Cache Miss)--> [ Resolving Name Server (ISP) ]
                                  |
                                  +--> 2. Query Root Server (.) -> Returns TLD Server (.me)
                                  +--> 3. Query TLD Server (.me) -> Returns Authoritative Server
                                  +--> 4. Query Authoritative Server -> Returns IP: 192.0.2.1

1. Local Cache: Your browser first checks its own cache, then the OS cache, and then your home router’s cache to see if you visited this site recently.
2. Recursive DNS Resolver: If not found, your request is sent to your Internet Service Provider’s (ISP) DNS resolver.
3. Root Nameserver: The resolver queries a Root Nameserver (representing the dot . at the end of every domain). The root server says, “I don’t know the IP, but I know who handles .me domains.” and returns the address of the TLD (Top-Level Domain) server.
4. TLD Nameserver: The resolver queries the .me TLD server. The TLD server responds, “I don’t know the IP, but I know the authoritative nameserver for curiousfolk.me.”
5. Authoritative Nameserver: The resolver queries the authoritative nameserver (often hosted by DNS providers like Cloudflare, GoDaddy, etc.). It responds with the final IP address: 192.0.2.1.
6. Return to Browser: The resolver gives the IP address back to your browser and caches it for future use.

Step 2: The TCP Handshake (Agreeing to Speak)

Now that your browser has the IP address, it must establish a connection with the web server. For web browsing, we use TCP (Transmission Control Protocol).

TCP is a connection-oriented protocol, meaning it guarantees that all data will arrive safely and in order. To set up this connection, it performs a 3-Way Handshake:

  Client (Browser)                           Web Server
  +--------------+                           +--------+
  |              | ---- 1. SYN (Synchronize) -> |        |
  |              | <--- 2. SYN-ACK ---------- |        |
  |              | ---- 3. ACK (Acknowledge) -> |        |
  +--------------+                           +--------+

1. SYN (Synchronize): The client sends a packet containing a random sequence number X to the server, saying “I want to open a connection.”
2. SYN-ACK: The server receives it and responds with its own sequence number Y and an acknowledgment number X+1, saying “I hear you! I’m ready to connect too.”
3. ACK (Acknowledge): The client responds with Y+1, saying “Got it! Let’s start talking.”

Once this is complete, a virtual pipe is opened between the client and server.

Step 3: IP Routing & Packets (Chop and Ship)

Web servers don’t send pages as one massive file. If a single byte was corrupted during transmission, the entire file would have to be resent. Instead, data is split into small pieces called Packets (usually about 1500 bytes each).

Each packet has:

• A Header: Contains metadata like Source IP, Destination IP, sequence number, and protocol.
• The Payload: The actual fraction of the file being sent.

+-------------------------------------------------------------+
|                     IP Header (20 Bytes)                    |
|  Source: 192.0.2.1 | Destination: 203.0.113.5 | Length: 1500 |
+-------------------------------------------------------------+
|                     TCP Header (20 Bytes)                   |
|  Source Port: 443  | Destination Port: 56213  | Seq No: 1205|
+-------------------------------------------------------------+
|                           Payload                           |
|       "...<html><body><h1>Curious Folk</h1>..."              |
+-------------------------------------------------------------+

These packets are sent out into the wild. They travel across routers and switches. Each router reads the destination IP and forwards the packet to the next closest router (using routing tables). Packets of the same web page might take completely different paths, detour around congestion, and arrive at your computer out of order or damaged.

TCP at the receiving end is responsible for:

• Reordering packets by their sequence numbers.
• Detecting missing packets and requesting retransmission.
• Checking for data corruption using checksums.

Step 4: HTTP/HTTPS (The Language / Payload)

Once the TCP connection is established, the browser sends an HTTP Request asking for the page content.

Here is a raw example of what an HTTP GET Request looks like:

GET /index.html HTTP/1.1
Host: curiousfolk.me
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9

When the server receives this, it processes it and sends back an HTTP Response with the page content (HTML, CSS, JS):

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 4520
Server: Apache/2.4.41 (Ubuntu)

<!DOCTYPE html>
<html>
<head>
    <title>Curious Folk</title>
</head>
<body>
    <h1>Welcome to the Cyber-Blog</h1>
</body>
</html>

What is the “S” in HTTPS?

HTTP transmits data in plain text. Anyone tapping into your network (like on public coffee shop Wi-Fi) could read your passwords or data. HTTPS uses TLS/SSL to encrypt the connection. During the handshake, the server shares a public certificate. The browser verifies this certificate and generates an encryption key that only the client and server can read, keeping the data completely secure.

Hands-On: Code Examples

Let’s look at how computers actually run this in code using Node.js.

1. Basic TCP Socket Server & Client

This is a low-level example of TCP communication (Step 2 and 3).

Server Code (server.js):

const net = require('net');

const server = net.createServer((socket) => {
    console.log('Client connected!');
    
    // Listen for data from client
    socket.on('data', (data) => {
        console.log('Received from client:', data.toString());
        // Send response back
        socket.write('HELLO CLIENT! TCP CONNECTION SECURED.\r\n');
    });

    socket.on('end', () => {
        console.log('Client disconnected.');
    });
});

server.listen(8080, () => {
    console.log('TCP Server running on port 8080...');
});

Client Code (client.js):

const net = require('net');

const client = net.createConnection({ port: 8080 }, () => {
    console.log('Connected to server via TCP!');
    // Send message to server
    client.write('HELLO SERVER! Can I get index.html?');
});

client.on('data', (data) => {
    console.log('Response from server:', data.toString());
    client.end(); // Close connection
});

Summary Journey: The Millisecond Sprint

To wrap it up, here is what happens when you query a site:

The next time you load a website, think of the trillions of transistors, routers, and light impulses firing across the globe in a fraction of a second just to show you a page. The internet is truly one of humanity’s greatest collaborative achievements! 🚀