What happens when you type an URL in your browser and press Enter?
Such a fast process and also such an apparently simple question to answer, actually involves a large number of steps that the browser has to follow to show us the web page that we want to access. If you are interested in web application development, this article will be very useful for you to understand how the Internet works behind what we normally see.
To answer this question, we will use as an example a web page that we all use on a daily basis: Google. What happens when we type https://www.google.com in our browser and press Enter?
Parts of an URL
The first thing that will happen is that the browser will separate all the elements that the URL contains to have an order in which to execute the processes that it has to carry out. A URL (Uniform Resource Locator) consists of 4 parts:
- Network protocol: It is used to establish communication rules between two or more machines in order to exchange information. It is the first part of the URL text that appears and can sometimes be hidden from view unless the URL is clicked. Some examples of network protocols are: http, https (a secure version of http), ftp, mailto, file, telnet, etc. It can be identified in the URL because it is separated from the rest of the URL with a colon (:) and in other cases two forward slashes (://) are added to it.
- Hostname: This portion of the URL is what the browser will first use to try to access the site. It can be in IP address format (ex: 8.8.8.8) or network domain format (ex: www.google.com). Later it will be explained what the browser does with this resource.
- Port: It is a number that identifies the place through which the web server will try to listen to the request of our browser. It is not usually shown to the public normally, the browser will connect to the port implicitly depending on the protocol being entered. For example, for an http request, the browser uses port 80, but for an https request, it uses port 443. This is how the browser would then actually interpret the request to sign in to Google (https://www.google .com:443).
- Route to the resource: If we want to access a specific element of the web application, we have to enter its entire route to said resource. It has a format similar to this: “/docs/images/example.png”, and is placed at the end of the URL.
So, inside the Google URL that we want to access, these are its parts:
IP lookup via DNS
Now that we’ve identified the parts of the URL, we can continue.
The browser will then try to identify an IP address that matches the hostname entered. To do this, it will search the cache of the browser and/or the operating system for an IP with which it can connect quickly. If it doesn’t find it, it will look within a DNS server for the “A record” that correctly links the domain with an IP address that the browser needs to connect to. When it finds it, this information is sent back to the browser to finally make the connection request to the web page we are looking for.
TCP/IP connection
After obtaining the IP address of the website to be found, the browser will try to make a connection through the TCP/IP protocol to that address. So, several movements will occur between the layers of this protocol:
- At the application layer, the browser will construct an HTTP request to be read by the server it is trying to connect to. This request contains two parts: request line (the first line) and request header (the rest of the message). The syntax of the request line is as follows:
request-method-name request-URI version-HTTPWhere:
- _request-method-name is the method that the server will be asked to execute. If we only want to access the web page, we must use the GET method.
-_request-URI is the resource we want to access. If the resource is not specified in the URL, the main page will be used by default (/index.html — can also be hidden under a simple /)
-_version-HTTP is the version of HTTP used for the request.
The request header contains various types of value pairs that provide data from the browser, and also the possible resources that are being sought from the web application that you want to access.
In our https://www.google.com example, the full HTTP request will look like this:
GET / HTTP/2 # Request Line
Host: www.google.com # Request Header - The domain we're
# trying to enter
User-Agent: Mozilla/4.0 # Request Header - Our browser version
Accept: */* # Request Header - Preferred format of
# the requested file- At the transport layer, a TCP protocol connection will be initiated, dividing the message sent into small packets with their own identifier each, and thus ensuring that the message reaches its destination complete.
- At the network layer, our machine will use the ARP protocol to determine if the IP we want to connect to is within our local network to send it directly, by consulting the MAC address of the server’s network card.
- At the link layer, once the MAC address of the server’s network card has been identified, we send the message to that address. The server will receive the message and depending on the characteristics of the message and the information on our machine, the server will show us a response.
Using a firewall
To prevent web server attacks, or unwanted user connections, many people choose to protect their servers with firewalls. In this way, they can filter the traffic that comes from different IP addresses and deny access to those who they consider should not connect.
From HTTP to HTTPS
A connection using the HTTP protocol has been found to be insecure from various attacks that soon became common. It can be dangerous if highly sensitive data (such as bank accounts) is transported over this protocol because it can be easily leaked in “plain text”. For this reason, this protocol was reinforced by adding a security layer through an SSL certificate that, through cryptographic methods, manages to transmit the message in a secure way to its destination, preventing possible information leaks from making the content unreadable. obtained from said action. This hardened protocol was given the name of HTTPS. Currently, many web pages are configured to redirect HTTP request traffic to the HTTPS protocol.
Visually, this change causes the icon to the left of the URL to change from this:
To this:
Using a load balancer
If the website we are trying to access usually receives a large amount of traffic, it is possible that a single server does not have the capacity to process all these requests that are arriving, in such a way that it becomes saturated and may stop working. To avoid this overloading of servers, some very popular websites (or, in this case, the most visited site in the world — Google) use not just one, but multiple servers, as well as a load balancer to distribute traffic between them. these servers. This is where a firewall and SSL certificate can be placed in order to capture all traffic (both wanted and unwanted) and safely deliver the information to the web servers. The traffic will then be distributed between the servers using some algorithm that is designated to the load balancer.
HTTP response
Returning to our Google example, once the HTTP GET request is sent from our browser to the servers, this request will be intercepted by the load balancer and will take the request to one of the servers it points to, under the criteria by which is programmed to distribute the load. Then the corresponding web server will return a response to the browser. This response will be preceded by a header that is separated by a blank line from the response body.
This header, like the request message, consists of two parts: a status line and response headers.
The status line syntax is as follows:
HTTP-version status-code reason-phraseWhere:
-_status-code is a 3-digit code that tells us the result of the request. Depending on what your first digit is, you can tell us the following:
- 2XX: The request was delivered successfully.
- 3XX: A redirect to another site or resource occurred.
- 4XX: Request error by client. We are probably trying to access a resource that does not exist (404) or one to which we are prohibited from accessing (403).
- 5XX: Server error processing request.
-_reason-phrase is a brief description of the status-code.
Next, we have the response headers, which, like the request headers, are pairs of values that will be returned to our browser as a result.
So, the header of the response message that our server will receive from Google will look something like this:
HTTP/2 200 OK # Status Line
date: Mon, 24 Jan 2022 03:55:52 GMT # Response Headers from there
# to end
expires: -1
cache-control: private, max-age=0
content-type: text/html; charset=ISO-8859-1
p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
server: gws
x-xss-protection: 0
x-frame-options: SAMEORIGIN
set-cookie: 1P_JAR=2022-01-24-03; expires=Wed, 23-Feb-2022 03:55:52 GMT; path=/; domain=.google.com; Secure
set-cookie: NID=511=ZHHN1zm9uinbOo8Zg4x0RuOEH0Vv1Zdu9Yo-eUw1xrbTzSnaRT5BCuXg31MOrxuYcAZ5fEsFV7dkSKl4WPusfEwDMWs5W_nkL9eqOzPbS3schX3p-5oQAsWTUTs3HEhriREgUkq7aCp6N_5KQk_pR02CwG17Mtr7YUxYw5lfhe0; expires=Tue, 26-Jul-2022 03:55:52 GMT; path=/; domain=.google.com; HttpOnly
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
accept-ranges: none
vary: Accept-Encoding
<!doctype html>...HTTP response body
What is returned in the body of the HTTP response will be the result of the resources that the web application infrastructure needs to deploy to satisfy the request requirements. Three elements are involved in this process:
- The web server, which also did the work of returning the response message header to us, is in charge of sending us the static content (HTML pages, files, images, video, etc.) of the page resource we are trying to access.
- The application server, which is responsible for generating the dynamic content (usually with the help of scripting languages, such as JavaScript) to complete the content of the request. After being generated, it is translated into HTML content and sent to the web server. If the web server needs to save data or return data that previously needed to be saved for future use (for example, your Gmail account details when you try to log in), the application server will call the database. .
- The database is a structure that, as its name indicates, will save all kinds of data from the clients that have interacted with the server, which the owner of the server considers important for its service to work. After saving or retrieving the information saved in this location, the database informs the application server to send the response to the web server.
Finally, the interaction of these 3 elements sends us an HTML code (or PHP in other cases) that our browser will interpret to show us a graphic response of the result, converting unintelligible text like this:
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="es-419"><head><meta content="text/html; charset=UTF-8" http-equiv="Content-Type"><meta content="/images/branding/googleg/1x/googleg_standard_color_128dp.png" itemprop="image"><title>Google</title><script nonce="Kd7o6+HiPgVq/Rzqd/hpzg==">(function(){window.google={kEI:'cRvuYbbbGN695OUPkfKe0A8',kEXPI:'0,202439,11,3,1100083,[...]};google.sn='webhp';google.kHL='es-419';})();[...]
font-size:1px}.gbh{height:0;position:absolute;top:24px;width:100%}@media all{.gb1{height:22px;margin-right:.5em;vertical-align:top}#gbar{float:left}}a.gb1,a.gb4{text-decoration:underline !important}a.gb1,a.gb4{color:#00c !important}.gbi .gb4{color:#dd8e27 !important}.gbf .gb4{color:#900 !important}
</style>[...]
<script nonce="Kd7o6+HiPgVq/Rzqd/hpzg==">(function(){window.google.erd={jsr:1,bv:1517,de:true};
[...]
})();</script>[...]
</body></html>To this:
