What happens when you type a URL in your browser and press enter

Stuart Kuredjian
Aug 9, 2017 · 5 min read

There’s a lot that goes on under the hood when you navigate to any website. In this article I will walk you through the path your URL request takes, from computer to website an back. I will be using holbertonschool.com as the example domain name on our journey.

You begin typing holbertonschool.com into your choice of browser and before you’ve even completed the string, the querying has already begun. I will leave the specifics of such things like how your browser tries to auto-complete the URL for another article.

Ok, you’ve pressed the enter key. From a very top-level view, you are asking the internet* to give you the home page for holbertonschool.com. The internet retrieves your file and returns it to your computer screen. Simple right? Ok let’s make it not so simple…. but fun nonetheless, I promise. Let’s jump in.

When you hit enter, you’re actually requesting a file from another computer, or server on the internet. But how does your browser know exactly which server on the internet is holding the home page for holbertonschool.com? By the name holbertonschool.com? Not exactly.

Computers and other connected devices on the internet communicate with each other using a unqie set of numbers called an IP address. In some cases you could type the IP address into your browser instead of the actual domain name. It would, however, be incredibly difficult remembering all the IP addresses for the sites you visit. So what has to happen is a domain-name to IP address translation before the browser can actually request the web page you’re trying to pull up.

IP Address Request

Where does this translation happen? Well, ideally your computer would have already visited the site and has stored the IP address for holbertonschool.com in your browser’s cache. If, however, you’ve never been to the site (or your cache has been cleared), neither your browser nor your operating system will know which IP address to associate with holbertonschool.com. It then lies on the resolver, usually your Internet Service Provider (ISP) to do the translating for you. Asking your ISP for the IP address is the first step in what is called the Domain Name System (DNS).

Assuming holbertonschool.com is requested on a regular basis, the resolver will probably have the associated IP address already. If not, it sends the request to the next step up in the lookup hierarchy: the root server**.

If the root server doesn’t have the information, it gives the resolver the address for the .COM Top-Level Domain (TLD) server*** and our search for an IP address that can take us to holbertonschoo.com continues. The resolver also takes note of the .COM TLD server’s address so that it doesn’t have to ask the root server next time holbertonschool.com is requested.

Finally, if the .COM TLD does not have the IP address associated with holbertonschool.com, the resolver is given the addresses to the source location where the IP address is sure to be found. This location is the authoritative name server, owned by the company that Holberton School purchased the domain name from. How though, does the .COM TLD know the address of the name server to give the resolver? When Holberton School first purchased the domain, the domain registrar reserved the name holbertonschool.com and communicated the authoritative name server addresses to the .COM TLD registry.

Now, the resolver knows exactly where to get what it’s looking for. The .COM TLD gives it not one name server address, but a list of them (usually 2 to 4). The domain registrar hosts multiple name servers so that it can handle high volume requests for all the other domain names they host. In addition, having multiple name servers is important in the event that one of the other servers fail.

So the resolver gets the IP address for holbertonschool.com from one of the name servers and passes it back to your browser. Fun right? And we haven’t even communicated with the actual website yet. :)

TCP/IP handshake

So now what? Ah, the request! Before the actual request is made, an introductory agreement must be made between the requesting client and the server where holbertonschool.com resides. An agreement that the standardized Transmission Control Protocol/Internet Protocol (TCP/IP) will be followed must be made on both ends. This agreement is made via a 3-step handshake: 1) client says “here I am” to the server. 2) The server then responds, “I acknowledge that you’re here.” 3) And finally, the client responds “I acknowledge that you acknowledged that I’m here.”

Load Balance Server / Securing the Connection

The main point of entry for the client’s request is at the load balance server. This is a server whose primary function is to distribute traffic among several servers in order to minimize strain on any one individual server. It is also here that the client’s connection is secured via SSL authentication/encryption. Once authentication has occured, the connection can proceed via the secure HTTPS protocol.

Restricting access with a firewall

Between the load balance server and the web-server software, is a firewall (hardware and/or software). This prevents all non-secure requests (those not over an HTTPS connection on port 443) from getting through.

Touchdown: the web server and it’s affiliates

The webserver is the software that processes the client’s request. The request may be as simple as a static HTML file with some text and media. In this case, the HTML file and any associated images, etc. are retrieved from the file system and served back to the client.

If, however, the requested file contains dynamic content, the web server must interface with the database server to retrieve specific queried information as well as the application server so that the queried data can be compiled and packaged into the final HTML file returned to the client.

In summary:
- the client types holbertonschool.com in their browser.
- a DNS lookup is done to resolve the IP address from the domain name.
- a request is sent to the IP address of the server where the requested content is stored.
- the server facilitates request routing, SSL authentication, port 443 forwarding, database queries, application compilation and finally service of content back to the requesting client.

And that’s that. Well.. it’s not exactly a nutshell and if we’re being honest, the granular information that could be covered for each step of the process would take a truckload of nutshells. But we’ll save those trucks for another article.

— — — — —
* The internet is a wide-area network (WAN), the largest of it’s kind. It is a network of Internet Service Providers (ISP), data-centers and universities that spans the globe.

** There are 13 root servers that exist as of this blog post. Root servers sit at the top of the DNS heirarchy and are scattered around the globe and operated by 12 independant organisations. The 13 root servers
are named “A.root-servers.net” through “M.root-servers.net.”

*** There is a TLD for each dot type (.com, .net, .org, .edu among others). The .COM TLD was the first and was created in 1985.
— — — — —

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade