The Internet Unveiled: What Happens When You Type a URL?

Many people think that when you type google.com into your browser, it just “talks to Google” and brings up the page.

But what actually happens is a massive journey through countless protocols, layers, and encapsulations.

Step 1: DNS Resolution - Finding the Address

You type google.com and hit Enter. Your browser needs an IP Address, because the internet doesn’t understand google.com; it understands 142.250.x.x.

The first step is DNS Resolution:

1. The browser checks its own DNS cache.
2. If not found, it checks the Operating System’s DNS cache.
3. If still not found, the request goes to a DNS Resolver (often provided by your ISP, or a public one like Google DNS or Cloudflare DNS).

Here’s where it gets complex: the DNS isn’t just one server. The resolver queries a hierarchy:

• Root DNS Servers
• TLD Servers (for .com)
• Authoritative DNS Server (for google.com)

Finally, an IP address is returned. But it’s rarely a static IP. Google uses CDNs, Load Balancers, and Geo-Routing, so someone in Egypt might get a different IP than someone in Germany, all to direct you to the closest and fastest server.

graph TD
    A[User types google.com] --> B{Browser DNS Cache?};
    B -- No --> C{OS DNS Cache?};
    C -- No --> D[DNS Resolver];
    D --> E[Root DNS Servers];
    E --> F[TLD Servers (.com)];
    F --> G[Authoritative DNS Server (google.com)];
    G --> H[IP Address Returned];

Step 2: TCP Handshake - Making the Connection

Now that we have the IP address, we need to establish a connection. This is where the TCP Handshake begins.

1. Your browser sends a packet with a SYN flag (Synchronize) – “I want to start a connection.”
2. The server responds with SYN-ACK (Synchronize-Acknowledge) – “Okay, I’m ready.”
3. Your browser responds with ACK (Acknowledge) – “Let’s go!”

Now, a reliable TCP Connection is established.

Step 3: TLS Handshake - Securing the Connection

If the website uses HTTPS (which google.com does), a TLS Handshake occurs after the TCP handshake. This is for encryption, verifying certificates, and establishing session keys.

During this process, the browser verifies:

• The server’s certificate is valid.
• The domain matches the certificate.
• The Certificate Authority is trusted.

A Session Key is then generated, which will be used to encrypt all subsequent communication.

Step 4: HTTP Request & Encapsulation - The Data Journey

Now, the browser wants to send an HTTP Request (e.g., GET /). This is where the magic of Encapsulation happens, a core concept of networking layers. Each layer takes the data from the layer above it and wraps it with its own header information.

1. Application Layer (HTTP): The browser creates the HTTP Request (your actual data).
2. Transport Layer (TCP): TCP adds a TCP Header (source/destination ports, sequence numbers). [TCP Header][HTTP Data]
3. Internet Layer (IP): IP adds an IP Header (source/destination IP addresses). [IP Header][TCP Header][HTTP Data]
4. Link Layer (Ethernet/Wi-Fi): The physical layer adds a Frame Header and Trailer (MAC addresses, error checking). [Frame Header][IP Header][TCP Header][HTTP Data][Frame Trailer]

This “frame” is then converted into electrical signals or radio waves and begins its journey: Your Device → Router → ISP → Many Routers → Google Network.

Each router along the way only looks at the IP Header to decide where to forward the packet.

graph TD
    A[HTTP Request (Data)] --> B(TCP Header);
    B --> C(IP Header);
    C --> D(Ethernet Frame);
    D --> E[Physical Transmission];

Step 5: Decapsulation & Server Processing

When the frame reaches Google’s servers, the reverse process, Decapsulation, occurs. Each layer strips off its header, until the server finally receives the original HTTP Request (GET /).

The server then:

• Processes the request.
• Fetches the page content.
• Executes backend logic (database queries, caching, authentication, APIs).
• Generates an HTTP Response (HTML, CSS, JS, cookies, headers).

Step 6: Response Journey & Rendering

The HTTP Response then undergoes the same encapsulation process and travels back to your browser. Your browser decapsulates it, and finally begins Rendering:

• Building the DOM (Document Object Model).
• Loading CSS.
• Executing JavaScript.
• Painting the page.

And then, you see google.com.

Naima’s Note: This entire, incredibly complex dance happens in milliseconds. For AI services, where every millisecond of latency can impact user experience or the efficiency of model inference, understanding these underlying network mechanics is paramount. Whether you’re optimizing a distributed AI training job or deploying a real-time AI inference API, the principles of efficient DNS, reliable TCP, and secure TLS are foundational. At 10xdev.blog, we emphasize that AI doesn’t abstract away the need for deep systems knowledge; it makes it even more critical.

Beyond the Basics: The Hidden Infrastructure

And all of the above is still a simplification! Behind the scenes, there’s even more:

• CDNs (Content Delivery Networks): To serve content from the closest geographical server.
• Load Balancers: Distributing millions of requests across thousands of servers.
• Reverse Proxies (NGINX, Cloudflare): Sitting in front of the actual servers for security and performance.
• Caching Layers: To avoid re-executing operations.
• WAFs (Web Application Firewalls): Protecting against attacks.
• Rate Limiting: Preventing spam and abuse.
• Monitoring & Telemetry: Observing performance and errors in real-time.
• HTTP/2 and HTTP/3: Modern protocols that significantly improve performance over older HTTP.

Often, you’re not even connecting directly to the “real” server, but an Edge Server that then communicates internally with the rest of the infrastructure.

All of this happens, usually, in less than a second. It makes you realize that simply opening a website involves an incredible symphony of technology.