Implement HTTP/1.1 Persistent Connections (Keep-Alive)

Persistent Connections

HTTP/1.1 defaults to keep-alive: one TCP connection on port 80 serves multiple requests. For example, a browser fetches /index.html, then /style.css, then /logo.png over the same socket without repeating the three-way handshake.

Framing with Content-Length

The client must know where each response ends:

• Content-Length: 1234 tells the client to read exactly 1234 bytes
• Without it, the client reads until the connection closes
• Transfer-Encoding: chunked is the alternative for dynamic content

Either side can terminate with Connection: close.

Connection Lifecycle

1. Client opens TCP to 192.168.1.10:80
2. Client sends request with Connection: keep-alive
3. Server responds with body and Content-Length
4. Connection stays open for the next request
5. Either side sends Connection: close to end

Pipelining (sending multiple requests before reading responses) was part of HTTP/1.1 but rarely used in practice because head-of-line blocking on TCP made it risky. Modern browsers open several parallel connections to the same host on port 443 instead of pipelining on one socket.

Why This Exercise

This task requires you to handle multiple requests on one connection. The Slowloris attack from 2009 abused this lifecycle by opening many keep-alive connections and trickling headers slowly to exhaust server connection pools. Production configs like nginx's keepalive_timeout and Apache's KeepAliveTimeout tune the same Connection header behavior you implement here on port 80.