HTTP versions

HTTP/1.1 reuses TCP connections (keep-alive) but suffers head-of-line blocking: one slow response blocks others on the same connection. HTTP/2 multiplexes many streams over one TCP connection with binary framing and header compression (HPACK). HTTP/3 uses QUIC over UDP — per-stream loss recovery reduces cross-request blocking.

| Version | Transport | Multiplexing | Head-of-line | |---------|-----------|--------------|--------------| | HTTP/1.1 | TCP | Sequential per connection | Per connection | | HTTP/2 | TCP | Yes, shared TCP | TCP-level still possible | | HTTP/3 | QUIC/UDP | Yes | Largely per-stream |

Node's built-in `http` module speaks HTTP/1.1; HTTP/2 requires `node:http2`. Reverse proxies often terminate HTTP/2 or HTTP/3 toward clients and speak HTTP/1.1 or HTTP/2 upstream.

On interviews: explain when HTTP/2 helps API latency; why TLS is effectively required for HTTP/2 in browsers; and deployment implications for load balancers.

Common pitfalls: enabling HTTP/2 without tuning connection limits; assuming multiplexing removes all latency; debugging with curl defaults that hide HTTP/2 behavior.

The trade-off is balancing simplicity, performance, safety, and operability — name which axis you optimized and what cost you accepted.

Checklist:

• Contrast connection reuse in 1.1 vs multiplexing in 2/3.
• Name where termination happens in your stack.
• Know Node module boundaries for HTTP/2.
• Test with tools that speak the client protocol.