The Life of a Request: An Engineering Deep Dive into Web Network Flow

DNS Resolution → TCP Handshake → TLS Handshake → Network Transit → Server Processing → Browser Rendering

When you type a URL into a browser and press enter, you trigger a complex choreography involving dozens of systems, multiple networking protocols, and thousands of miles of infrastructure. To the average user, it’s magic. To an engineer, it is a sequence of precisely defined steps managing state, latency, and security.

This article dissects this process, moving from the browser’s high-level intent down to the raw socket handling on the server.

What we’re going to learn:

Phase 1: How DNS resolution translates a human-readable domain into a routable IP address using hierarchical, cache-driven lookups.

Phase 2: How a reliable TCP connection is established using the three-way handshake and why it impacts latency.

Phase 3: How TLS secures the connection through certificate verification and symmetric key negotiation.

Phase 4: How HTTP requests traverse global network infrastructure such as CDNs, WAFs, and load balancers.

Phase 5: How a backend server stack (Nginx, PHP-FPM, application runtime) processes a request and generates a response.

Phase 1: The Address Lookup (DNS Resolution)

Before any data can be transferred, the browser needs to know the destination’s location. Humans use names (e.g., google.com); networking equipment uses numerical IP addresses (e.g., 142.250.190.78 or IPv6 equivalents). The Domain Name System (DNS) is the distributed, hierarchical database that bridges this gap.

DNS is designed heavily around caching to reduce global network load and latency.

Step-by-Step Flow:

Browser Cache: The browser first checks its own internal cache of recently visited domains. If found, the process stops here (latency: <5ms). 1.

OS Cache (Stub Resolver): If not in the browser, the OS is queried. The OS maintains its own DNS cache (viewable/flushable via commands like ipconfig /displaydns). 1.

The Recursive Resolver (Usually the ISP): If the IP is not on the local machine, the OS sends a query to its configured DNS resolver. This is usually provided automatically by your ISP via DHCP, though many engineers configure public resolvers like Google (8.8.8.8) or Cloudflare (1.1.1.1).

Engineering Note: This query typically uses UDP on port 53 because it is lightweight and fast, lacking the overhead of TCP connection setups. If the response is too large, it may retry over TCP.

The Iterative Journey: The Recursive Resolver now undertakes the journey on your behalf. It likely has common domains cached. If not, it starts at the top of the hierarchy:

• Root Hints (.): It asks one of the 13 logical Root Server clusters: "Who handles .com?" The root responds with a list of TLD (Top-Level Domain) Name Servers.
• TLD Servers (.com): The recursive resolver asks the .com TLD server: "Who handles google.com?" The TLD server responds with the Authoritative Name Servers for that specific domain (e.g., ns1.google.com).
• Authoritative Servers: Finally, the resolver asks Google’s own name server: "What is the A record (IPv4) or AAAA record (IPv6) for google.com?"
• Final Response: The authoritative server returns the specific IP address. The Recursive Resolver caches this answer based on the TTL (Time To Live) value defined by the domain owner and returns the IP to your OS.

Phase 2: Establishing Transport (TCP 3-Way Handshake)

The browser now has the target IP address. It needs to establish a reliable communication channel. HTTP uses the Transmission Control Protocol (TCP) because TCP guarantees that data arrives in order and without corruption.

A TCP connection is defined by a Socket Pair—a unique combination of IP addresses and port numbers:

{Client IP : Client Random High Port} <—> {Server IP : Server Port 443 (HTTPS)}

To start this connection, a three-step "handshake" occurs to synchronize sequence numbers and ensure both sides are ready to transmit data.

SYN (Synchronize): The client browser chooses a random initial sequence number (let’s call it x) and sends a TCP packet with the SYN flag set to the server’s IP on port 443. It’s saying, "I want to connect, and I will start numbering my data bytes at x." 1.

SYN-ACK (Synchronize-Acknowledge): The server receives the SYN. If it’s accepting connections, it chooses its own random sequence number (y). It sends back a packet with both the SYN and ACK flags set. It acknowledges the client’s sequence number (ACK = x + 1) and proposes its own (SYN = y). 1.

ACK (Acknowledge): The client receives the SYN-ACK. It sends back a final packet with the ACK flag set, acknowledging the server’s sequence number (ACK = y + 1).

At this exact moment, the socket connection is marked as ESTABLISHED.

