WHAT HAPPENS WHEN YOU TYPE GOOGLE.COM IN YOUR BROWSER AND PRESS ENTER?

Introduction

Have you ever wondered what happens when you type "https://www.google.com" in your browser and press enter? This simple action initiates a complex sequence of events that results in the display of the Google search engine home page. Let's break down the process step by step.

To start off, let me provide you with definitions of three key terms that will be used throughout this article:

Server: Refers to a computer system or program that provides functionality to other devices. This can be either hardware or software. In this article, the term "server(s)" specifically refers to the computer system(s) that host the website being accessed.

Client: Refers to a computer system or program that can access services and functionalities provided by a server. This is commonly a personal device, such as a laptop or smartphone, that is used to access the internet or other online services. In this article, the term "client" refers specifically to the web browser being used to access the website.

Protocol: Refers to a set of rules or methods used for transmitting data between two devices. The Open System Interconnections (OSI) model is a conceptual model used to describe telecommunications between computers, and it includes many different protocols.

STEP 0 — URL PARSING

In order for web browsers to function properly, they need to know the web page that corresponds to a given string of text. This string of text, known as the Uniform Resource Locator (URL), is parsed by the browser in a process called URL parsing.

Web browsers operate on Internet Protocol (IP) addresses, which are like addresses for servers. However, instead of using IP addresses directly, we use domain names, which are easier for humans to remember. The Domain Name System (DNS) is responsible for translating domain names into IP addresses.

Without DNS, web browsing would be far less efficient and convenient. However, domain names alone are useless to a web browser. In order to access a website, the browser must resolve the domain name into its corresponding IP address. This process is essential for the browser to successfully load the website.

When given an unfamiliar item, the best way to describe it is by breaking it down into smaller, identifiable features. Web browsers operate in a similar manner. Upon receiving a string of text, such as https://www.google.com, the browser, let's say Firefox for this article, breaks it up into four parts:

Protocol: https, the data transfer method to be used between the client and server.

Hostname: www.google.com, the domain name that corresponds to the IP address of the server.

Port: the port where the request will be sent. In this case, the port is 443, which is implied by the HTTPS protocol.

Path-and-file-name: the name of the file requested and its location in the server's directory. It is left empty in our example URL, indicating that we are querying the server at the root /.

The browser then checks the hostname for any non-ASCII characters and uses Punycode to encode the URL into a functional string if necessary. Next, it checks its cache for recent hostnames that it has already resolved to an IP address. If it finds a match, it pulls out the IP directly. If not, it searches the operating system's cache before undergoing the DNS resolution process.

In summary, web browsers rely on a systematic approach to parse URLs and resolve hostnames into IP addresses. This process helps browsers efficiently retrieve and display web pages for users.

STEP 1 — DNS LOOKUP

The first step in the process of accessing a website is known as DNS lookup. If the web browser, like Firefox, cannot find the hostname in its cache, it sends it to a resolver server, usually provided by the Internet Service Provider. The resolver then begins the complex process of converting the hostname into its corresponding IP address through the Domain Name System.

While the details of hostname-IP DNS resolution can be complex, there are resources available, such as dnsimple's comic "How DNS Works," that explain it in an approachable and entertaining way. Essentially, the resolver contacts both the top-level domain server (such as .com) and the domain registrar to obtain the IP address associated with the hostname. Once the process is complete, Firefox has the IP address corresponding to the website, which we will refer to as 88.88.88.88 for the purpose of this example (note that this is not the actual IP of the website).

Updating our flowchart:

STEP 2 — TCP/IP

In Step 2, once the IP address associated with the website has been resolved, the web browser is ready to communicate with the corresponding server. The communication occurs over Transmission Control Protocol/Internet Protocol (TCP/IP), which is the standard protocol for web infrastructure and the OSI model.

TCP is responsible for establishing the connection between the client and server, ensuring reliable packet delivery, even if it takes more time. In contrast, User Datagram Package (UDP) is faster but less reliable, making it more suitable for streaming services where instant content takes priority. However, TCP is used almost everywhere else.

IP addresses are unique to machines and represent the network addressing and routing that guide the destination points of TCP. In our example, Firefox communicates with the server hosting www.google.com over TCP, prioritizing reliability over speed for this static website.

