TCP 队头阻塞 & HTTP 队头阻塞
作者：互联网
最近在看论文看到了队头阻塞的概念，然后去查了一下资料，发现和我一开始以为的有点不一样，原本我认为队头阻塞是‘’第一个数据包由于网路拥塞因此无法及时到达接收端，后面的因为前面的没法继续传送也堵在那了，但是通过度娘发现我理解的并不太对。下面说一下我理解的！
TCP队头阻塞和HTTP队头阻塞有些类似，但又不太一样！！
1、TCP队头阻塞
我们都知道，TCP是一种可靠传输，这个可靠就是体现在它能够“按序到达”，然后再被上层接收，这里的按序到达指的是最终顺序是按序排列的，也就是说每当有一个或几个Packet丢失的时候，会等待它到达后合并，然后再向上交付。
因此，很容易可以理解，当一个流的第一个数据包丢失了，那么即使后面的数据包都到达了，后面的这些数据包也不能被处理，而是要等第一个数据包到了之后才能被上层接收处理，那么这个时候不止是第一个数据包需要额外等待一个或多个RTT，后面的第二个Packet、第三个Packet......都需要同样多等待那么多时间才能处理，但实际上他们是按时到达了的，这也就是所谓的TCP队头阻塞。
2、HTTP队头阻塞
首先先回忆一下HTTP协议
HTTP分为 HTTP/1.x 和 HTTP/2（现在已经到了HTTP/3）
HTTP/1.0 是一个短连接，每一次请求完成后都会断开连接，因此下一次又要重新请求，因此每一个请求就要两倍的RTT开销，这样资源消耗过大。使用并行TCP连接可以缩短响应时间。
HTTP/1.1 是一个长链接（持续连接），万维网服务器在发送响应后仍然在一段时间内保持这条连接，是同一个客户（浏览器）和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。【这里要注意，即使不是同一个文档也没关系，只要他们在同一个服务器上就不需要另外建立连接】
而HTTP/1.1又分为非流水线方式（no pipelining）和流水线方式（pipelining）这两种传输方式：
非流水线方式： 客户在收到前一个响应之后才能发出下一个请求，因此，在TCP连接已经建立之后，客户每访问一次对象都要用一个RTT，这比 HTTP/1.0 的要用去两倍的RTT的开销要节省了建立TCP连接所需的一个RTT开销。但是它还是有缺点，依然是有比较多的RTT资源浪费，因为服务器发送完一个对象给浏览器后其TCP连接就处于空闲状态（直到下一个请求到达），浪费了服务器资源。
流水线方式： 在客户端收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个个的请求到达服务器后，服务器就可以连续的发回响应报文。因此采用流水线方式的时候，客户访问所有的对象只需花费一个RTT时间。这种方式使得TCP连接中的空闲时间减少，提高了文档下载效率。
从上面我们可以看到，对于HTTP/1.1中的流水线方式中，存在队头阻塞的问题！
流水线方式中，所有的HTTP请求是连续发送的，但是其响应是串行返回的（因为管道化要求服务端按照请求发送的顺序返回响应（FIFO）原因是HTTP请求和响应并没有序号标识，无法将乱序的响应与请求关联起来，所以要求按顺序返回），那么当后面的响应都返回了，而第一个响应因为延迟等原因没有返回的话，客户端一样也没办法处理，虽然按照没有延迟等理想情况来说，这样确实会提高文件传输效率，但是网络中经常会有延迟等情况，所以只要第一个的响应没有及时到达，后面的响应到了也没法处理。（其实这个和TCP队头阻塞有些像）
为了解决HTTP/1.1中的队头阻塞，提出了解决办法，其中就包括HTTP/2等，这些在后面的文章中再写到~
标签：HTTP,请求,队头,阻塞,TCP,响应 来源： https://blog.csdn.net/weixin_44260459/article/details/120797655