SPDY Head of Line blocking

Question

I\'m having troubles with understanding how SPDY can solve HOL blocking.

Quote from: http://chimera.labs.oreilly.com/books/1230000000545/ch02.html#TCP_HOL

Answer 1

HOLB has several causes, of which packet retransmission is one, but it's not the one relevant to HTTP and SPDY. The one relevant to HTTP and SPDY is the fact that in HTTP 1.x multiple requests must be responded in order.

Imagine a HTTP client that sends to a server 2 requests over the same TCP connection, and that the first response is "large" in content length while the second response is "small" in content length.

Due to the nature of the HTTP 1.x protocol, the second response must wait for the first response to complete. The second response is head-of-line blocked by the first response.

With multiplexed protocols like SPDY and HTTP 2, instead, this type of HOLB does not exist, because the second "small" response can arrive to the client well before the first "large" response (they can even be interleaved).

The diagram of the question you referenced above explains it graphically.

Ilya, in his response, was not referring to TCP packets, but to HTTP "packets" when he was saying that they can be out of order. Imagine a "packet" made of the HTTP headers, and a "packet" made of POST data to be uploaded to the server (or, in a response, "packets" made of the data to be downloaded to the client). In HTTP 1.x, these HTTP "packets" must be in order (first all the HTTP "packets" of request 1, then all the HTTP "packets" of request 2; or first all the HTTP "packets" of response 1 and then all the HTTP "packets" of response2), while in SPDY and HTTP 2 they may be out of order or even interleaved.

The lack of this kind of HOLB in SPDY and HTTP 2 makes these protocols more efficient than HTTP 1.x.

The HOLB caused by TCP retransmissions affects any TCP based protocol, included multiplexed protocols like SPDY and HTTP 2, and duplex protocols like HTTP 1.x.