Open in app

Sign in

Write

Sign in

The Backend Developer Roadmap: Part 1: Internet vol. 2

David Viodes
7 min readMar 31, 2021

--

Alright, welcome back. In the last blog post we went over the Internet, its history, and how it works. I had briefly mentioned topics such as web browsers, HTTP, and Domain Names. This blog post aims to cover these topics more in depth. There were numerous articles that helped me along the way. So, I will be giving special acknowledgments and shout outs to the authors and companies that came up with these articles as they appear in this blog post. The information I will be presenting will be a summary of articles mentioned. Links to the specific articles can be found at the shoutouts or at the bottom of this blog in the bibliography. Without further ado, let’s get started.

Browsers And How They Work

Web browsers. We all use them. But few actually know how they work behind the scenes. A web browser’s, or client’s, main job is to fetch and display data on a desktop or mobile device. There are a series of tasks that go into ensuring this job’s completion. First, the client must navigate to the correct server that holds the data for the webpage. This is accomplished through a process known as DNS lookup or DNS resolution. Alex Nadalin states in his article How Browsers Work,

This process makes sure that once the user enters a URL, the browser knows which server it has to connect to. The browser contacts a DNS server to find that google.com translates to 216.58.207.110, an IP address the browser can connect to.

Once the IP address is returned from the DNS resolution, the client must set up a connection to the server through a process known as a TCP handshake. I will also discuss the TLS handshake, though keep in mind this process is only necessary for secure connections made through HTTPS. Next, the client must tell the server what it needs. Subsequently, the server will either respond with the requested information, or it will respond with an error explaining why it was unable to provide the information. This back and forth communication is known as an HTTP exchange. Finally, once the data that the client requested is received, the client will begin a process known as rendering. During this process, the client will begin parsing the information received to begin painting the web page onto the screen. Now, let’s take a closer look at each one of these steps.

DNS Resolution

Let’s start with what DNS is and why it is important. Cloudflare’s article What Is DNS | How DNS Works says that DNS, which stands for Domain Name System, serves as the “phonebook of the Internet”. The article then goes on to explain that every device that is connected to the Internet is provided with a unique IP address. The most current version of IP is IPv6 with IPv4 being utilized extensively as well. An IP address under IPv4 may look something like 192.168.1.1. While an IP address under IPv6 may look something like 2400:cb00:2048:1::c629:d7a2. With every website having its own unique IP address, this would become very difficult very quickly if we had to memorize all these crazy IP addresses. Luckily, DNS addresses this by converting domain names, like google.com, to IP addresses.

Now, how does DNS convert a hostname into an IP address? Let’s take a look at the four DNS servers involved with this process.

  1. Recursive resolver (DNS recursor)
  2. Root nameserver
  3. TLD nameserver
  4. Authoritative nameserver
Image via Cloudflare

A recursive resolver, otherwise known as a DNS recursor, acts as the middleman between the client and a DNS nameserver. If the DNS recursor has the IP address that the client is asking for cached already, it will simply return the IP address to the client. However, if the DNS server does not have the IP address cached, it will then send a request to the root nameserver. The root nameserver will then tell the DNS recursor which TLD nameserver to send the request to. The DNS recursor then sends the request along to the TLD nameserver which tells the DNS which authoritative nameserver to send the request to. Finally, the DNS recursor sends the request to the authoritative nameserver which tells the DNS recursor what the IP address is for the requested hostname.

TCP and TLS Handshakes

The IP address has been returned, the client knows where to go, now the client sets up a connection with the server utilizing the TCP handshake. As Sujan Rai’s article TCP 3-Way Handshake Process explains, the TCP handshake may be referred to as “SYN, SYN-ACK, ACK”. This is in reference to the process having three steps to it. First, the client sends a segment with a Synchronize Sequence Number, or SYN, informing the server that communication is about to begin with that sequence number. Next, the server acknowledges, or ACKs, the segment and sends a segment of its own with an SYN back to the client. Finally, the client ACKs the package and, with one SYN going one direction and one going the other, what is known as a full-duplex communication is formed.

Now that the TCP handshake is done, the TLS handshake, or negotiation, must occur to establish a secure connection. The process looks like this:

Image via ssl.com

Chris Kemmerer offers much more detail than I am willing to go into here on this process so if you would like a more detailed look at the TLS handshake process, check out his article The SSL/TLS Handshake: An Overview.

HTTP Exchange

Image via MDN Web Docs

Once the TCP, and sometimes TLS, handshakes are finished and connection has been established, the HTTP exchange can begin. HTTP is short for Hypertext Transfer Protocol which is the most commonly used protocol dealing with how data is sent over the Internet. During this exchange, the client will send an initial HTTP GET request to the server. The server will then respond with the proper response headers and HTML. An algorithm called the TCP slow start is typically used by the server to balance the speed of a network connection. This algorithm allows the server to send a 14kb packet of data to the client for the first response. The client acknowledges the response and the server can then double the size of the packet for the next response. This pattern continues until a predetermined threshold is reached, or congestion happens.

Congestion is simply when the server sends packets of data faster than the client can acknowledge them, causing the packets to be dropped which results in the server registering it as a missing ACK.

Rendering

Once the data is received, the client will begin the process of parsing the HTML and constructing what is known as the DOM tree.

Image via w3schools

The client will then load any other additional resources included in the HTML, such as CSS or JavaScript files, and presents all of this to the user as a fully formed and functional webpage. I will be going into further detail on HTML, CSS, and JavaScript in part 2 of this blog series. So, stay tuned for that. However, for a more detailed explanation of the rendering process, check out Mozilla’s article Populating the page: how browsers work.

What Is Hosting?

Alright, I know that was a TON of information. We have one more small topic to cover before moving onto part 2 of this blog series. That small topic, what is hosting? website.com’s article What is Web Hosting provides a short and sweet answer to the question.

Simply enough, hosting is a service provided by a web hosting service provider that allows you to host your website on their server. That’s it. That’s the whole thing. They provide you with all of the technologies and services needed to accomplish this task. Most times, the web hosting service provider will require that you own the domain name you want your website to have in order to host with them. If you do not own the domain name, the provider may assist you with purchasing one. And that, ladies and gentlemen, is hosting in a nutshell.

I do want to thank you for taking the time to read part 1 of my blog series, The Backend Developer Roadmap. As stated above, part 2 will be about basic frontend knowledge. I hope to see you all there!

Extra Resources

Bibliography

Backend
DNS
Knowledge
Journey
Web Development

--

--

David Viodes

Written by David Viodes

3 Followers

Full-Stack Web Developer who continues to learn things whether he likes it or not.

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams