DEV Community

Jacopo Carosi (TheEdgeOfDev)
Jacopo Carosi (TheEdgeOfDev)

Posted on • Originally published at theedgeofdev.link on

Web Request Journey

#webdev #networking #learning

Considering that Front-end developers constantly work with concepts like lazy loading and asynchronous requests, they rarely take the time to consider
what is really happening behind the scenes of the Web.

So, I decided to summarize the journey that a data packet usually takes from a client to a server, step by step.

Note: This article is not meant to replace deep foundational knowledge like the OSI model or TCP/IP model, which are covered in specialized courses.
Rather, the article aims to be a conceptual map to get a high-level understanding of the main actors involved when we send a request to a server and receive a response.

Starting from the Browser

Everything begins on your computer or mobile device the moment you open your favorite browser (Firefox, Chrome, Safari).

You type a URL (e.g., www.example.com) into the address bar or click on a link that opens a web page.

Now the Browser performs several checks on various caches:

  1. Browser Cache Check: first, it checks its local cache to see if the page (or parts of it like images, CSS, JavaScript) was already downloaded and hasn't expired. If it finds a valid version it will use that, significantly speeding up load time.

  2. Browser DNS Cache: checks if the IP address is in the browser's DNS cache.

  3. Operating System DNS Cache: if not in the browser, it checks the OS DNS cache.

  4. Local Router Cache: may have its own DNS cache.

If none of the caches (or only part of them) can generate 100% of the page, it moves to the following steps:

  1. DNS Resolution (Domain Name System): if the page isn't cached or the IP is unknown, the browser must translate the domain name (e.g., www.example.com) into a numeric IP address (e.g., 93.184.216.34). It does so by querying the Internet Service Provider's DNS servers.

  2. Authoritative/Root DNS Servers: if the ISP doesn't know the domain, it queries higher-level DNS servers until it finds the authoritative server for that domain, which returns the correct IP.

  3. Establishing TCP/IP Connection: once the IP is obtained, the Browser establishes a connection with the server. Most web traffic uses the TCP (Transmission Control Protocol). This happens via a process called the "Three-Way Handshake":

  • SYN: browser sends a SYN (synchronize) packet to initiate a connection.
  • SYN-ACK: server responds with a SYN-ACK (synchronize-acknowledge) packet.
  • ACK: browser responds with an ACK (acknowledge) packet. Now the connection is established! 🤝

  1. TLS/SSL Handshake (for HTTPS): if the URL starts with https://, a secure connection is required. After the TCP handshake, a TLS/SSL Handshake occurs to encrypt the exchanged data. Browser and server exchange messages to verify the server's identity via SSL/TLS certificate, agree on encryption algorithms, and generate secret session keys.

    This ensures the data is unreadable to anyone intercepting it (in theory).

  2. Sending the HTTP Request: now the Browser sends the actual HTTP request, which includes:

  • HTTP Method: GET, POST, PUT, DELETE, etc.
  • Path: specific resource being requested (e.g., /page.html, /api/users).
  • HTTP Protocol Version: (e.g., HTTP/1.1, HTTP/2, HTTP/3).
  • Headers: extra info like browser type (User-Agent), accepted content types (Accept), cookies, etc.
  • Body: optional, mainly for POST or PUT to send data (e.g., form input).

Go to full article

Top comments (0)