What happens when you type a webpage into a browser?

google.com — — — — — — — →209.85.277.104

In the OSI model (Open Systems Interconnection Model), DNS is under the application-layer protocol.

(If the URL does exists in the cache, move to step #4)

Before having to go through additional steps, the browser attempts to locate the DNS record associated with the URL.

First — the browser checks it’s own cache as the browser maintains a “cache of DNS records for some fixed duration”.

Second — if the record is not found in the browser, it moves on to the OS’s cache by making a system call (gethostname)to fetch the DNS record as the OS also maintains a cache of recent DNS queries.

Third —if not found in the OS’s cache, the browser moves on to the router’s cache as the router also maintains a cache of DNS queries.

Fourth — lastly, the browser checks the ISP cache if all above caches have failed. Your ISP will have a record of your DNS cache since it maintains it’s own DNS server.

If the browser has not found what it needs in any of the possible cached locations, it moves on to initiate a DNS query.

DNS servers are based on a recursive lookup; if the last step of looking in the ISP cache fails, the resolver, usually your ISP (Internet Service Provider) will locate the root server (something all resolvers must know). Why is this important? The root server is important because the root server holds all the locations of the TLD (Top Level Domain) servers, which includes: .COM, .NET, .ORG, etc. The root server won’t know the IP of “holbertonschool.com” website, but it does know the .COM Top-level domain server, which it returns. This information is saved by the resolver and if the .COM server is unable to locate the IP address needed, it provides the resolver the name servers (authoritative name servers). This information is known to the .COM server with the help of the Domain Registrar — when the domain for “holbertonschool.com” was first purchased, the domain registrar reserved the name, communicating the authoritative name server addresses to the .COM TLD registry.

The .COM TLD gives the resolver a list of .COM servers associated with the IP address for “holbertonschool.com”. Since the list is not given in any order, the resolver runs a WHOIS query, giving the resolver the IP address it needs.

After the resolver retrieves the IP address for “holbertonschool.com”, the TCP and IP makes an introductory agreement — a handshake. Let’s dive deeper:

Once the correct IP address is received, the browser will build a connection with the server that matches the IP address in order to make the transfer of content. This is done with a process called a TCP/IP three-way handshake as it is a three-step process where the client (your computer) and the server exchange SYN(chronize) and ACK(nowledgement) messages to make the connection needed.

The IP address is cached and the TCP/IP connection has been made. It’s fairly straight-forward from here if the request made was over HTTP (Hyper Text Transfer Protocol). If the page is being served under HTTP (located at port 80) the server handles the request, sends it back and HTML is served to the user.

However, what happens when the request is over the more secured connection HTTPS (Hyper Text Transfer Protocol Secure)? HTTPs pages typically user one of two secure protocols to encrypt the connection — SSL (Secure Sockets Layer) or TLS (Transport Layer Security). Both of the protocols use a system called “Asymmetric” Public Key Infrastructure (PKI). How does this work?

A PKI or asymmetric system uses two “keys” to encrypt the connection, a public and private key — basically a lock and key mechanism where anything encrypted with the public key can only be decrypted with the private key and vice-versa. The public key can be distributed but the private key must be kept hidden and safe or else all the security you’ve established is now in the wind.

Before any packets are actually sent, if you have a firewall, anything not secured or not recognized is filtered. What is a firewall? A firewall is a “network security device that monitors incoming and outgoing network traffic” — based on your configurations on what is allowed in, the firewall can allow or block traffic from entering in based on your security settings. A firewall can be hardware, software or both — it just depends on how it ends up being implemented. After your firewall has allowed in approved traffic (packets), you might have something called an SSL to ensure whatever is coming in is encrypted.

SSL or Secure Sockets Layer provides additional security by establishing an encrypted link between the web server and the browser. It ensures that all data passed between the web server and browser is private. This is done during the TCP/IP three-way handshake. For example, client A needs to establish a TCP/IP connection with client B and to make sure client B is really client B, the following is done:

Ok, what about load balancer? Where do they come to play in the whole schema of transferring packets? First, what is a load balancer? A Load Balancer is a device that allows the traffic coming to and from to be distributed across a number of servers. Ok, but what’s the point of distribution? Well, what if all the HTML content and data are stored in just one web server? What would be the SPOF (Single Point of Failure)? The SPOF, in this case, is that the users, which can be you, would be unable to access the content if the website is in the mist of an update. How so? In order to update the content, everything needs to be shut down.

To remedy that, a load-balancer is put in place so that content can be contiguous and seamless; when one web server goes down, the back-up can be used.

Now, how would the content be distributed? Well, there are two popular methods: (1) Active-Active load-balancing or (2) Active-Passive load-balancing.

There are pros and cons to either method — whatever is chosen largely depends on traffic and what is decided.

Now we’ve passed the firewall, verified both parties and have a seamless and uninterrupted web-browsing session. Ok, but how is the content and data sent to the user?

Once all the content has been gathered by each of the servers; the web server sends out a response, containing the web page you’ve requested along with other information such as status code.

The browser then displays the HTML content and think, all this was done in the milliseconds as you waited for your web-page to load.

Resources:

Computer Networking: A Top-Down Approach by James F. Kurose and Keith W. Ross

Related posts:

dua gelas kopi tersaji kesepian di teras rumah kali ini. pintu pagar tertutup rapat--daun mangga luruh membaca bumi. seorang ibu memeluk lututnya. tatapannya tajam pada harapan. kantuk retak di…

I like writing as it also helps me align my thinking. I do keep lots of theories, ideas probabilities in my head but I when I write I can redesign them and align them so that pieces of the puzzle in…