Engineering Note on Latency: This process takes 1.5 Round-Trip Times (RTT) before any actual data can be sent. If the ping to the server is 100ms, this handshake alone consumes 150ms.

Phase 3: Securing the Transport (The TLS Handshake)

Standard HTTP is sent in plaintext; anyone on the network path (like public WiFi or an ISP) could read the data. HTTPS layers HTTP on top of TLS (Transport Layer Security)—the successor to SSL—to provide encryption, authentication, and integrity.

The TLS handshake happens immediately after the TCP connection is established and before any HTTP data is sent. Its goal is to securely negotiate a fast, symmetric encryption key.

The TLS 1.2/1.3 Flow (Simplified):

Client Hello: The browser sends a message listing the newest TLS versions it supports, supported cipher suites (algorithms for encryption), and some random random bytes. 1.

Server Hello & Certificate: The server chooses the best common protocol version and cipher suite. It sends its SSL Certificate. 1.

Authentication (The Trust Chain): The browser receives the certificate.

It checks: Is the certificate expired? Does the Common Name matches the domain URL?

Crucially, it checks the Digital Signature. The certificate is signed by a Certificate Authority (CA), like Let’s Encrypt or DigiCert. The browser has a pre-installed root store of trusted CA public keys. It uses these root keys to verify that the server’s certificate was genuinely signed by a trusted entity.

Key Exchange (The Hybrid Cryptosystem):

Asymmetric Encryption (Slow): The server’s certificate contains its Public Key. The browser uses this public key to securely encrypt a "pre-master secret" and sends it to the server. Only the server, possessing the corresponding private key, can decrypt it.

Deriving Session Keys (Fast): Both the client and server now have the same pre-master secret and the random bytes exchanged earlier. They run this data through a specific algorithm to generate identical Symmetric Session Keys.

Finished: Both sides send a "finished" message encrypted with the new session key to verify everything worked.

All subsequent HTTP data is now encrypted using this fast, symmetric session key.

Phase 4: Network Transit and Infrastructure

With a secure tunnel established, the browser finally sends the HyperText Transfer Protocol (HTTP) request.

GET / HTTP/1.1Host: google.comUser-Agent: Mozilla/5.0...Accept: text/html...

This request data is segmented into TCP packets, which are wrapped in IP packets. These packets travel the internet backbone. They don’t just fly straight to the server; they pass through various infrastructure layers:

Routers/Switches: Dozens of hops across different ISPs, directing packets based on IP destination. 1.

CDN (Content Delivery Network): Often, the DNS record doesn’t point to the origin server, but to a nearby CDN edge node (like Cloudflare, Akamai, or Fastly).

The CDN terminates the TLS connection.

It checks its cache. If the requested content (images, CSS, or even cached HTML pages) is present, it serves it instantly from the edge, dramatically speeding up the response.

Web Application Firewall (WAF): Before reaching the server, the request might pass through a WAF. The WAF inspects the HTTP request for malicious patterns (SQL Injection attempts, XSS attacks) and blocks them if necessary. 1.

Load Balancer: For popular sites, a single server cannot handle the traffic. A load balancer sits in front of a server farm, distributing incoming requests across multiple healthy servers using algorithms like Round Robin or Least Connections.

Phase 5: Server-Side Processing (The Backend Stack)

The request finally arrives at a specific backend server’s network interface card (NIC). The kernel identifies the destination port (443) and passes the data to the application listening on that port: The Web Server.

We will assume a common modern stack: Nginx as the web server, and PHP-FPM for dynamic content.

5.1. The Web Server (Nginx)

Nginx is high-performance, event-driven software. It receives the encrypted data, decrypts it using the symmetric session keys established in Phase 3, and parses the HTTP request headers.

It makes a decision based on the file extension requested:

Static Content (.jpg, .css, .html): If the request is for a static file present on the disk, Nginx reads the file and sends it straight back into the encrypted tunnel. This is extremely fast.

Dynamic Content (.php): Nginx knows it cannot execute PHP code. It is configured to proxy these requests to a specialized processor.

5.2. The Application Gateway (FastCGI / PHP-FPM)

Nginx connects to the PHP-FPM (FastCGI Process Manager) daemon, usually via a local Unix Socket (faster than TCP localhost).

**The Concurrency Model:**PHP execution is single-threaded. If PHP-FPM were a single process, it could only handle one request at a time, queueing everyone else.Instead, PHP-FPM uses a Master/Worker model.

