最近在看论文看到了队头阻塞的概念，然后去查了一下资料，发现和我一开始以为的有点不一样，原本我认为队头阻塞是‘’第一个数据包由于网路拥塞因此无法及时到达接收端，后面的因为前面的没法继续传送也堵在那了，但是通过度娘发现我理解的并不太对。下面说一下我理解的！
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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。