Using a browser to consume content is something most of us do everyday. Heck, you’re doing it right now. Recently though, I was humbled by the realization that for something I do so often, I only had a vague idea of what was happening “under the hood”. But rather than stew in my own shame and self-loathing, I decided to dive in to gain a better grasp on the complete end-to-end process, or life cycle, of a browser. While I won’t be tackling the complete complexity and hundreds of components that make up a browser, hopefully this quick guide will give you a better understanding of what’s happening the next time you navigate to a website.

Request Preparation

Most often a browser’s journey begins with a  Uniform Resource Locator , or, as it’s more commonly referred to as, a URL. Put simply a URL is an address. Put a little less simply a URL is a specific type of  Uniform Resource Identifier  (URI) which is a sequence of character that identifies a resource, and, for our purposes, a website. Diving a bit deeper you’ll find that the URL structure is surprisingly robust as it contains:
  • Protocol: the (network) method of access to the resource.
  • Domain: the address where the resources can be accessed, these are often used in place of an IP address because they’re easier to remember.
  • Path: a more precise location for accessing specific resources.
  • Query string: where parameters and values are stored.
  • Fragment: an internal page reference, commonly referred to as an anchor.

url example

Once you’ve entered a URL into the address bar and struck the enter key the browser gets to work!

The Power of DNS

Domain names are useful because they help us more easily remember the address for content, like web sites/pages, we want to consume. Computers, however, don’t use domain names to communicate, they use  Internet Protocol  (IP) addresses. So, steps must be taken to use the domain name to find the associated IP address. This process is known as the  Domain Name System  (DNS) lookup.
The lookups are initially performed through use of a  root server. Root servers contain mapping information between domains and their corresponding IP addresses. Though the number of root servers is in flux there are several hundred located around the world.
client server model

Pretty straight forward, right? Efficient? Not really. As you can imagine it takes time to communicate with root servers, and for data, like domain/IP mapping, that doesn’t change often so it makes sense to cache this kind of information. That’s not to say that a DNS lookup takes a long time, but it’s faster to check cache.

DNS information can be cached at four levels:

  • Browser Cache
  • Operating System (OS) 
  • CacheRouter Cache
  • Internet Service Provider (ISP) Cache

The browser will start by searching its own cache. If that doesn’t exist then the cache stored by the OS will be checked. In fact, this process of checking will continue using the router then the ISP.

browser path

If the information cannot be found at any of the cache levels then a search will be conducted using the root servers previously mentioned.

Request and Response

Note: While HTTP isn’t the only type of request browsers support, it is a very common activity that will provide a good foundation of knowledge to expand in subsequent blog posts.

client server workflow

3.) Having successfully established a connection with the server, the client prepares and sends an HTTP request header that includes information like the HTTP method, path, cookies, and a variety of other details.

request headers

Sample request header

4.) The server receives the HTTP request and begins preparing a packet containing the HTTP response header along with a part of the requested content. There are a variety of content types that can be returned. You can find more information on them  here .

response headers

Sample (HTML) response header

Steps 5 and 6 show how the process can be repeated on an established connection. It’s important to point out that establishing a new connection can be a time-consuming process and crucial to re-use already opened connections as much as possible.

Just the Beginning

When a response from the server has been received the content is then handed off to the layout/rendering engine of the browser. There are a variety of rendering engines but they are all tasked with the same mission; to display information on the screen. While there is certainly more to unpack (see what I did there?) when it comes to the browser rendering from a workflow perspective, that’s it! The complete, high level, journey of requesting information from a web server. Keep an eye out for future write-ups where I’ll be diving deeper into the details of other types of requests (e.g. HTTPS), how browser layout engines work, and more!

Source link

Write A Comment