Network - rs-hash/Senior GitHub Wiki

"When a user makes a request from their browser—say, by visiting https://example.com—that request undergoes several steps before it reaches the server and the response is returned. Here's a deep dive into that journey across the network stack."

1. Browser → DNS Resolution (Layer 7 + Layer 3)

"First, the browser needs to convert the domain name example.com into an IP address using DNS (Domain Name System). This involves querying recursive DNS servers, potentially hitting a cached entry at the browser, OS, or ISP level. If it's not cached, the query resolves via root → TLD → authoritative name servers, returning an IP like 93.184.216.34."

Important Concepts:

  • DNS TTL (Time to Live) affects how long this IP is cached.

  • DNS over HTTPS (DoH) for privacy is increasingly common.

2. TCP Handshake (Layer 4)

"Once the IP is known, the browser initiates a TCP handshake with the server. This is a 3-step process (SYN → SYN-ACK → ACK) that establishes a reliable connection over which data can be transferred."

If HTTPS is used (which it is), a TLS handshake follows:

  • Key exchange

  • Server certificate validation

  • Negotiation of encryption algorithms

"This part is where SSL/TLS secures the connection. For front-end engineers, this affects initial load time, especially if you’re working on performance budgets or measuring TTFB (Time to First Byte)."

3. HTTP Request Sent (Layer 7)

"After the handshake, the browser sends the actual HTTP request — e.g., a GET /index.html — with headers like User-Agent, Accept, Cookies, etc."

If the server is behind a CDN, the request may terminate at the nearest edge location, reducing latency.

If not cached, the CDN forwards the request to the origin server.

"I often optimize these requests using compression (like Gzip), setting cache headers (like Cache-Control), and minimizing payload size in SPAs or SSR apps."

4. Routing Through the Internet (Network Layer - Layer 3)

"The request packet travels through multiple routers across the internet. Each router looks at the destination IP address and forwards it accordingly. This is where IP routing, NAT (if applicable), and peering come into play."

Packet might be fragmented and reassembled.

If there’s a bottleneck (e.g., undersea cable congestion), latency increases.

5. Server Processing (Application Layer)

"The server receives the request, processes it—possibly hitting a database, computing some logic, or rendering a template—and sends back an HTTP response. This could be static content, JSON from a REST API, or streamed HTML in SSR."

The server might also send Set-Cookie headers or Cache-Control headers.

6. Response Travels Back

"The response is broken into packets, travels back over the same (or different) network path, and reaches the client. The browser assembles the packets, decrypts TLS, parses the headers and body."

7. Rendering in the Browser

"Once the response is received, the browser parses HTML, CSS, and JS. Requests for additional resources (like images, scripts, fonts) are triggered and go through similar cycles."

Browser builds the DOM, CSSOM, and executes JS, eventually painting pixels to the screen.

If HTTP/2 is used, multiple assets can be multiplexed in a single connection.

🧠 Pro-Level Insights (to impress interviewers): CDN Optimization: "By using a CDN like Cloudflare or Akamai, we reduce latency and improve availability by serving content from edge locations closer to users."

Preconnect / DNS-Prefetch: "I use in the head to initiate DNS and TLS earlier, reducing latency."

Waterfall Debugging: "In Lighthouse or DevTools, I can see exactly where latency is introduced — DNS lookup, TCP handshake, TTFB, etc."

🔚 Summary (Optional wrap-up in interview): "So the request flows from the

browser → DNS → TCP/TLS → HTTP → server → and back through routers → browser → rendering.

Understanding this full flow helps me make smart decisions about caching, connection reuse, resource loading, and performance monitoring on the front end."