What Happens When You Type Google.com: DNS, TCP/IP, HTTPS & More

Ok, let’s say you are doing some search on “how DES works”. You open your browser, you type google.com(or chatgpt.com if you are new gen), and then you get your fresh and familiar google home page.

But, wait! Have you ever wondered what is really happening behind the scenes? Which processes are responsible for the displaying of this page? Let’s discuss it in this post.

First of all, what you are doing by typing google.com and pressing Enter is called a request. You are sending a request to the google servers. But for now, your browser doesn’t know yet what is the location (address) of these servers.

💡

In internet context, the ‘location’ of the computer is its IP address. Example: 98.10.98.8

Now the big question is: how your browser knows the IP address of google.com? Simple, thanks to dns resolution.

DNS resolution

DNS resolution is the process of converting a domain name (like google.com) into an IP address (like 98.10.98.8). Without this step, your browser wouldn’t know where to send your request.

Here’s how your browser actually gets that IP address:

Check its own cache – maybe it has already resolved this domain name recently.
Ask the Operating System (OS) – if the browser cache doesn’t have it, the browser relies on the OS to do the job. The OS will:
- Look into its own DNS cache.
- Check the hosts file (a small local file that can map domain names to IP addresses).
Contact the DNS resolver – if the OS still doesn’t find anything, it asks a resolver server (usually provided by your Internet Service Provider, ISP).
Resolver tries its cache – the ISP’s resolver also has a cache. If it finds the IP, great, done. If not, it has to go further…
Ask the root server – the resolver contacts one of the Internet’s root servers.

💡

The root servers don’t know the exact IP of google.com, but they do know where to find the servers that handle the Top-Level Domain (TLD), like .com for google.com.
Redirect to the TLD server – the root server points the resolver to the appropriate TLD server (in this case, the .com server).
TLD server points to the authoritative servers – the TLD server doesn’t know the final IP either, but it knows which authoritative name servers are responsible for the domain google.com.
Ask the authoritative name server – these are usually managed by the registrar or hosting provider. They contain the actual DNS records:
- A/AAAA records → mapping domain name to IPv4/IPv6 addresses
- CNAME records → aliasing one domain to another
- Other records like MX (mail), TXT, etc.

Finally, the authoritative name server returns the correct IP address for google.com. From this point, your resolver, your OS, and your browser all cache the result, so the next lookup is much faster.

Now that your browser knows the IP address of the destination server, it’s time to establish a connection. This is where TCP (Transmission Control Protocol) comes into play.

TCP connection

The Internet is built on layers. IP gives us the address (where to go), and TCP ensures a reliable connection (how to talk).

Here’s what happens next:

Browser → Server (SYN) – your browser says: “Hey server, are you there? I’d like to start a conversation.”
Server → Browser (SYN + ACK) – the server replies: “Yes, I’m here. I got your message, let’s sync up.”
Browser → Server (ACK) – your browser confirms: “Great, we’re connected!”

This little dance is called the TCP three-way handshake.

💡

The goal of the handshake is to make sure both sides agree to talk, and to set up things like sequence numbers so that data arrives in the right order and nothing gets lost.

Once this handshake is done, your browser and the server now have a reliable communication channel. Packets can flow back and forth, and if some are lost, TCP will resend them.

HTTPS/SSL (TLS)

Before we dive into HTTPS, let’s quickly talk about HTTP itself.

🔹 What does HTTP add on top of TCP?

HTTP (HyperText Transfer Protocol) sits above TCP and defines the rules and language of the Web. Without it, the browser and server wouldn’t know how to talk to each other in a structured way.

Here’s what HTTP brings:

📄 Message structure – every exchange follows a request/response format with clear methods like GET, POST, PUT, DELETE…

🌍 Client/Server model –

The client (your browser) sends a request, e.g., “Give me /index.html”.
The server replies, e.g., “200 OK + here’s the HTML content”.

🗂️ Headers – metadata that adds context to each message: content type (text/html, application/json), language, compression, authentication, caching rules, and much more.

🔒 Extensibility – HTTP was designed to be easy to extend. And the best example is HTTPS, where HTTP is combined with TLS to provide security: encryption + authentication.

🌐 Interoperability – any browser, server, or API that “speaks HTTP” can communicate, no matter the platform, operating system, or programming language.

🔹 Enter HTTPS

The problem with plain HTTP is that it’s clear text. Anyone on the same network (your ISP, a hacker on public Wi-Fi, etc.) could intercept your requests and read them.

That’s where HTTPS comes in:

It uses TLS (Transport Layer Security) to encrypt all communication.
It guarantees integrity, so data can’t be modified unnoticed.
It provides authentication, by verifying that the server really is who it claims to be (via certificates).

So HTTPS = HTTP + TLS → same rules, same structure, but now wrapped inside a secure tunnel.

💡

That’s why, when you see the little lock 🔒 in your browser’s address bar, it means your data is encrypted, authenticated, and safe from prying eyes.

Firewall

Before data really starts flowing, your packets may have to go through one or more firewalls.

A firewall acts like a security guard standing at the door. Its job is to check each packet and decide whether it should be allowed in or out.

💡

Firewalls can be on your own computer, inside your home router, at your ISP, or even on Google’s infrastructure side.

They enforce rules like:

Only allow traffic on certain ports (e.g., port 443 for HTTPS).
Block suspicious traffic.
Protect networks from attacks.

If your packets don’t pass the firewall checks, the connection just stops there. But assuming everything is fine, the packets go through and reach the destination server.

Load Balancer

Once your encrypted request reaches Google’s infrastructure, it doesn’t go straight to a single server. Google has millions of users making requests at the same time.

That’s where the Load Balancer comes in.

Think of it like a traffic cop 🚦. Its job is to:

Distribute requests across multiple servers.
Prevent overload by spreading traffic evenly.
Detect when a server is down and redirect traffic elsewhere.

💡 Without load balancers, one server could be overwhelmed while others sit idle. With them, everything runs smoothly at scale.

Web Server

After the load balancer decides which machine should handle your request, the first stop is usually a Web Server (like Nginx or Apache).

The web server’s role is to:

Accept the incoming HTTP/HTTPS request.
Handle basic things like serving static files (HTML, CSS, images, JavaScript).
Forward more complex requests to the Application Server.

💡 You can think of the web server as the receptionist of a company: it handles simple questions directly, but forwards trickier requests to the right department.

Application Server

Now we’re getting into the real business logic. The Application Server is where your request is processed according to the site’s rules.

For Google, this might involve:

Checking if you’re logged in.
Running the search algorithm.
Talking to databases or other services.

This is where programming languages and frameworks come in (Java, Python, Go, Node.js, etc.).

💡

Application servers don’t usually serve files directly. Instead, they generate dynamic content (like your personalized search results).

Database

Finally, many requests end up querying a Database.

The database stores and organizes all the persistent data a service needs:

User accounts
Search indexes
Emails (if we were talking about Gmail)
Any structured information the application relies on

💡

The database is like the giant library 📚 at the heart of the system. The application server asks it questions, and it responds with the data needed to build your page.

Here is a big picture but not complete picture of what actually happens

See more on :