From Browsers to Servers: The Journey of Your Data

Introduction

Look at the current era, everything looks like is revolving around the internet. Billions of people on our earth communicate, interact and socialize with each other through internet access everyday despite how far away they are. The data sharing or transfer, live streaming, live chat or call, corporate meetings, etc., all of these is working seamlessly with the help of internet connection and that too achieved in a fraction of milliseconds.

Although it looks simple but there are a lot of things working under the hood in a single client to server communication. In this article, we will deep dive into the journey of this data flow over the internet.

Client-Server Model

When we access a website over the internet, the request is sent from the client or browser to the server over the internet network for some information, services or resources. The server then processes the request and sends back the requested information.

During this process a connection is established between client and server and then data flows. The connection between the client and server terminates once the server has fulfilled the request.

We simply provided a website URL on the browser’s address bar, and then it loads with the content of the website in a mere milliseconds or seconds.

But wait, how does browser know about which serve to connect, how to identify the location of the server, and how to establish a secured, reliable and seamless connection for the data flow at both the ends?

Well, we will learn about the same in deep as we proceed from here.

Web Client or Browser

A web browser or client is an application that allows you to access and interact with the website on the internet.

The Journey of your web communication starts when we provide a website URL in the browser address bar. URL (Uniform Resource Locator) is basically an address of your website where it lives online and it helps you to identify the site easily. We will now see what are the various parts of a URL.

Components of a URL

A simple URL consists of at least 3 components as shown below:

But a complex URL can contain up to 9 components as shown below:
Eraser Link: https://app.eraser.io/workspace/Ed3We6PyIgbT4FIXjxjT

Let’s take a look at each one of them.

Protocol or Scheme

This part defines a set of rules for how data is displayed, formatted or transferred over the internet. Commonly used schemes are HTTP, HTTPS and FTP.

Subdomain

It determines what specific content of the website should be displayed. The most common subdomain is “www“.

Second-level Domain

It basically indicates the name of the website.

Top-level Domain (TLD)

It represents the type of the organization. Also known as the domain extension. Commonly used domain extensions are .gov for Government websites, .com for Commercial websites, .edu for Educational institutes, etc.

Subdirectory

It’s located after the TLD in the URL. Also known as a nested folder. Helps to understand the location on a website.

Port

They are simply numbers defined for specific servers. By default, HTTP URL uses port 80 & HTTPS URL uses port 443.

Path

It directs the browser to a specific page on the website. The path must be easy to understand for humans and search engines.

Query

Represented by “?”, it acts as a separator for Path and Query Parameters in the website URL.

Parameters

URL Parameters contain a key and a value, separated by “\=“. It can accept multiple parameters each separated by “&“.

Fragment or Anchor

They are placed with a “#“ in the end of a URL. It provides a direct access to a specific place on the page of the website, convenient for lengthy web pages.

DNS resolution

Once we enter a URL on the browser search bar and submit it, a web URL is converted into an IP address through a process called DNS Resolution.

What is a DNS (Domain Name Server)?

Like we have contacts in our Contacts/Phonebook application on our mobile, similarly the DNS is like a phonebook of the Internet. DNS translates Domain names to IP addresses so browsers can load the resources over the internet.

How Does DNS work?

Let’s understand the process of DNS resolution. There are 4 DNS servers involved in resolving the domain name of a website as shown below.

DNS Resolver

When URL is loaded, browser sends the request (For ex., google.com), then it travels through the internet and sent to the DNS server. The request is first received by DNS resolver. It can be thought of like a librarian who is asked to find a particular book somewhere in a library. It queries a DNS Root Nameserver.
DNS Root Nameserver

This server gives information about the nearest Root Nameserver. It serves as a reference to the other more specific locations. It acts like an index in a library that points to a rack of books. There are total 13 Root Nameservers in the world, please check at https://root-servers.org/. It requests to the TLD Nameserver (For ex., .com).
TLD Nameserver

It stores information for domain names with a common top-level domains such as .com, .gov, etc. It can thought of like a specific rack of books in a library. It sends the information of specific top-level domain to the Authoritative Nameserver.
Authoritative Nameserver

It stores information about the domain names and their associated IP addresses. It acts as a dictionary for the books in a rack and is the final step of DNS nameserver query. It will return the IP address of the requested hostname (For ex., google.com) back to the DNS Resolver.

The DNS Server then sends the IP address of the domain name to the Web Browser or Client.

DNS Caching

It involves storing the data closer to the requesting client so that later the DNS query can be resolved earlier and additional queries to the DNS resolver can be avoided. This improves load time, reduces CPU consumption and reduces bandwidth, thereby improving the performance and reliability of the data requests.

The DNS caching can be done on browser or at operating system level. By default, the modern web browsers are designed to cache the DNS records for some amount of time.

Establishment of TCP/IP connection

TCP connection is the cornerstone of reliable communication on the internet. It also ensures security and ordered delivery of the data between the devices. TCP uses three-way handshake for the effective connection establishment. This handshake actually makes the TCP connection reliable. Before actually delving into the Three-way Handshake, let’s look at the TCP Header.

TCP Header

