What really happens when you type google.com and press Enter?

Hi everyone, my name is Clément and I am currently a full-stack developer student at the Holberton School in Lille. Today, we will try to answer a question that I never asked myself before discovering the power and complexity of the web:

"What Really Happens When You Type google.com and Press Enter?"

A classic question you definitely don’t want to face during a technical interview!

You need to search for something, and to avoid the misery of typing yahoo.com, you type "google.com" instead, hit Enter. The page appears, it’s so basic and familiar, almost unsurprising… But behind this simple action lies a cascade of complex processes. And to understand what’s really happening, we need to revisit the fundamentals of network communication.

Why is this important?

When you enter a URL and press "Enter", you activate a process that spans multiple layers of the OSI (Open Systems Interconnection) model and the TCP/IP model. These two models provide an abstract and organized view of data exchange on the Internet. The OSI model, though idealized, often serves as a theoretical reference, while the more practical TCP/IP model is used to structure modern Internet protocols.

The OSI model consists of 7 layers, ranging from the physical layer (where data is converted into electrical signals) to the application layer (where interactions with services like HTTP take place). Each layer plays a specific role in data transmission.

1. DNS (Domain Name System)

The first challenge to overcome is simple: machines don’t understand domain names. They communicate through IP addresses, which are numeric strings like 172.217.16.206 (Google in this case). When you type "google.com", DNS steps in to translate this name into an IP address. It’s like looking up a school in a directory when you only have the name, not the address. But DNS is far more complex than it seems. It’s a globally distributed infrastructure, and before your DNS request finds its way, several steps are necessary, each involving specific servers:

• Recursive resolvers (like those from your ISP), which are the first to receive the request. They check their caches: if Google’s IP is there, the response is instant.
• Root servers: If nothing is cached, the request is sent to one of the 13 root servers, which direct your query to the top-level domain (TLD) servers, like ".com".
• TLD servers: Finally, they guide you to Google's authoritative servers, which will return the requested IP. This system is designed to be fast and efficient through caching at every step. A key mechanism here is the TTL (Time to Live), which determines how long DNS information remains in cache before being refreshed. This TTL reduces server load but can increase latency if caches have expired.

?? For more:

Explanation of how DNS works.

2. TCP/IP: The journey begins

Once the IP address is obtained, it’s time to prepare for data transport. This is where TCP/IP comes into play. TCP (Transmission Control Protocol) and IP (Internet Protocol) work together to ensure that data reaches its destination. First, a connection between your computer and Google’s server needs to be established. This is done through what’s known as the TCP three-way handshake:

1. Your computer sends a TCP segment with a "SYN" (synchronize) flag.
2. Google’s server responds with a "SYN-ACK" (synchronize-acknowledge).
3. Your computer sends an "ACK" (acknowledge). Next, the data is broken into fragments called packets, each containing a header with information about its order and destination. These packets pass through different network layers (physical, data link, network, etc.) and are routed optimally to Google’s IP address. This process includes several optimizations such as congestion control (with algorithms like Cubic or BBR) to prevent network saturation. Mechanisms like fast retransmission and Selective Acknowledgment (SACK) also improve reliability by handling packet loss efficiently.

?? For more:

How TCP/IP works.

3. Firewall: The mighty security guard

Before reaching Google’s servers, your request must pass through several firewalls. These are crucial for ensuring that your request doesn’t contain anything malicious. They can block suspicious packets, protect against attacks (like DDoS or spoofing), and enforce security policies. Firewalls also check that the data follows security protocols like HTTPS and ensure that incoming and outgoing packets are legitimate.

4. HTTPS/SSL: Security is not optional!

You’ve probably noticed the little padlock next to the URL, indicating that your connection is secure. This involves SSL/TLS (Secure Sockets Layer / Transport Layer Security), which ensures that your data exchanges are encrypted and protected.

During the handshake phase, SSL negotiation is crucial for establishing a secure session. This process includes the exchange of certificates and encryption keys between your browser and Google’s server. Thanks to this, even if a hacker intercepts the packets, they won’t be able to decrypt them without the private key. A major improvement here is TLS 1.3, which reduces the number of handshake rounds, boosting performance while enhancing security with algorithms like AES-GCM or ChaCha20-Poly1305.

?? For more:

Understanding TLS 1.3.

