Notes on HTTP
November 10th, 2024
This is certainly a departure from my prior posts, but I spent some time this evening learning about HTTP and the changes across its various iterations.
I did not write these notes intending to publish them (please pardon any grammatical errors or lack of completeness), but felt compelled to share them in case you find the topic interesting.
---
HTTP/1 used a single request / connection. This means that the entire TCP handshake (SYN → ACK/SYN → ACK) would need to be executed for every request. This was even more cumbersome when TLS was being used.
HTTP/1.1 introduced an improvement with keep-alive connections. This allowed the client to reuse the same connection for consecutive requests, eliminating the overhead of creating a new connection every time. There was a push for pipelining (it never gained much traction apparently), which allowed the client to send multiple requests consecutively, without waiting for the previous request to finish. The problem was that the responses needed to be processed in-order, meaning that if 2 requests were made, response 2 could not be processed until response 1 was processed. This was inefficient in cases where one slow response would block all subsequent responses. This is called Head of Line (HOL) Blocking.
HTTP/2 improved the status quo by introducing the concept of multiplexing and independent (well, somewhat) streams. Multiplexing allows the client and server to use the same connection to handle multiple requests/responses simultaneously. Requests/responses were broken up into frames, each frame corresponding to a stream ID and an order number. This reduced the HOL Blocking imposed by HTTP/1.1’s architecture (frames of response 2 could now be processed prior to the completion of response 1) but couldn’t completely solve the HOL Blocking problem. This is because HTTP/2 still operates over TCP, which means that if one packet for a response is dropped, the entire stream is paused until that packet is received. This is because even though the streams are logically separated, they’re still operating on top of the same TCP connection, which imposes that strict ordering requirement.
HTTP/3 is a significant departure from its predecessors, as it relies on QUIC (Quick UDP Internet Connections) which is build on top of UDP. I’m not going to go into depth here, but some of the key takeaways:
1. HTTP/3 solves the HOL Blocking problem by completely isolating streams from each other, preventing a dropped frame in one stream from delaying the others.
2. Improved handshake — TCP always requires a 3-message handshake, whereas QUIC can use a 0 message handshake (i.e. no handshake) in certain scenarios.
3. QUIC handles connection migration, meaning that if a user changes networks, the connection does not need to be reestablished. This is particularly efficient for mobile users, who may be switching between Wifi and cellular networks frequently.