What happens when you type “google.com”

Just for the pleasure of finding out how things work

With loads of sources on the internet to understand how google.com actually shows up on your web browser, it was really difficult for me to understand it initially. Here is what I learnt-

‘g’ is pressed

When you just type ‘g’, the browser receives the event and the auto-complete algorithm starts. Based on your browser you are using the algorithm presents you with the various suggestions in the dropbox below the URL box. The suggestions are prioritized based on your search history and bookmarks. Suggestions are refined after each key is pressed.

‘enter’ is pressed

Browser now has the following information contained in the URL-

Parse URL

1. Protocol-“hhtp”

Use ‘Hyper text transfer protocol’

2. Resource- “l”

Retrieve main index page

Check HSTS list

Browser checks its HSTS (HTTP Strict Transport Security) list. This is a list of websites that have requested to be connected via HTTPS only. The browser sends the request via HTTPS instead of HTTP.

Convert non-ASCII Unicode characters in hostname

The browser checks the hostname for characters that are not in a-z, A-Z, 0-9, -, or ..

If there are the browser would apply Punycode encoding to the hostname.

DNS Lookup

Browser checks if domain is in the cache. If not found it calls the OS’s gethostbyname which checks if the hostname can be resolved by reference in the local hosts file. If not found here it makes a request to the DNS server. This is mostly the local router.

• If the DNS server is on the same subnet the network library follows the ARP process below for the DNS server.
• If the DNS server is on a different subnet, the network library follows the ARP process below for the default gateway IP.

ARP Process

In order to send an ARP broadcast the network stack library needs the target IP address to look up. It also needs to know the MAC address of the interface it will use to send out the ARP broadcast.

The ARP cache is first checked for an ARP entry for our target IP. If it is in the cache, the library function returns the result: Target IP = MAC.

If the entry is not in the ARP cache:

• The route table is looked up, to see if the Target IP address is on any of the subnets on the local route table. If it is, the library uses the interface associated with that subnet. If it is not, the library uses the interface that has the subnet of our default gateway.The MAC address of the selected network interface is looked up.

Opening of a Socket

Once the browser receives the IP address of the destination server, it takes that and the given port number from the URL (the HTTP protocol defaults to port 80, and HTTPS to port 443), and makes a call to the system library function named socket and requests a TCP socket stream.

• This request is first passed to the Transport Layer where a TCP segment is crafted. The destination port is added to the header, and a source port is chosen from within the kernel’s dynamic port range (ip_local_port_range in Linux).
• This segment is sent to the Network Layer, which wraps an additional IP header. The IP address of the destination server as well as that of the current machine is inserted to form a packet.
• The packet next arrives at the Link Layer. A frame header is added that includes the MAC address of the machine’s NIC as well as the MAC address of the gateway (local router). As before, if the kernel does not know the MAC address of the gateway, it must broadcast an ARP query to find it.

HTTP Server Request Handle

The HTTPD (HTTP Daemon) server is the one handling the requests/ responses on the server side.

• The server breaks down the request to the following parameters:

1. HTTP Request Method (either GET, POST, HEAD, PUT and DELETE). In the case of a URL entered directly into the address bar, this will be GET.

2. Domain, in this case — google.com.

3. Requested path/page, in this case — / (as no specific path/page was requested, / is the default path).

• The server verifies that there is a Virtual Host configured on the server that corresponds with google.com.
• The server verifies that google.com can accept GET requests.
• The server verifies that the client is allowed to use this method (by IP, authentication, etc.).
• If the server has a rewrite module installed (like mod_rewrite for Apache or URL Rewrite for IIS), it tries to match the request against one of the configured rules. If a matching rule is found, the server uses that rule to rewrite the request.
• The server goes to pull the content that corresponds with the request, in our case it will fall back to the index file, as “/” is the main file (some cases can override this, but this is the most common method).
• The server parses the file according to the handler. If Google is running on PHP, the server uses PHP to interpret the index file, and streams the output to the client.

Working of the Browser

Once the server supplies the resources (HTML, CSS, JS, images, etc.) to the browser it undergoes the below process:

• Parsing — HTML, CSS, JS
• Rendering — Construct DOM(Document Object Model) Tree → Render Tree → Layout of Render Tree → Painting the render tree

HTML parsing

The parses the HTML markup into a parse tree. Almost all browsers have fault tolerance of most common invalid HTML cases.

Page Rendering

• Create a ‘Frame Tree’ or ‘Render Tree’ by traversing the DOM nodes, and calculating the CSS style values for each node.
• Calculate the preferred width of each node in the ‘Frame Tree’ bottom up by summing the preferred width of the child nodes and the node’s horizontal margins, borders, and padding.
• Calculate the actual width of each node top-down by allocating each node’s available width to its children.
• Calculate the height of each node bottom-up by applying text wrapping and summing the child node heights and the node’s margins, borders, and padding.
• Calculate the coordinates of each node using the information calculated above.
• Create layers to describe which parts of the page can be animated as a group without being re-rasterized. Each frame/render object is assigned to a layer.
• Textures are allocated for each layer of the page.
• All of the above steps may reuse calculated values from the last time the webpage was rendered, so that incremental changes require less work.
• The page layers are sent to the compositing process where they are combined with layers for other visible content like the browser chrome, iframes and addon panels.
• Final layer positions are computed and the composite commands are issued via Direct3D/OpenGL. The GPU command buffer(s) are flushed to the GPU for asynchronous rendering and the frame is sent to the window server.