Summary
HTTP evolved from simple request-response over new TCP connections to multiplexed streams and then QUIC-based transport in HTTP/3.
Interview Points
- HTTP/1.0: one request per connection.
- HTTP/1.1: persistent connections, but application-level head-of-line blocking.
- HTTP/2: multiplexing, binary framing, header compression, but TCP-level head-of-line blocking remains.
- HTTP/3: runs over QUIC on UDP, reducing transport-level head-of-line blocking.
- gRPC commonly uses HTTP/2; browsers negotiate versions transparently.
2-3 Minute Interview Script
“HTTP versions mainly improve latency and connection efficiency. HTTP/1.0 opened a new TCP connection per request, which was expensive. HTTP/1.1 added keep-alive, but requests could still block behind each other.
HTTP/2 introduced multiplexing over a single TCP connection, binary framing, and header compression. That solved a lot of application-level blocking and became a strong foundation for gRPC. The remaining issue is TCP head-of-line blocking: packet loss can block all streams on that connection.
HTTP/3 moves HTTP onto QUIC over UDP. QUIC provides reliability, encryption, congestion control, and independent streams in user space, so packet loss affects less of the connection.
In architecture, I would use HTTP/2 or HTTP/3 at the edge where supported, and HTTP/2 with gRPC for typed internal service communication when it fits the use case.”
Follow-Ups
- Why does HTTP/2 still have head-of-line blocking?
- Where does gRPC fit?