How understanding TCP made me a better web developer
·2 min read ·Computer Science · Performance · Web Development
HTTP is the protocol web developers live in. But HTTP runs on top of TCP, and understanding what TCP does—and what it costs—explains a lot of web performance decisions that otherwise seem arbitrary.
The Three-Way Handshake
Before a single byte of HTTP data can flow, TCP establishes a connection:
Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK
Three round trips before the server sees your GET request. On a 50ms round-trip connection, you're waiting 150ms before anything starts. This is why latency matters more than bandwidth for the first load of a resource.
Keep-Alive
HTTP/1.1 introduced Connection: keep-alive to reuse TCP connections across multiple requests. Instead of paying the handshake cost for every resource, the connection stays open.
HTTP/2 went further: one TCP connection, multiplexed requests. Multiple requests in flight simultaneously without the head-of-line blocking that affects HTTP/1.1.
Why This Explains Real Decisions
Why HTTPS adds latency: TLS adds 1-2 more round trips on top of the TCP handshake. HTTP/2 + TLS session resumption reduces this, but the cost is real.
Why CDNs help: A CDN puts a server closer to the user, reducing round-trip time. On a 200ms connection, the three-way handshake costs 600ms. On a 10ms connection, it costs 30ms.
Why HTTP/2 push matters for mobile: Mobile connections have higher latency and lower bandwidth. Reducing round trips through HTTP/2 multiplexing and server push has more impact on mobile than on desktop.
The Practical Takeaway
When you're diagnosing web performance, understand what's happening before your application code starts. DNS lookup, TCP handshake, TLS negotiation—all of this happens before the server processes your request. The browser devtools network tab shows this breakdown. Read it.