紧接上篇博客HTTP/2 并没有解决 TCP 的队首阻塞问题，它仅仅是通过多路复用解决了以前 HTTP1.1 管道化请求时的队首阻塞问题。
TCP发生队首阻塞的原因：
HTTP/2虽然可以解决http队首阻塞问题，但是 TCP 层面的队首阻塞是 HTTP/2 无法解决的（HTTP 只是应用层协议，TCP 是传输层协议），TCP 的阻塞问题是因为传输阶段可能会丢包，TCP是一个按序传输的通道,一旦丢包就会等待重新发包，阻塞后续内容传输
TCP的队首阻塞问题，我们经常会在http2协议中去讨论，因为http2中TCP通道很少，可能只有一个
在http2中丢包了会怎么办？
采用HTTP/2时，浏览器一般会在单个TCP连接中创建并行的几十个乃至上百个传输。如果HTTP/2连接双方的网络中有一个数据包丢失，或者任何一方的网络出现中断，整个TCP连接就会暂停，丢失的数据包需要被重新传输。因为TCP是一个按序传输的通道，因此如果其中一个点丢失了，通道上之后的内容就都需要等待。
随着丢包率的增加，HTTP/2的表现越来越差。在2%的丢包率（一个很差的网络质量）中，测试结果表明HTTP/1用户的性能更好，因为HTTP/1一般有六个TCP连接，哪怕其中一个连接阻塞了，其他没有丢包的连接仍然可以继续传输。
TCP的队首阻塞介绍：
TCP在不可靠的信道上实现了可靠的网络传输。基本的分组错误检测与纠正、按序交付、丢包重发，以及保证网络最高效率的流量控制、拥塞控制和预防机制，让TCP成为大多数网络应用中最常见的传输协议。
虽然TCP很流行，但是实现TCP的种种机制会导致额外的延迟，对性能造成负面影响，特别是按序交付和可靠交付。想想看，每个TCP分组都会带着一个唯一的序号被发出，而所有分组必须按顺序传送到接收端。如果中途有一个分组没能到达接收端，那么后续分组必须保存在接收端的TCP缓冲区上，等待丢失分组重发并到达接收端。应用程序对TCP重发和缓冲区中排队的分组一无所知，必须等待分组全部到达才能访问数据。在此之前，应用程序只能在通过套接字读数据时感觉到延迟交付。这就是TCP的队首阻塞。
例子：
假设采用http2协议在在单个TCP连接上发送消息，向服务器拿三张照片，因为http2多路复用的原因，三次请求和三次响应都可以是无序且并行的，
但是要是第一张照片的TCP分节丢失了，客户端将保持已到达的不按序的所有数据，直到丢失的分节重传成功，客户端才去访问数据，这样不仅延缓了第一幅图像数据的递送，也延缓了第二幅和第三幅图像数据的递送。
如何解决TCP队头阻塞：
- TCP中的队头阻塞的产生
是由TCP自身的实现机制决定的，无法避免。想要在应用程序当中避免TCP队头阻塞带来的影响，只有舍弃TCP协议。 - 比如google推出的
quic协议，在某种程度上可以说避免了TCP中的队头阻塞，因为它根本不使用TCP协议，而是在UDP协议的基础上实现了可靠传输。而UDP是面向数据报的协议，数据报之间不会有阻塞约束。 - 此外还有一个SCTP（流控制传输协议），它是和TCP、UDP在同一层次的传输协议。SCTP的多流特性也可以尽可能的避免队头阻塞的情况。