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

To understand why that is the case, recall that every TCP packet carries a unique sequence number when put on the wire, and the data must be passed to the receiver in-order (Figure 2-8). If one of the packets is lost en route to the receiver, then all subsequent packets must be held in the receiver’s TCP buffer until the lost packet is retransmitted and arrives at the receiver. Because this work is done within the TCP layer, our application has no visibility into the TCP retransmissions or the queued packet buffers, and must wait for the full sequence before it is able to access the data. Instead, it simply sees a delivery delay when it tries to read the data from the socket. This effect is known as TCP head-of-line (HOL) blocking.

So HOL blocking exists because TCP guarantees in-order delivery. But here the user igrigorik says that SPDY allows for the packet to come in different order. But isn't SPDY just a HTTP replacement? Meaning it still runs over TCP (from here).

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.