What happens when you visit a website from your browser

$alaedine\x42$

9 min readSep 5, 2021

Hello curious people of the internet. In this article we will explore step by step the process of requesting a web page from a browser ( yes I say from your browser because you can visit a page from a terminal or a script too).
Before getting started we have to explore some key terminology to make the post easier to read

Server: Another word for a computer or computer program. Can refer to either hardware or software. Servers provide functionality for other devices. In the context of this article, usage of the term “server(s)” will refer to the computer system(s) hosting www.example.com.
Client: Also a computer or computer program, but one that can access services and functionalities hosted on a server. Most familiarly, clients are the personal devices — laptops, smartphones, etc. — that we use to access services through the internet, among other things. In the context of this article, usage of the term “client” will refer to the web browser.
Protocol: Or, more specifically, communication protocol — a general term for a system of rules, or method, for transmitting data between two devices. The Open System Interconnections (OSI) model, the conceptual model used to describe telecommunications between computers, consists of a myriad of protocols.

Now let’s get started. So you open your browser and decide to visit your favorite website https://www.holbertonschool.com you type the address in search bar and get the page directly. easy right ?? well there is a lot happening behind the scenes after you typed enter.

URL PARSING:

first your web browser will take the input and see if it’s a keyword or a URL.
If it doesn’t start with the format protocol:// then it will be considered as search key word else it will proceed differently by splitting your input

in our case the protocol will be HTTPS, hostname is holbertonschool.com, the port will be by default 443 because we are using HTTPS(other ports are used for other protocols). and the path-and-file-name will be thefile provided by the root of the web server.

Finally, the web browser checks caches. Where it keeps a running storage of recent hostnames that it has already resolved.

DNS RESOLUTION:

now that our URL is parsed and splitted, for this step we will focus on hostname.

the browser doesn’t really know what is holbertonschool.com actually the browser only understand IP addresses it is possible to give web browsers exact IP addresses to access websites — in fact, this would save quite a bit of work — however, we humans have a difficult time remembering 4–12+ digit strings of numbers, let alone the dozens upon dozens of them we frequent every day.

a super hero called DNS will help the browser to identify what is the IP address of the hostname. Domain Name Servers are like an address book for websites. When you type a web address in your browser, the browser looks at the DNS to find the website’s real address before it can retrieve the website. The browser needs to find out which server the website lives on, so it can send HTTP messages to the right place (see below). This is like looking up the address of the shop so you can access it.

So instead of remembering every site IP address we just remember the domain name and we let DNS do all the other work.

before we explain this process we have to know few things:

Root level domain: is a name server service that networked computers may use to query the Domain Name System (DNS), the decentralized Internet naming system, in place of (or in addition to) name servers operated by the local Internet service provider (ISP) to which the devices are connected
Top Level Domain Servers: Top-Level Domain (TLD) Name Servers are a group of servers that facilitate the generation of websites’ Internet Protocol (IP) addresses. Without these servers, it would be practically difficult for Domain Name System to function properly. Each domain name includes a top level domain (TLD) like .COM or .NET, and a subdomain of that top level domain. For example, take a look at the domain name for this website: Lifewire.com. The TLD is .com in this example, and lifewire is the subdomain.

DNS resolver: A DNS resolver (recursive resolver), is designed to receive DNS queries, which include a human-readable hostname such as “www.example.com", and is responsible for tracking the IP address for that hostname.

now let’s assume that the web browser didn’t find a corresponding IP address of the host name in it’s cache. it will send it to the configured DNS resolver ( Typically your internet service provider but it can be configured to check another one too) . to be resolved into its IP through the Domain Name System.

here is a brief explanation of how the complete DNS resolution happens. the resolver contacts both the top-level domain server (.com, in our case) and domain registrar before successfully resolving the hostname into its corresponding IP address. When it’s all said and done, the client knows the IP address corresponding to www.holbertonschool.com — we'll call it 98.98.98.98 in our example ( this is not actually the IP of the website).

Establishing TCP communication:

so now that the client knows the IP address of the hostname it’s time to establish communication between them. contact between the client (again it’s our browser) and the server hosting www.holbertonschool.com will be done via TCP.

TCP: stands for Transmission Control Protocol a communications standard that enables application programs and computing devices to exchange messages over a network. It is designed to send packets across the internet and ensure the successful delivery of data and messages over networks. An alternative transport-layer protocol, User Datagram Package (UDP) is faster, but less reliable — packet delivery is not double-checked. UDP is typical of streaming services where instant content takes priority; TCP is used most everywhere else.

Getting the SSL certificate:

now that the server and client are ready to communicate. the client will first check if the server provides some security Here is a very simplified explanation:

Your web browser downloads the web server’s certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.

Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server’s certificate was indeed signed by the trusted certificate authority.

The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.

Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.

Load Balancer:

well technically you don’t communicate directly with the server hosting www.holbertonschool.com most of infrastructures depends on load balancers. A load balancer is an intermediary responsible for handling this traffic-splitting work. A load balancer is a software that can be configured either on the same server as that hosting web content or on a server all its own. One such common and free load balancer software is HAProxy.
the resolved IP address of www.holbertonschool.com was truly the IP address of the load balancer server. the client completed the TLS handshake with this load balancer server, thus making it the TLS termination proxy. Almost like a post office, this server, which we’ll imagine is configured with a round-robin algorithm on HAProxy, was the receiver of our HTTP GET request. HAProxy took the request, pulled up the IP address of the next web server in its queue, and sent it off that way.

HTTPS REQUEST:

so know the client know that it’s safe to communicate with the web server and HTTP request will be sent to the web server. but why did I type HTTPS ?? well the S in HTTPS stands for Security and it’s added by a TLS layer on top of the HTTP. The browser will send a GET request asking for holbertonschool.com web page. If you’re entering credentials or submitting a form, this could be a POST request. This request will also contain additional information such as browser identification (User-Agent header), types of requests that it will accept (Accept header), and connection headers asking it to keep the TCP connection alive for additional requests. It will also pass information taken from cookies the browser has in store for this domain.

FIREWALL:

We are very, very close to retrieving our web page. I pinky promise. But, before our GET request is officially, finally received by the host server, the message goes through one last security check — a firewall.

Through the TLS handshake, our browser came to an agreement with the load balancer server as to how to encrypt messages as they are passed back-and-forth. TLS achieves three crucial security purposes — privacy, integrity, and identification — yet it fails to account for a fourth — honesty.

Firewalls are hardware, software, or an implementation of both that filter all traffic coming into and out of a server. TLS is effective for preventing data from being intercepted mid-transmission. Yet, it assumes that received data is coming from a trusted source. Firewalls make no such assumptions, and utilize a combination of packet filters, application gateways, circuit-level gateways and proxy servers to make certain that a packet does not contain viruses or malicious hardware.

HTTP RESPONSE — Host Server:

The server contains a webserver (i.e., Apache, nginx) that receives the request from the browser and passes it to a request handler to read and generate a response. The request handler is a program (written in ASP.NET, PHP, Ruby, etc.) that reads the request, its’ headers, and cookies to check what is being requested and also update the information on the server if needed. Then it will assemble a response in a particular format (JSON, XML, HTML).

Delivery of a web page works as follows:

A GET request is received by the web server. The web server pulls up the file configured at the given location (in our example, the HTML file configured at the root (/) of the machine).
If the file contains dynamic content, the application server is run (ie. the corresponding scripts are run). The result of these scripts is inserted into the web page.
If the dynamic content involves stored data, the Python scripts queries from the database server.
The web server delivers the web page.

Application server:

application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).