The Master Process manages the pool and listens for incoming connections from Nginx.

It maintains a "pool" of existing Worker Processes (e.g., 50 workers) already initialized with the PHP interpreter loaded into memory.

Nginx hands the request to the Master, which immediately assigns it to an idle Worker. That specific Worker is now dedicated to this one request until completion. Other requests are handled simultaneously by other workers.

5.3. The Application Execution (Zend Engine)

The chosen PHP Worker process loads the requested PHP script (e.g., index.php for WordPress or Laravel’s front controller).

The Zend Engine (the core of PHP) takes over:

Lexing/Parsing: Reading the human-readable PHP code and converting it into abstract syntax trees. 1.

Compilation: Converting the syntax trees into Opcode (intermediate machine instructions). Note: OPcache is usually used here to store these opcodes in shared memory so subsequent requests skip steps 1 and 2. 1.

Execution: The engine executes the opcodes sequentially.

During execution, the application framework boots up. It might connect to other services:

Database (MySQL/PostgreSQL): The PHP worker opens a new TCP connection to the database server to run SQL queries to fetch article text, user data, etc.

Redis/Memcached: To fetch cached data snippets to avoid hitting the database.

Eventually, PHP generates the final HTML string. It hands this output back to the PHP-FPM worker, which passes it back through the socket to Nginx.

Phase 6: The Response and Rendering

Nginx receives the HTML generated by PHP. It constructs a valid HTTP response header:

HTTP/1.1 200 OKContent-Type: text/html; charset=UTF-8Content-Length: 2543Server: nginx

It attaches the HTML body, encrypts the whole package using the TLS session key, and streams it back down the established TCP connection.

The Browser’s Job:

Decryption: The browser receives the packets, ensures they are in correct TCP order, and decrypts the stream. 1.

Parsing (The Critical Rendering Path):

*   The browser begins parsing the HTML document top-to-bottom.

*   It builds the **DOM (Document Object Model)** tree.

1. Cascade: When the parser finds or tags, it pauses parsing (usually) and fires off new HTTP requests to fetch those assets, repeating much of the network process described above for each file.
2. Rendering: Once it has the HTML (DOM) and CSS (CSSOM), it combines them into a Render Tree and paints the pixels onto your screen.

The webpage is loaded. The TCP connection may be kept open for a short time (HTTP Keep-Alive) in case you click a link, saving the overhead of a new handshake.

---

Frequently Asked Questions (FAQ)

Why does DNS use caching at so many levels?

DNS caching drastically reduces latency, global network traffic, and load on root and authoritative servers. Without caching, every page load would require multiple global lookups.

Why is TCP still used when UDP is faster?

TCP provides ordered delivery, retransmission, and congestion control. HTTP requires reliability; speed optimizations are achieved through techniques like connection reuse, HTTP/2 multiplexing, and TLS session resumption rather than abandoning TCP.

Does HTTPS slow down websites?

The initial TLS handshake adds some overhead, but modern optimizations (TLS 1.3, session resumption, hardware acceleration) make HTTPS effectively mandatory with negligible real-world performance cost.

Why does the browser make so many additional requests after loading HTML?

HTML is only the entry point. CSS, JavaScript, fonts, images, and APIs are fetched separately to enable caching, parallel loading, and reuse across pages.

How do CDNs improve performance if the server is far away?

CDNs serve content from geographically closer edge nodes, reducing round-trip time (RTT) and offloading traffic from the origin server.

Why does PHP-FPM use multiple worker processes?

PHP is single-threaded. Multiple workers allow concurrent request handling, enabling the server to scale under load without blocking.

What happens if one step in the process fails?

The browser aborts the pipeline at the failure point:

DNS failure → site cannot be located

TCP/TLS failure → connection error

Server error → HTTP 4xx/5xx responseEach layer is designed to fail fast and visibly.

Closing Thoughts

What feels like an instant page load is, in reality, a tightly orchestrated pipeline spanning global infrastructure, cryptography, operating systems, and application runtimes. Every millisecond is negotiated, cached, encrypted, routed, processed, and rendered with precision.

Understanding this flow is not just academic—it directly informs better debugging, performance optimization, security decisions, and architectural design. Once you see the system end-to-end, the web stops being “magic” and starts being engineering.