5. Load Balancer: Distributing tasks (Divide and conquer)

Once your secure request reaches Google, it’s not handled by just one server. Google, like many large infrastructures, has hundreds of thousands of servers worldwide. A load balancer ensures that requests are distributed efficiently across these servers to:

1. Prevent overloading a single server, which could slow down or crash.
2. Optimize performance by distributing the load based on geographic proximity or server availability.
3. Ensure high availability by rerouting requests if a server fails.

A load balancer can operate in several ways, the most common being:

• Round Robin: Requests are distributed evenly across available servers.
• Least Connections: Traffic is directed to the server with the fewest active connections.
• IP Hash: Requests from the same IP address are always routed to the same server for consistency (often used for persistent sessions). For massively distributed systems like Google, specialized load balancers like Google Cloud Load Balancer can handle millions of requests simultaneously, leveraging infrastructure spread across multiple geographic regions.

?? For more:

How Load Balancing Works.

6. Web Server: The Great Page Maker...

Once the request is routed through the load balancer, it finally reaches a web server. The web server’s job is to process the HTTP(S) request and return the requested web page. Popular web servers like Apache, Nginx, or Google Web Server (GWS) are built to handle millions of simultaneous requests. These servers can respond to static requests (like images or plain text), but most interactions require dynamic pages, generated on the fly.

To handle these dynamic pages, web servers are often paired with application servers, which process complex requests before generating a response. Languages like Python, Java, or PHP are often used here to execute server-side code, depending on the data requested by the user.

?? For more:

How Web Servers Work.

7. Application Server: The brains of the bunch.

When you visit Google, the page you see isn’t the same for everyone. For instance, search results may be personalized based on your history or habits. This personalization is handled by the application server, which goes beyond merely serving static files. The application server relies on business logic to understand your request, access various databases, and assemble the page based on this information. For example, it may:

• Run code to personalize search results.
• Communicate with external services like APIs for additional information.
• Manage user sessions and enforce access and security rules.

Popular application servers include Django (for Python), Spring (for Java), and Node.js (for JavaScript). They handle complex requests, as well as authentication, session management, and many other critical tasks.

?? For more:

What Is an Application Server?.

8. Database: Google’s memory

Behind every application server is often a database storing all the necessary information to build a personalized web page. In Google’s case, this includes data like:

• Your search history.
• Your user settings.
• The index of web pages for search results.

Google uses massively distributed and sophisticated database systems like Bigtable and Spanner. These databases are designed to handle petabytes of data and respond within milliseconds. Querying a database might seem trivial, but it’s crucial to the performance of any web application. Modern databases are optimized to minimize latency using techniques like sharding (data fragmentation) and replication (copying data across multiple servers to avoid single points of failure).

?? For more:

Introduction to Google’s Bigtable Database.

9. Back to the user!

Once the server generates the requested page, it’s broken into TCP/IP packets, which retrace their path back to your browser. This return journey also involves routers, firewalls, and sometimes intermediate caches to speed things up.

When all packets arrive, your browser reassembles them to display the page. At this point, further optimizations like the Critical Rendering Path (CRP) and lazy loading are used to display essential page elements as quickly as possible, before loading secondary elements. Your browser’s rendering engine (like Blink for Chrome or Gecko for Firefox) is responsible for this. These engines follow a defined series of steps, from parsing HTML and CSS to building the DOM and rendering the final elements on screen.

After this long journey, Google’s homepage finally appears! How long do you think it actually took?

Now that you have read this fabulous article with the greatest attention (I hope), I feel you are ready to decipher this diagram:

Conclusion

In reality, when you type "google.com" and press "Enter", a multitude of processes are set in motion to turn this simple action into a visual response in milliseconds.

From DNS to application servers, through HTTPS security and rendering engines, every step is optimized to maximize speed, security, and efficiency. And all of this happens without you even noticing a delay. If you're considering a career as a network engineer or, like me, find the complexity and efficiency of web infrastructure fascinating, feel free to deepen your understanding with this list of sources:

• Explanation of how DNS works.
• How TCP/IP works.
• Understanding TLS 1.3.
• How Load Balancing Works.
• How Web Servers Work.
• What Is an Application Server?.
• Introduction to Google’s Bigtable Database.

If you have any relevant suggestions or comments about this presentation, feel free to send me a message!