Google is everywhere, and chances are you have used it at least once in your life to search for things like the listing of famous people in the world, or perhaps you’ve used Google to search for the cheapest universities in the US. My point is we’ve all used the Google search engine, be it on our phones, tablets, or desktop devices.
Have you ever pondered over what happens when you type ‘google.com’ in your web browser and hit the enter key on your keyboard? It would be an oversimplification to answer this question by saying that your web browser returns the Google home page, and that’s it. There’s a lot more going on than you could think. In fact, the request is so fast that we barely notice what’s going on under the hood.
In this post, I’m going to dig under that hood and unravel every piece of the underlying technology that is impacted from when you make your request (i.e type in google.com and hit enter on your keyboard) to when you receive a response (i.e access the google home page). Hopefully, after this post, you will begin to appreciate how the Internet works.
What happens when you type a URL into a web browser?
It all begins when you tap or click open a web browser. I’m pretty sure you are familiar with a web browser. If not, a web browser is basically any application we use to access the internet. Popular web browsers are Google Chrome, Firefox, Opera, Safari, and Microsoft Edge.
Let’s say you want to access google.com, and so you open up a web browser (Microsoft Edge) and type ‘google.com’, and hit enter. Wait, not so fast. Let’s consider what you just did: You opened the web browser and typed ‘google.com’. Generally, the web browser presented a URL address bar and you typed a domain name. URL stands for Uniform Resource Locator while a domain name is what is used to locate resources on the internet. We’ll talk more about these two later, but for now, let’s say that’s what you’ve done.
When you hit enter on the keyboard after typing ‘google.com’, the browser receives that as a request, and starts to find the information on the internet.
The first place the browser checks is in its own cache. The browser cache is a file that stores a list of searches you’ve done in the past. If you have ever visited the ‘google.com’ web page in the past, the browser is going to remember your request by caching it for easy access in the future. Otherwise, it is going to forward your request to the next level, which is by checking a local file on your computer that’s called a host file.
The host file is available on every computer and contains a list of domains and IP addresses mapped to those domains. If you are on a Windows system now, try to see what I am talking about c:\Windows\System32\Drivers\etc\. Since the host file doesn’t contain all possible domains existing on the internet, chances are the host file might not have the answer to your request. So, the browser forwards your request to the next level, which is the DNS.
As the next lookup, the DNS server reserves information about all domains on the internet. As a matter of fact, DNS stands for Domain Name System so it’s pretty obvious your browser is going to find some information about your request (‘google.com’) here. The DNS server can be compared to a phonebook. A phone literally stores contact information. It does this by assigning a name (e.g John Smith) to a number (e.g 000–000–0000). So whenever you want to call John Smith, that’s the number you’re going to call. Similarly, the DNS server uniquely maps domain names to IP addresses.
At this point, things are about to get interesting as your request (‘google.com’) is about to change into something else. Since we humans are not really good at remembering numbers, and computers communicate using numbers, the DNS server exists to bridge that gap. To explain this further, let’s say the resource you are looking for by typing ‘google.com’ is available on the internet, on a computer that’s far far away (might be closer to you, depending on your location). We can’t literally tell where exactly on earth this computer is physically located, but what is possible is it can be reached via its IP address. This IP address is unique and is assigned only to this computer. Now we clearly see what the DNS server is doing. The DNS server has a record of the domain name ‘google.com’ mapped to the IP address of the server that has the resource you are looking for.
So when your web browser looks up this information from the DNS server, the DNS server gives a positive response. It says, “I see that you are looking for the IP address of ‘google.com’. Here is it.” The DNS server sends back the exact IP address of the server to which ‘google.com’ points, which is 8.8.8.8.
Your web browser now knows the IP address of the server that has the resource that you want to access. Now what? Some kind of interesting connection is about to be established between your computer and the server that has the resource your web browser is requesting. This connection is called a TCP/IP connection. It cannot be established without your browser knowing the IP of the server that has the resource.
TCP/IP is a Transmission Control Protocol and it’s established over an Internet Protocol. I get it. Things are getting a bit technical here. Hang in there. Later, I will dissect these two protocols for clear understanding. For now, let’s just say, this is the kind of connection that’s established between your computer and the computer that has the resource you’re looking for.
Bravo, a connection has been established, but there are some restrictions that might be on both ends of the connection. For instance, your computer might block the request to this server if it is behind a firewall, and if the firewall rules don’t allow connection to 8.8.8.8, which is the IP for the server that ‘google.com’ points to. On the other hand, the server might block your request if it’s also behind a firewall that doesn’t allow requests from your computer. So, it’s a two-way thing. This is really important because it prevents unauthorized access to a server from a request that could be harmful. The internet is full of theft, and I don’t need to over-emphasize that.
So let’s assume that the firewalls on both ends allow for such a connection. So, what next? Your browser now sends the request for a webpage, but that has to be done over a secure connection. That’s when SSL / TLS comes into the picture. SSL, which stands for Secure Socket Layer, is responsible to encrypt the data between your computer and the server. This protocol is very cognizant of what could go wrong here, and so it puts in a set of rules to secure the data that’s been transmitted.
The result of the SSL / TLS is that little padlock you see in the URL bar or the “https” at the beginning of the domain ‘google.com’ when your result is returned to the web browser. It would literally look like this: “https://www.google.com”. So when you see it like this, it’s because of that extra layer of security that SSL provides.
We’ve come a long way now, and there’s a lot you’ve already understood. If you didn’t, and if you are tech-savvy like me, you should take some time to go over it. It would greatly help.
We all know that the domain ‘google.com’ belongs to a company called Google. Google is a tech giant, and by that I mean they are on top of their game. What do I mean? Let me explain.
While you were typing ‘google.com’ in your Microsoft Edge web browser, let’s assume there were also a hundred and ninety-nine thousand (199,000) other people typing the same ‘google.com’ you typed into their web browsers, bringing it to a total of two hundred thousand (200,000) requests in a given time. Imagine one server receiving all those 200k requests. Response time might become slow or the server might even crash.
To avoid this, big companies like Google implement what is called a Load Balancer mechanism. What the load balancer does is receive all those 200k requests and distribute them evenly or sequentially (depending on the algorithm used by the load balancer) between multiple servers in order to reduce the load on a single server. That is how big companies like Google handle millions of requests periodically.
With this implementation, the server that received your request for the first time when you searched ‘google.com’ might be different from the server that receives your same request after a day or two. With the load balancer in between, your request passes through the load balance both to and from the server.
When the server replies to your request, it does that by sending a response. So you requested a resource and the server has to respond. This response is usually called an HTTP response because initially, what you did was initiated an HTTP request from your web browser.
Since you requested ‘google.com’, the server is going to reply with specific content like HTML, CSS, and Javascript files that make up the Google home page. The HTML file instructs your browser on how to render the content of the page; The CSS tells how the content should be styled and the Javascript gives behavior or interactivity to the page. While only these types of files? Because they are the files needed to render the Google homepage in your browser. HTML, CSS, and Javascript files are considered static content.
What if there was a need for dynamic content? Let’s say, after accessing google.com, you decided to search for a list of famous people in the world. When you do that, the web server will make a request to the application server, which would then make a request to the database server to return the search results of famous people in the world, exactly the results that match your search criteria. Then, the response is done in reverse: The database server will send the response back to the application server, and the application server will now contact the web server and finally, the search results get displayed in your web browser.
I just gave you an overview of what happens when you actually type ‘google.com’ in your web browser. As you can see, it’s not all that simple, but you would barely notice because of how blazingly fast this works, especially when you are on a super-fast internet connection. Before I get deeply technical, let me help you visualize what’s happening.
Now let’s dissect each part of this process and discuss it for what it truly is.
DNS Request
Earlier, I spoke about DNS servers. The work of the DNS server is to resolve human-readable domain names into computer-readable IP addresses. For instance, anytime you visit a website, your browser remembers that visit by storing information about your visit in its cache. This process is called caching, and the essence of it is so that the next time you try to access that same website, the browser would know the IP and directly connect to the server without contacting the DNS server to get the IP address. Pretty interesting, isn’t it?
However, if the browser doesn’t have information about the site (i.e It’s your first time ever accessing the site using that browser), perhaps, you’ve cleared your browser’s cache, or the DNS record for that specific domain has changed recently, the browser is then going to make a request to the DNS server to handover the corresponding IP address of that domain name you’ve typed.
Internal Workings of the DNS Server
The DNS server is usually located at your internet service provider’s end or the ISP for short. An ISP is any company that provides you with internet access. At the ISP, there is a local DNS resolver that stores information on domain names and their IP addresses. So it’s the first place that gets checked when your request hit the DNS server. If this local DNS resolver doesn’t have that information, it is going to forward your request to a root name server.
The job of the root nameserver is to respond with a top-level domain (TLD) such as “.com”, “.org”, “.net”, “.tech”, etc, and also by providing information about the authoritative nameserver of the domain.
At the authoritative nameserver is where everything is finally resolved. The authoritative nameserver responds with the unique IP address of the server that has the resource for ‘google.com’. It is this server that responds with the IP 8.8.8.8.
It’s a bit of a process, but you can be sure that this process will be cached by both the browser and the DNS resolver so that the next time you try to access the domain ‘google.com’, there will be a record of it.
There is a TTL or “Time To Live” that determines the length of time that the DNS record for ‘google.com’ can be cached, and this is solely determined by the nameserver.
TCP/IP
The Internet is what it is today mainly because of two important protocols: TCP (Transmission Control Protocol) and IP (Internet Protocol). These protocols depend on each other. There’s no TCP without IP, and on the other hand, IP cannot communicate without TCP. Let’s dig deeper.
I mentioned earlier that TCP is what happens next after your browser acquires the IP of the server that ‘google.com’ points to. Why is that? Initially, when your browser sent the request, it was accompanied by an additional piece of information which is your computer’s IP address. Until the DNS server resolves ‘google.com’ to an IP, only your computer’s IP is known. After the DNS resolution, now two IP addresses are known (Your computer’s IP address and the server’s IP address).
Your computer makes the request to the server using TCP. The transmission control protocol is responsible to ensure this connection is reliable and correct. By correct I mean following the standards of the Open Systems Interconnect (OSI) that were adopted in 1984 by the International Standards Organization (ISO). That was just a side track. Let’s get back to the flow.
After the TCP/IP connection is established, the server will respond by sending HTML, CSS, and Javascript content for rending ‘google.com’, which is the Google homepage. Remember all the request and response thing is done over a TCP/IP connection.
Firewall
When we talk about firewalls, the only thing that should come to mind is security. In computer networking, firewalls are meant to prevent certain access. Firewalls are security rules, and their primary purpose is to prevent external potential threats from hackers, malware, and spyware. Let me explain.
Earlier, when you typed ‘google.com’ in your web browser (assuming your computer was behind a firewall), the request passed through the firewall on its way to one of the Google servers. The firewall ensured that the outgoing request was allowed by its rules. Let’s dig deeper into firewall rules.
Rules that block requests based on source and destination
If you have ever been denied access to a website or web service because of your geographic location or your IP address, chances are you’ve been affected by this rule.
Rules that block requests based on the request type
When you are requesting to access a webpage on the internet, this type of request is known as an HTTP or HTTPS request, and there are designated ports that listen in for such requests. For instance, HTTP listens on port 80 while HTTPS listens on port 443. And you got it right, these ports are what are called TCP ports. Remember TCP? Good! On the other hand, your request could be denied access to an SMTP port, and if it does, you’ve been affected by this rule.
On the other end, if Google’s firewall allows your request, you’re definitely going to access the webpage otherwise you’re going to be denied. That’s the amazing work of firewalls.
HTTPS/SSL
Earlier, I said that when you typed in ‘google.com’ in your web browser and hit enter on your keyboard, what you were doing was making a request. This request is called an HTTP request. HTTP stands for HyperText Transfer Protocol). This protocol ensures that the data transmitted between your web browser and the Google server is encrypted. But the question is, is this really encrypted using HTTP? The answer is, No.
Due to this, a secure version of HTTP which is HTTPS was introduced. The “S” before the “HTTP’ stands for “Secure”. When your browser established the connection with the Google server, that happened over HTTPS, thus establishing an SSL connection. The SSL connection is just an added security tunnel for transmitting the data securely. This way, the data is completely unhackable. Only your web browser and the Google server know what’s been sent.
Load-balancer
Let’s go back to the hypothetical scenario I presented earlier about the 199,000 other requests that were been sent at the same time you were sending yours. A total of 200k request was sent to ‘google.com’ or the IP 8.8.8.8. All these requests hitting a single server might cause the server to reduce performance or even crash. There must be a mechanism to distribute these requests evenly. This mechanism is called load balancing. The overall work of a load-balancer is to increase the reliability of the system by reducing the load on a single server.
As of this writing, it is estimated that Google receives 9 billion searches a day. With this estimate, it is only obvious that a single web server cannot handle these requests. A load-balancer is implemented to distribute these requests evenly so that other servers can’t get overloaded while others are underutilized
So when your browser made the request, it was received by the load balancer on Google’s end. The load balancer, using a load-balancing algorithm, sent your request to one of Google’s servers in the server network. There are different types of load-balancing algorithms such as Round Robin, Weighted Round Robin, Least Connection First, etc.
Web Server
A web server could be a physical or virtual server with a piece of software installed on it. This software is responsible for handling the request for web pages. This server receives the request from the load-balancer and replies with the appropriate response back to the load-balancer, which forwards the request to the client browser. The type of response would usually be the HTML, CSS, and Javascript files for your browser to render.
Application Server
We’ve seen the web server handling static content. What about dynamic content? Dynamic content is stored on what is called an application server.
When you search Google for a list of billionaires in the world, your request gets routed to an application server that is responsible to fetch all websites that match your search criteria. This process involves querying a database.
Database Server
The database server is responsible to store dynamic content. It acts like a storehouse, with the ability to get you the data you need from it in the quickest possible time.
Conclusion
So you now have a deep understanding of the underlying technologies that are involved when you type ‘google.com’ and hit enter on your keyboard. Most times, people oversimplify this, and as a tech-savvy, it pains me. I decided to write about this internet mystery so that even you, a non-techie, and appreciate the beauty that makes our world so connected today.
As a software engineering student, I’m submitting this post to the Software Engineering program at the African Leadership Experience (ALX) as my project.
Hope you enjoyed the ride. Please feel free to leave a comment. If you would love to connect with me personally, send me a DM on Twitter. I would love to hear from you. I’m also available on GitHub and LinkedIn.
I also write amazing content at Techpro Dailys. Thanks for the support.
