SeniorDesignCommonNot answered yet
An application calls an HTTP API over the network. Walk through, end to end, everything the system does to deliver that request and return the response — from the application's call down through the operating system and network stack, across the physical network, to the server and back. Cover how the destination is resolved, how the connection and any encryption are established, how the data is wrapped as it descends the stack, and where intermediaries on the path get involved.
Request traverses: (1) app API call; (2) OS socket + TCP/IP stack; (3) DNS (cache → stub → recursive → authoritative); (4) TCP 3-way handshake; (5) TLS if HTTPS; (6) HTTP request; (7) ARP, routing, NAT, load balancer; (8) server processing; (9) response reverses. Encapsulation: HTTP body → TCP segment → IP packet → Ethernet frame.
- ✗Skipping DNS latency in estimates — a cold DNS lookup adds 20–200 ms; OS cache, browser cache, and EDNS0 TTL management are critical for performance
- ✗Not accounting for connection establishment cost — TCP + TLS adds 1.5–2 RTTs; connection pooling and keep-alive eliminate this overhead for subsequent requests
- ✗Ignoring the OS TCP buffer and Nagle's algorithm — small writes are coalesced by default;
TCP_NODELAYdisables Nagle for latency-sensitive protocols
- →At what point does ARP get involved, and how does it differ for a cross-subnet request?
- →How does a reverse proxy (nginx) change the request lifecycle compared to a direct connection?
Contents
Network Request Lifecycle
Flow Diagram
Application
│ 1. HTTP client calls connect() + write()
│
OS / Kernel
│ 2. Syscall → socket created
│ 3. DNS: getaddrinfo()
│ └─ /etc/hosts → OS cache → stub resolver → recursive DNS (ISP)
│ └─ ROOT → TLD → authoritative DNS → A/AAAA record
│ 4. TCP connect() → 3-way handshake (SYN / SYN-ACK / ACK)
│ 5. TLS handshake (ClientHello…Finished) — ~1 RTT in TLS 1.3
│ 6. HTTP/1.1: GET /path HTTP/1.1\r\nHost: …\r\n\r\n
│ or HTTP/2: HEADERS + DATA frames
│
Network stack
│ 7. TCP segmentation → IP packet (TTL=64, src/dst IP)
│ 8. IP → route lookup → ARP for next-hop MAC
│ 9. NIC → Ethernet frame (src MAC, dst MAC, EtherType)
│
Network (physical path)
│ 10. L2 switch → L3 router → NAT (rewrites src IP:port)
│ 11. Load balancer / reverse proxy (nginx/HAProxy)
│ └─ TLS termination, adds X-Forwarded-For
│
Server Application
│ 12. accept() → request processing → build response
│ 13. Response traverses the same path in reverseLatency by Stage
| Stage | Typical latency |
|---|---|
| DNS (cold) | 20–200 ms |
| DNS (OS cache) | < 1 ms |
| TCP handshake | 1 RTT (10–100 ms) |
| TLS 1.3 handshake | 1 RTT |
| TLS 1.2 handshake | 2 RTT |
| HTTP request + response | server-dependent |
| With HTTP keep-alive | transmission RTT only |
Contents
