DEV Community

Cover image for How web browsers work - fetching data (part 2, with illustrations)🚀
Arika O
Arika O

Posted on • Updated on

How web browsers work - fetching data (part 2, with illustrations)🚀

In the last article we talked about navigation, the first step the browser takes to display the websites. Today we'll move onto the next step and see how resources get fetched.

2. DATA FETCHING

HTTP Request

After we established a secure connection with the server, the browser will send an initial HTTP GET request. First, the browser will request the markup (HTML) document for the page. It will do this using the HTTP protocol.

HTTP (Hypertext Transfer Protocol) is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser.

Image description

The method - e.g: POST, GET, PUT, PATCH, DELETE etc
URI - stands for Uniform Resource Identifier. URIs and used to identify abstract or physical resources on the Internet, resources like websites or email addresses. An URI can have up to 5 parts:

  • scheme: used to say what protocol is being used
  • authority: used to identify the domain
  • path: used to show the exact path to the resource
  • query: used to represent a request action
  • fragment: used to refer to a part of a resource
// URI parts
scheme :// authority path ? query # fragment

//URI example
https://example.com/users/user?name=Alice#address

https: // scheme name
example.com // authority
users/user // path
name=Alice // query
address // fragment
Enter fullscreen mode Exit fullscreen mode

HTTP header fields - are a list of strings sent and received by both browser and server on every HTTP request and response (they are usually invisible for the end-user). In the case of requests, they contain more information about the resource to be fetched or about the browser requesting the resource.

If you want to see how these headers look like, go to Chrome and open the Developer tools (F12). Go to the Network tab and select FETCH/XHR. In the screen shot bellow I just made a Google search for Palm Springs and this is how the request headers looked like:

Image description

HTTP Response

Once the server receives the request, it will process it and reply with an HTTP response. Attached to the body of the response we can find all relevant headers and the contents of the HTML document we requested.

Image description

Status code - e.g: 200, 400, 401, 504 Gateway Timeout etc (we aim for a 200 status code, since it tells us everything went ok and the request is successful)
Response header fields - hold additional information about the response, like its location or about the server providing it.

An example of an HTML document can look something like:

<!doctype HTML>
<html>
 <head>
  <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>This is my page</title>
  <link rel="stylesheet" src="styles.css"/>
  <script src="mainScripts.js"></script>
</head>
<body>
  <h1 class="heading">This is my page</h1>
  <p>A paragraph with a <a href="https://example.com/about">link</a></p>
  <div>
    <img src="myImage.jpg" alt="image description"/>
  </div>
  <script src="sideEffectsScripts.js"></script>
</body>
</html>
Enter fullscreen mode Exit fullscreen mode

For the same google search I mentioned earlier, this is how the reponse headers look like:

Image description

If we take a look at the HTML document, we see that it refrences different CSS and Javascript files. These files will no be requested until the browser won't encounter these links but this doesn't happen in this step, but in the parsing phase which we'll discuss in the next articles. At this point in time, only the HTML is requested and received from the server.

The response for this initial request contains the first byte of data received. Time to First Byte (TTFB) is the time between when the user made the request (by typing the website's name in the address bar) and the receipt of the first packet of HTML (which is usually 14kb).

TCP Slow Start and congestion algorithms

TCP slow start is an algorithm that balances the speed of a network connection. The first data packet will be 14kb (or smaller) and the way it works is that the amount of data transmitted is increased gradually until a predetermined treshold is reached. After each packet of data is received from the server, the client responds with an ACK message. Since the connection has a limited capacity, if the server sends too many packets too quickly, they will be dropped. The client won't send any ACK messages so the server will interpret this as congestion. This is where congestion algorithms come into play. They monitor this flow of sent packets and ACK messages to determine a rate at which traffic is optimal and create a steady traffic stream.

Refrence materials:

Discussion (7)

Collapse
faruq_jada profile image
Faruq Ahmed

When will you release the third part of the series?

Collapse
arikaturika profile image
Arika O Author

I think tomorrow. The illustrations take quite a bit of time to be made :).

Collapse
faruq_jada profile image
Faruq Ahmed • Edited on

we are patiently waiting, thanks!
Wish you best of luck

Collapse
nghihs profile image
Hồ Sỹ Nghi

looking forward to the next part. Thanks for sharing!!

Collapse
arikaturika profile image
Arika O Author

Glad it helped. The next part should be ready these days 🤞.

Collapse
ismailcherri profile image
Ismail Cherri

Hi, great article. There is a typo in this line:

These files will no be requested until the browser won't encounter these links

Collapse
mat3uszkek profile image
Mateusz Skrobiś

great article :)