HTTP/1.1 队头堵塞

已于 2025-07-22 14:56:53 修改
阅读量454 收藏 5
点赞数 7
CC 4.0 BY-SA版权
分类专栏： # 图解 HTTP 文章标签： http
于 2025-04-17 17:47:43 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/chirrupy_hamal/article/details/147309752

文章目录

一、队头堵塞

1、非管线化

在这里插入图片描述
如图，http 请求必须等到上一个请求响应后才能发送，后面的以此类推，由此可以看出，在一个 tcp 通道中，如果某个 http 请求的响应因为某种原因没能及时返回，那后面的请求都会被阻塞

2、管线化

在这里插入图片描述
管线化限制服务器需按照请求的发送顺序返回响应，如果其中某个响应因为某种原因延迟了几秒，那后面的响应都会被阻塞，而且客户端要等服务器响应完第一批发出的请求后，才能发出下一批请求

HTTP/1.1 管线化解决了请求的队头阻塞，但没有解决响应的队头阻塞

二、如何解决？

HTTP/2.0、HTTP/3.0

四十四：HTTP/1.1发展中遇到的问题
W楠的博客
12-11 560
然而，随着互联网的迅速发展和应用场景的不断扩展，HTTP/1.1在设计和实现过程中暴露出了一些问题。然而，这种组合依赖于额外的配置，未加密的HTTP通信仍然广泛存在，暴露于中间人攻击和数据窃取的风险中。每个HTTP/1.1请求都需要完整的头部信息，即使多个请求共享相同的上下文，这种重复会增加带宽消耗，特别是在传输小文件或频繁请求时尤为显著。HTTP/1.1的设计在灵活性上存在一定限制，例如，扩展功能时需要引入新的请求方法或头字段，但这些修改常常与现有实现不兼容，导致兼容性问题。
HTTP/1.1、HTTP/2、HTTP/3 演变（计算机网络）
qq_61504864的博客
03-31 1053
图中发送方发送了很多个 packet，每个 packet 都有自己的序号，你可以认为是 TCP 的序列号，其中 packet 3 在网络中丢失了，即使 packet 4-6 被接收方收到后，由于内核中的 TCP 数据不是连续的，于是接收方的应用层就无法从内核中读取到，只有等到 packet 3 重传后，接收方的应用层才可以从内核中读取到数据，这就是 HTTP/2 的队头阻塞问题，是在 TCP 层面发生的。我们都知道 HTTP/1.1 的实现是基于请求-响应模型的。
HTTP/1.1队首阻塞和HTTP/2优化
大力海棠的博客
05-04 2021
应用层的优化的方式很多，我知道的有浏览器上的优化，通常我们浏览一个HTML网页时，客户端向服务器端发送请求得到主页面，主页面上由很多元素组成，JS文件，CSS样式文件和各种音频图片等资源，等待服务器端发送HTTP或HTTPS响应，在接收到主页面响应后，开始进行页面布局，即构建DOM文档对象模型。页面构建完成后，客户端浏览器继续发送请求，获取页面上的子元素（CSS文件，图片音频等）进行页面渲染。由于...
HTTP1.1 对头阻塞和 HTTP2 中对其的解决措施
weixin_63951768的博客
01-03 1444
只是“头部”的一个小问题，也能“阻塞”整条“线路”。这就是极难解决的 Web 性能问题之一，队头阻塞，接下来让我们来了解一下它是怎么来的。
HTTP1.0、HTTP1.1、HTTP2.0、HTTP3.0之间的区别，以及发展过程中解决的问题
最新发布
2203_75974353的博客
05-15 554
每次发展解决的问题如下：
HTTP：什么是队头阻塞以及怎么解决
OceanStar的博客
10-29 3446
短连接 HTTP协议最初(0.9/1.0)是个非常简单的协议，通信给出也采用了简单的“请求-应答”方式。 它底层的数据传输基于TCP/IP，每次发送请求前需要先与服务器建立连接，收到相应报文后会立即关闭连接。 因为客户端和服务器的整个连接给出很短暂，不会与服务器保存长连接的状态，所以就称为“短连接” 短连接的缺点相当严重，因为在TCP协议里，建立连接和关闭连接都是非常“昂贵”的操作。TCP建立连接要有“三次挥手”，发送3个数据包，需要1个RTT；关闭连接是“四次挥手”，4个数据包需要2个RTT。
HTTP/1.1的工作模式及队头阻塞
James的博客
02-01 2294
典型的HTTP工作模式是点对点的，其中包括2个参与者，即客户端和服务器，尽管还可以引入其它参与者，如正向代理，反向代理，但其本质上还是点到点的，其它角色或扮演客户端，或服务器，或二者，充当中间人参与到HTTP的通讯中，HTTP协议本身仅通过特定头字段标记【Via】是否通过中间人转发，并不改变点到点通讯的本质。 进一步，在HTTP/1.1中客户端发送请求，服务器回应客户端的请求，客户端发送的每一个请求，需要等待服务器回应后才能发送下一个请求，即所有请求在一个FIFO队列里，这样就会造成队头阻塞。即如果队头的请
什么是队头阻塞以及如何解决
ldxxxxll的博客
04-12 1739
独立的消息数据都在一个链路上传输，也就是有一个“队列”。比如TCP只有一个流，多个HTTP请求共用一个TCP连接队列上传输的数据有严格的顺序约束。比如TCP要求数据严格按照序号顺序，HTTP管道化要求响应严格按照请求顺序返回所以要避免队头阻塞，就需要从以上两个方面出发，比如quic协议不使用TCP协议而是使用UDP协议，SCTP协议支持一个连接上存在多个数据流等等。
HTTP 之 HTTP/1.1 连接特性（五）
qq_35876316的博客
08-20 680
由于队头阻塞和TCP连接的独立性，HTTP/1.1 可能需要同时打开多个TCP连接来下载多个资源，这在高延迟环境下影响性能。HTTP/1.1 引入了持久连接，允许多个请求和响应在同一个TCP连接上复用，减少了连接建立和关闭的开销。在管道化技术中，如果一个响应被阻塞，所有排队在其后的请求都将等待，这限制了并行处理的能力。允许在单个TCP连接上并行交错发送多个请求和响应，解决了队头阻塞问题。每个请求/响应通常使用一个独立的TCP连接，或通过持久连接复用。由于头部压缩，减少了不必要的网络流量，加快了传输速度。
如何理解 HTTP1.0/1.1/2.0 的区别?
向着太阳迎着光
12-20 699
HTTP/1.0：每个请求都需要单独建立连接，效率低，适用于简单的Web应用。HTTP/1.1：增加了持久连接、管道化和缓存控制，减少了延迟和重复连接，但依然面临队头阻塞的问题。HTTP/2.0：通过多路复用、二进制协议、头部压缩和服务器推送等技术显著提高了性能，适合现代Web应用和复杂页面。对于大多数现代Web应用，推荐使用HTTP/2，尤其是在资源密集型页面或需要大量并发请求的情况下。
队头阻塞/Head Of Line blocking,HOL
summer_fish的专栏
01-14 1367
队头阻塞（Head-of-Line blocking，简写HOL blocking）是网络通信中常见的问题，特别是在使用TCP协议时。当一个TCP分节丢失，导致其后续分节不按序到达接收端时，就会发生队头阻塞。在这种情况下，后续分节将被接收端一直保持，直到丢失的第一个分节被发送端重传并到达接收端为止。这种延迟递送确保接收应用进程能够按照发送端的发送顺序接收数据。
队头阻塞-介绍
qq_68874993的博客
08-27 1264
本文内容是队头阻塞的介绍和举例
解决http请求阻塞问题
Bird_King的博客
11-11 995
解决http请求阻塞问题
HTTP之队头阻塞
qq_40276626的博客
09-19 2082
HTTP1.1 HTTP1.1中引入了长连接，允许多个连接复用一个TCP连接。 当多个请求先后调用HTTP发送的时候，如果前一个请求不响应的话，后一个请求是不会发送的。 所以如果前一个响应阻塞的话，后边的请求也会被迫阻塞，叫做队头阻塞。 为什么要严格控制返回顺序呢？ 因为假如不按照FIFO返回响应，就无法区分返回的响应头对应哪个HTTP请求头了。 HTTP2.0 HTTP2.0时，引入了帧、流的概念。 HTTP2是基于TCP的。HTTP2允许多个请求不按照先后顺序发送数据，并允许穿插的发送数据，也就是每次发
http什么是队头阻塞
caofengtao1314的专栏
04-22 3186
参考文章：https://time.geekbang.org/column/article/104949大家尽量购买 “队头阻塞”与短连接和长连接无关，而是由 HTTP 基本的“请求 - 应答”模型所导致的。 因为 HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。 队列里的请求没有轻重缓急的优先级，只有入队的先后顺序，排在最前面的请求被最优先处理。 如果队首的...
Http 长连接 队头阻塞 性能优化
前端开发一枚
01-28 2099
1.短连接及长连接 早期的 HTTP 协议也被称为是“无连接”的协议。不会与服务器保持长期的连接状态，所以也称为短连接。 到Http1.1就出现了长连接的通信方式，也叫“持久连接”（persistent connections）、“连接保活”（keep alive）、“连接复用”（connection reuse）。 短连接以及长连接都可以用下图很好的解释 其实蛮好理解，短连接就是ht...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值