What happens when…
What happens when you type a URL into your browser? While software engineers and other positions involving computers and technology would be most likely to have been asked this question, whether as an interview question or as part of their education, with the ever-growing rise of technology any person needs to have some insight into how information is stored and moved behind the scenes. For this post, we’ll assume you are trying to access the site https://www.holbertonschool.com. What happens first?
The URL is entered into your address bar:
Before a URL can be accessed, the browser has to know where you want to go. From the moment you press the first key, whether you’re on a physical or digital keyboard, the browser will receive the event (a specific action recognized by the software, in this case, a keypress) and display the letter or symbol pressed in the address bar. Immediately after, the browser’s autocomplete function will kick in. Different browsers have different algorithms to determine what you may be trying to enter based on factors such as past searches and common or trending searches, as with Google Chrome’s Omnibox address bar, with further symbols entered helping to refine the search. Once the enter key is pressed, signaling the end of the query, the browser determines if what you are looking for is a website or a search. In the case of it being a search term, you are transferred to the default search program for your browser with the search term already entered, otherwise, it moves on to the next step.
A DNS request is made:
DNS, or the Domain Name System, is a record of the domain names (such as holbertonschool.com in this example) and their corresponding IP address (in this case, 34.234.197.104). When a DNS request is performed, the browser is taking the human-readable domain name and translating it to the machine-readable IP address so it knows where to request information from. A domain name is technically not needed, as you could simply visit http://34.234.197.104 to visit the website, but that is harder to remember, making DNS significantly more user friendly.
When performing a query, the browser will perform up to 4 steps to retrieve the IP address:
First, the browser will check it’s local browser cache. The browser cache stores websites you have visited previously for a short time, with positive responses being held for up to a day by default, and negative responses typically being held for only around 5 minutes.
If the browser is unsuccessful in locating the IP address this way, it will next check the cache of your operating system. This cache is similar to the one maintained by your browser, the main differences being that is is computer wide and the records typically have a much longer time to live.
If the IP address still hasn’t been found, it moves on to the third step, checking the cache located on the router, which is maintained independently of any computer on it.
Finally, we go to the Root DNS server. As the website is “holbertonschool.com” we are asking for information about “.com” and are referred to the relevant Top Level Domain in charge of “.com”. From there we are referred to the Authoritative Name Server with the information on “holbertonschool.com”, which finally gives us the IP address we are looking for.
Now that we have the IP address, we can finally query the home page of the website while the result is cached by our 2 local caches and the router cache for later use.
The browser connects to the server:
While IP is the method used to perform connections over the internet, it is unable to account for a lot of things, such as error checking or ensuring everything arrives in an order the receiving machine can interpret. That’s where TCP, or Transmission Control Protocol, comes in. Let’s imagine for a moment you wanted to send a letter in the mail, but you could only do it one word at a time. As you send the letters, they may take slightly different routes or encounter delays along the way, causing them to arrive at different times, out of order, and some may even be lost in transit and the receiver would have no way of knowing. With TCP, a connection is maintained throughout the transfer, and once all the pieces of the original letter are received, TCP will sort them out into the proper order.
TCP operates by establishing a 3-way handshake before a connection can be established. This is done by having the client send a packet of data called a SYN packet. Once it is received by the server, the server acknowledges it by sending a SYN-ACK packet. Last, the client sends an ACK packet to acknowledge the receipt and at the same time, the first packet can be sent. TCP prevents loss of packets by requiring the server to send an acknowledgment after every packet sent, that way a copy of the packet can be sent out if one is lost. In addition, a portion of the packet contains the data TCP uses to reorder the packets at the end so everything is received as it was sent. When both the client and server are ready to terminate the connection, it is done in the same way the connection was opened, only with FIN packets instead of SYN.
Moving Past the Firewalls:
When talking about security in any network or server, a firewall is an extremely important component. To put it simply, a firewall is a program that inspects each packet that tries to pass through to or from a server and determines if it should be allowed to pass or be intercepted. A firewall works by having a series of filters that any traffic will pass through. These filters can be as broad as denying all traffic on all non-whitelisted ports, to as narrow as denying all incoming traffic from a certain IP address. If a packet gets flagged by any of these filters, it is blocked from moving forward. Many firewalls block all traffic that is not on port 22 (for ssh connection), port 80 (for HTTP connection), and port 443(for https).
HTTPS/SSL:
Now that your data has moved past the firewall, it is time to request the data from the website. With increased standards regarding security on websites, many websites now default to using https when transferring data, which allows data to be encrypted before transfer to prevent unencrypted data from getting into the hands of an unauthorized person or program. To connect using https, the web server will first have to send over a copy of its SSL, or secure sockets layer, certificate. Utilizing SSL and other encryption methods provides benefits not only to the client wishing to connect, such as a safer transfer of potentially sensitive data, but for the webserver as well, namely the trust it can foster in their users and the better ranking on Google’s search engine. The client will receive the certificate and perform a check to see if the certificate can be trusted. Assuming it is, the client will then send back an acknowledgment to start the encrypted session. Once the session is started, encrypted data can be shared between the client and web server, typically over port 443.
Load-Balancer:
The main purpose of the load balancer is to simply redirect traffic to a web server, with servers chosen using an algorithm selected by the host. While a load balancer isn’t strictly necessary, as you could always simply connect directly to the webserver (assuming the connection would not be blocked by the firewall) bypassing the need for a load balancer, a load balancer serves to prevent a server being overloaded if many users wish to connect at once, diminishing the threat of Denial of Service attacks, and also serves to ensure a website does not go offline if maintenance needs to be performed, as one server can be taken down and the load balancer will simply no longer send traffic there until it is back online. When a client attempts to connect to a load balancer, the load balancer will check which web servers are available, and make a decision on which webserver to send the client to. After making this decision, the load balancer changes the destination IP and port as necessary to match the webserver it has selected. The web server will then accept the connection, and send an acknowledgment back through the load balancer, which forwards it to the client. Once the client has received this packet, it will continue with the connection.
Receiving the web page:
Now that we’ve finally connected to a web server, we can take the final step to receive the page. The client sends a request to the webserver for the page. The web server receives and acknowledges this request, and submits its own request to the application server for the content. The application server will look at the content that is being requested. If the content requires something from the database, such as if content displayed on the page contains data in the database, the application server will submit a query to the database to get whatever content it needs. Once the query has been returned, the application server responds to the web server’s request with the content, which is sent through the load balancer towards the client. The final step before reaching the client is it may have to pass through the firewall filters one more time before it is sent to the client, after which point the web page will be displayed on the client’s browser, less than 2 tenths of a second after the initial request was made.