There and Back Again: A Browser's Tale, Part 1

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.

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.

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.

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

After successfully locating the IP address the browser is ready to make a request for data. It's important to note that from this point forward we'll be looking at a Hyper Text Transfer Protocol (HTTP) request workflow.

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.

1. The client sends a request to open a connection via Transmission Control Protocol (TCP) synchronize (SYN) packet.

2. The server accepts the connection and responds to the client with a TCP SYN acknowledge (ACK) packet.

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.

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.

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!