STEP 3 — SSL

After resolving the IP address of the server it wants to communicate with and the method of communication, the browser undergoes a security check before initiating the conversation. The first message sent by Firefox to the resolved IP address of the website includes its Transport Layer Security (TLS) version, along with a list of supported cipher algorithms and compression methods.

TLS is a symmetric cryptography encryption method used to keep communicated data private, authenticated, and reliable. When the server receives this message, it chooses its preferred TLS algorithm and method and responds with a certificate that includes the server's TLS public key.

Using this public key, the browser encrypts a pre-master key that is sent back to the server. If the public key is authentic, the server can decrypt the pre-master key with its TLS private key. This successful decryption confirms that the browser and server have established a trusted connection and a symmetric method of sending messages back and forth. This process is called the TLS handshake and is responsible for the green lock displayed in the browser whenever a website is connected through HTTPS.

Although the TLS handshake process is complex, dnsimple offers a fantastic, clear comic explanation of this protocol on their website, how https.works.

STEP 4 — HTTPS

Although TLS is essential, let's not forget the significance of the "HTTP" in HTTPS. It stands for HyperText Transfer Protocol and is a stateless, asymmetric client-server request-response protocol that uses TCP/IP. HTTP was initially created by the inventor of the internet, Tim Berners-Lee, and is still the most widely used internet communication protocol. The most recent version of HTTP is HTTP/1.1, which is maintained by the World-wide Web Consortium (W3C).

While TCP/IP determines the method of communication, HTTP defines how computers interact with each other. After the TLS handshake is completed, Firefox sends a HTTP request message to the server. The request message follows a strict format that includes the request line, which specifies the type of request the browser makes to the server. There are several types of request messages, with GET being the type used to acquire a web resource (web page) from a server. The header section of HTTP request messages allows the browser to specify various request details, such as whether the server should store cookies. The request body is optional and mostly irrelevant to request messages.

In our example, Firefox sends a TLS-encrypted HTTP GET request to the resolved IP of www.google.com to retrieve the web page at the root of the host server. We'll revisit HTTP later, but for now, it's important to understand that the "HTTP" in "HTTPS" plays a critical role in web communication.

STEP 5 — LOAD BALANCER

In the previous steps, we've been discussing the communication between our browser and the server hosting the desired web page. However, we haven't yet talked about the server itself. This is because up until now, we've actually been interacting with an intermediary called a load balancer.

The significance of load balancing lies in the fact that there are over five billion internet users today, and the number of HTTP GET requests sent to a website can be enormous. Even for huge websites like Google or Amazon, a single computer cannot handle such heavy traffic without slowing down. That's why established websites divide traffic across multiple servers configured to handle requests identically, making the process much more efficient.

A load balancer is responsible for splitting up this traffic. It can be a software configured on the same server as the web content, or it can be on a separate server. An example of free load balancer software is HAProxy. Load balancing algorithms divide HTTP request traffic into various types, each with their own advantages and disadvantages. For instance, round-robin load balancing sends requests to servers in turn according to a queue, while least connections sends requests to the server currently handling the least number of connections.

In our example, the IP address resolved for www.google.com was actually the IP address of the load balancer server. After completing the TLS handshake, Firefox designated it as the TLS termination proxy. Similar to a post office, the server, which we'll assume has a round-robin algorithm on HAProxy, received our HTTP GET request, took the request, pulled up the IP address of the next web server in its queue, and sent it off that way.

However, if a website is configured with just one load balancer, and that load balancer server fails, the entire site would be inaccessible, making it a single point of failure. A stable website should have multiple load balancers set up as a transparent cluster, where each load balancer knows the status of its companions, and any one can handle a greater share of requests in the case that another goes down. Here's an updated graphic to illustrate this more stable load balancer cluster:

STEP 6 — FIREWALL

As we approach the final steps of retrieving our desired web page, there is one last crucial security check that our GET request must pass through before reaching the host server. This is where the firewall comes in.

During the TLS handshake, our browser and the load balancer server agreed upon how to encrypt messages exchanged between them. While TLS serves to provide privacy, integrity, and identification, it fails to ensure honesty.

