Request Lifecycle & Transport Protocols
Tracing a network packet from socket allocation down through TCP handshake, TLS 1.3 negotiation, kernel socket buffers, and HTTP/2 application stream multiplexing.
1. Journey of a Network Packet
When an application makes a request, operating system abstractions hide multiple transport layers. Use the interactive workflow diagram below to step through each phase from browser write to server execution:
Host domain "api.complexity.io" is translated into machine routable IP address "198.51.100.24".
Checks OS /etc/hosts cache and invokes getaddrinfo() POSIX syscall.
2. The 5-Tuple & Kernel Sockets
On Unix and Linux operating systems, every network connection is exposed as a file descriptor backed by a kernel socket. The OS kernel uniquely identifies every TCP socket connection via the 5-tuple:
Because the client port is dynamically allocated from the ephemeral port range (`32768–60999` by default on Linux), a single server listening on port 443 can easily sustain tens of thousands of simultaneous connections as long as each client socket has a distinct source port or IP.
3. TCP Handshake & Connection Overhead
Before a single byte of HTTP payload can be transmitted, the client and server must agree on initial sequence numbers and window sizes via the three-way handshake:
- SYN: Client sends an initial sequence number `ISN_c`.
- SYN-ACK: Server acknowledges with `ACK = ISN_c + 1` and provides its own `ISN_s`.
- ACK: Client acknowledges `ISN_s + 1`. The socket state transitions to `ESTABLISHED`.
4. TLS 1.3 Cryptographic Handshake
Under TLS 1.2, cryptographic negotiation required two additional round trips. TLS 1.3 reduced this overhead to a single round trip (1-RTT) by combining cryptographic parameter negotiation into the initial ClientHello message using Diffie-Hellman ephemeral key exchange:
Client Server │ │ │─── ClientHello (Key Share, Cipher Suites) ───────►│ │ │ Calculates Shared Secret │ │ Generates Session Keys │◄── ServerHello, Certificate, Finished ────────────│ │ │ │─── [Encrypted Application Data: GET /api/v1] ────►│ Ready!
5. HTTP/1.1 vs HTTP/2 vs HTTP/3
The application layer protocols evolved specifically to eliminate latency bottlenecks:
- HTTP/1.1: Sequential pipelining suffered from Head-of-Line (HoL) blocking. If response #1 hung, subsequent responses on that socket were blocked.
- HTTP/2: Introduced binary framing and bidirectional stream multiplexing over a single shared TCP socket.
- HTTP/3 (QUIC): Replaced TCP with UDP-based QUIC, eliminating transport-layer Head-of-Line blocking when packets are lost.
6. Engineering Knowledge Verification
Why does HTTP/2 still suffer from Head-of-Line blocking at the TCP transport layer when a single packet is lost on a lossy cellular network?
7. Key Takeaways & References
- 5-Tuple Connection Identity: Sockets are bound to protocol, source IP/port, and destination IP/port.
- Connection Re-use: Handshake overhead makes persistent connections and pool reuse essential for low latency.
- Stream Multiplexing: HTTP/2 interleaves frames over one socket; HTTP/3 eliminates TCP HoL blocking using UDP.