title: SPDY Head of Line blocking
body: <p>I'm having troubles with understanding how SPDY can solve HOL blocking.</p>
  
  <p>Quote from: <a href="http://chimera.labs.oreilly.com/books/1230000000545/ch02.html#TCP_HOL" rel="nofollow noreferrer">http://chimera.labs.oreilly.com/books/1230000000545/ch02.html#TCP_HOL</a></p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>So HOL blocking exists because TCP guarantees in-order delivery. But <a href="https://stackoverflow.com/questions/10480122/difference-between-http-pipeling-and-http-multiplexing-with-spdy">here</a> 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 <a href="http://www.chromium.org/spdy/spdy-whitepaper" rel="nofollow noreferrer">here</a>).</p>