To prevent malicious traffic from getting through, firewalls act as a filter for all incoming and outgoing traffic to and from a server. They can be implemented through hardware, software, or a combination of both, and use a variety of methods such as packet filters, application gateways, circuit-level gateways, and proxy servers to identify and block malicious data.

Firewalls are relatively easy to install and can be configured at any point where data is received, including both the load balancer and host servers. An example of a freely available firewall for Linux systems is Uncomplicated Firewall (UFW).

In our example, our GET request has already passed through a firewall installed on the load balancer, and will next pass through another firewall on whichever host server it is distributed to.

STEP 7 — Host Server

Congratulations, you have made it to the final step in the process of hosting your website! The host server is a crucial part of your web stack and consists of multiple components configured using the LAMP model.

The LAMP model comprises of the following components:

Linux (L) - The operating system on which the host server runs. For our example, we will use Ubuntu, but you can choose your preferred distribution.

Apache (A) - The HTTP web server, which handles HTTP request/response messages and delivers the static web page. Apache is the most commonly used HTTP web server, but others like Nginx are also popular.

MySQL - The database server, which is SQL-based and stores information such as user accounts. MySQL is a widely used and free database software.

PHP/Python (P) - The application server, which handles dynamic content crucial to modern websites. PHP and Python are two high-level languages that can handle dynamic content, but other languages like JavaScript and Ruby are also supported.

Each component of the LAMP web stack can be configured separately or on the same server. In the traditional setup, each level of the stack runs on a virtual machine, but today, it's common to separate each part into individual containers, such as Docker.

The LAMP stack works together on a common codebase to deliver a web page. When a GET request is received by the web server, it pulls up the file configured at the given location. If the file contains dynamic content, the application server runs the corresponding Python scripts, which are inserted into the web page. If the dynamic content involves stored data, the Python scripts query the database server.

Remember that a given website will most reliably be configured with multiple servers to handle traffic efficiently and prevent a single point of failure. Keep in mind that data is only received by an individual server after it has passed its firewall.

For our example, we will configure our flowchart with three host servers, each running an Ubuntu Linux distribution utilizing three containers - one each for an Apache web, Python app, and MySQL database server. This will be an active-active setup, where all servers will be running and handling requests simultaneously. The database container on the first host server will be the master, while the others will be replicants.

ASIDE — MONITORING

In addition to the web infrastructure setup we've discussed, it's important to note the role of monitoring software in ensuring the smooth operation of a website. Websites are delicate and require constant attention and fine-tuning based on metrics such as traffic volume, request processing speed, and server status. Monitoring software is responsible for collecting and analyzing these metrics to help identify and resolve issues before they escalate.

One example of such software is SumoLogic, which works by installing agents on each server in the web infrastructure (including load balancers and host servers) and collecting the data on a separate cloud server. By configuring SumoLogic to monitor our example servers, we can ensure that they are properly maintained and any issues are quickly identified and addressed.

8. PAGE RENDERING

After a long journey, the requested web page has finally reached our web browser. The host server sent the HTML file configured at the root of www.google.com back to the browser in an HTTP response message. The initial status line of this message includes a status code indicating the success of the request, with 200 indicating a successful retrieval and delivery of the web page. Other common status codes include 301 for page redirection and 404 for page not found.

The response header provides information about the delivered page, such as its type and size. In the response message body, the host server delivers the entire HTML code that the browser has been searching for. The browser uses its HTML and CSS engines to parse the code, break it down into its Document Object Model, and render the page. Any JavaScript scripts written in the file are executed. Ultimately, the web browser displays the Holberton School website homepage in all its glory, a realization of our dream.

Conclusion

In conclusion, here's a summary of the process described:

The browser parses the URL into protocol, hostname, port, and location.

The browser checks if the hostname is cached, if not, it is resolved through the DNS.

The browser establishes an encrypted connection with the load balancer via TCP/IP.

The browser sends a GET request to the load balancer for the file at the root of the website.

The load balancer passes the GET request through its firewall and distributes it to the next available host server based on its load balancing algorithm.

The host server retrieves the file from its root directory and serves its content dynamically through the application and database servers.

The browser receives the HTTP response message containing the file content and renders the HTML page.