The TCP Header is an essential component of TCP protocol. It provides necessary information required for handling the delivery of data reliably. Let’s see what are all components of TCP Header.

Source and Destination Ports

These are 16-bit fields specifying the source and destination ports. They help in correct routing of the data.
Sequence Number

This 32-bit field is like a serial number for every byte of data sent. It ensures the order of the data is correct when received, reducing the chances of error or data loss.
Acknowledgment Number

This 32-bit field confirms the successful receival of data. It tracks the acknowledgment of received data.
Data Offset and Reserved Bits

The 32-bit Data Offset field specifies the length of the TCP Header. Reserved bits are reserved and used for future extensions.
Control Flags

TCP uses several Control Flags to manage different aspects of communication. Most crucial flags are SYN (Synchronize) and ACK (Acknowledgment).

Three-way Handshake

It’s the key part of how devices will communicate with each other. Now, let’s look at the handshaking process.

Initiating SYN (Synchronize) Packet

When client initiates a connection, it sends a SYN Packet with a randomly chosen Sequence no.
SYN-ACK (Synchronize-Acknowledgment) Packet

The server then acknowledges the SYN packet by sending a SYN-ACK packet. The acknowledgment number corresponds to the received sequence number from the client incremented by one.
Final ACK (Acknowledgment) packet

The client, upon receiving the SYN-ACK packet, acknowledges it by sending a final ACK packet. The acknowledgment number corresponds to the received sequence number from the server incremented by one.

This way a reliable TCP connection finally gets established. We can now transfer the data between the client/browser and the server.

Sending HTTP Requests over a TCP connection

Now, as the TCP connection is already present, HTTP requests can be sent securely and reliably.

HTTP (Hypertext Transfer Protocol) is a standard text-based, reliable and stateless protocol, used by browsers to access the web pages from the server.

Formulation of HTTP Request

The HTTP Request consists of Request Line, Method, Headers and optionally a Body/Payload. The Request Line includes the method (GET, PUT, POST, PATCH, DELETE), the URI of the resource and the HTTP version.

Transmitting the Request

Once the HTTP request is composed, it is converted into a series of data packets and sent over TCP connection. TCP ensures that the packets are sent in order, and also checks for errors during transmission.

Server Processing and Response

The server after receiving the data packets, reassembles them to form the HTTP request and processes it. It then send back the response over the same TCP connection. The HTTP Response also follows the same HTTP standard format consisting of Status line, Headers, and a body containing requested data/ error messages.

Sending HTTPS requests over a TCP connection

We already saw how to send data over TCP using HTTP which ensures ordered and reliable transfer. But, what if want are data flow to be completely secured over the network.

For that, we use HTTPS (Hypertext Transfer Protocol Secure), which encrypts the data exchanged between a web client/browser and a web server using SSL/TLS (Secure Sockets layer/Transport Layer Security) protocols. Without HTTPS, sensitive information such as passwords, credit card information, personal data, etc., could get exposed to malicious attacks over the internet network.

How does SSL/TLS Encryption work over TCP in HTTPS?

Once the TCP connection is established after three-way handshake, the SSL/TLS handshake begins. During this handshake, the client and server exchange cryptographic information to generate a shared secret key, which is then used to encrypt all the subsequent communication.

The encryption provided by SSL/TLS handshake ensures that any data sent over the TCP connection is now unreadable/inaccessible to unauthorized parties. It ensures data integrity, confidentiality and security on the internet.

Protocols other than TCP → QUIC

Traditionally, HTTPS used TCP as it’s transport protocol, but can work with other transport protocols such as QUIC.

QUIC (Quick UDP Internet Connections) is a new transport layer protocol developed by Google that used UDP instead of TCP but still ensures reliable and ordered transmission features. It aims at reduced connection setup time, ensuring higher performance and low latency.

Transfer of resources from Server to Client/Browser

Once the SSL/TLS handshake is complete, the secured data flow starts between a Client and a Server.

The server sends the response for the HTTP request from the client, which typically consists of Status Code, Headers and Actual requested data/Response Body, all encrypted using TLS.

Response Status Code

The status code returned by the server can indicate the Success, Failure or Redirection. Below image gives the brief information about the status codes:

Response Headers

It provides the metadata information about the response sent by the server. It contains information like Content Type, Server details, Caching Instructions, etc.

Response Body or Payload

This is an actual content which was requested by the client. It can include HTML, JSON, Images, etc. When there is some problem during processing of the request, then it will contain the error message(s).

Summary

Let’s summarize everything we learned in this article.

We understood the complete flow of data from the Browser to the Server on the internet. We saw the components of a Request URL, how DNS resolution works, DNS caching, how TCP/IP connection establishes using a three-way handshake, how HTTP/HTTPS connection works, how our data can be secured using SSL/TLS encryption, and finally about the structure of the server response.

The whole process is well formulated and followed using different protocols which are widely accepted across the globe. Now, we are clear about what actually happens behind the scene when we go to a website on the browser.

In the end, I would like to request you to provide your valuable feedback on this article, and do highlight mistakes.

Thank you so much for being with me till the end of this article. Hope you enjoyed it.