32 | 未来之路：HTTP/3展望

Chrono



该思维导图由 AI 生成，仅供参考

在前面的两讲里，我们一起学习了 HTTP/2，你也应该看到了 HTTP/2 做出的许多努力，比如头部压缩、二进制分帧、虚拟的“流”与多路复用，性能方面比 HTTP/1 有了很大的提升，“基本上”解决了“队头阻塞”这个“老大难”问题。
HTTP/2 的“队头阻塞”等等，你可能要发出疑问了：为什么说是“基本上”，而不是“完全”解决了呢？
这是因为 HTTP/2 虽然使用“帧”“流”“多路复用”，没有了“队头阻塞”，但这些手段都是在应用层里，而在下层，也就是 TCP 协议里，还是会发生“队头阻塞”。
这是怎么回事呢？
让我们从协议栈的角度来仔细看一下。在 HTTP/2 把多个“请求 - 响应”分解成流，交给 TCP 后，TCP 会再拆成更小的包依次发送（其实在 TCP 里应该叫 segment，也就是“段”）。
在网络良好的情况下，包可以很快送达目的地。但如果网络质量比较差，像手机上网的时候，就有可能会丢包。而 TCP 为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，其他的包即使已经收到了，也只能放在缓冲区里，上层的应用拿不出来，只能“干着急”。
我举个简单的例子：
客户端用 TCP 发送了三个包，但服务器所在的操作系统只收到了后两个包，第一个包丢了。那么内核里的 TCP 协议栈就只能把已经收到的包暂存起来，“停下”等着客户端重传那个丢失的包，这样就又出现了“队头阻塞”。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

HTTP/3是基于QUIC协议的下一代HTTP协议，它解决了HTTP/2中存在的“队头阻塞”问题，实现了更高效的数据传输和更好的性能表现。QUIC协议基于UDP实现了可靠传输，引入了类似HTTP/2的“流”和“多路复用”，并全面采用加密通信。HTTP/3利用QUIC的流来发送“请求-响应”，简化了流控制，帧的结构也变得更简单。头部压缩算法升级成了“QPACK”，解决了HPACK的“队头阻塞”问题。HTTP/3没有指定默认的端口号，需要使用HTTP/2的扩展帧“Alt-Svc”来发现。总的来说，HTTP/3综合了HTTP/1、SSL/TLS、HTTP/2的技术，是一个“集大成之作”，基于QUIC协议的特点，实现了更高效的数据传输和更好的性能表现。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《透视 HTTP 协议》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(31)

最新
精选

许童童
IP 协议要比 UDP 协议省去 8 个字节的成本，也更通用，QUIC 为什么不构建在 IP 协议之上呢？直接利用UDP，兼容性好。说一说你理解的 QUIC、HTTP/3 的好处。彻底解决队头阻塞，用户态定义流量控制、拥塞避免等算法，优化慢启动、弱网、重建连接等问题。对比一下 HTTP/3 和 HTTP/2 各自的流、帧，有什么相同点和不同点。 HTTP/3在QUIC层定义流、帧，真正解决队头阻塞，HTTP/2流、帧是在TCP层上抽象出的逻辑概念。相同点是在逻辑理解上是基本一致的，流由帧组成，多个流可以并发传输互不影响。
作者回复: great。
2019-08-09
3
25
lesserror
老师，以下问题，麻烦回答一下，谢谢： 1.它使用自己的帧“接管”了 TLS 里的“记录”，握手消息、警报消息都不使用 TLS 记录，直接封装成 QUIC 的帧发送，省掉了一次开销。省掉的一次开销是什么？ 2.解决了 HPACK 的“队头阻塞”问题。没明白这句话。
作者回复: 1.省去了TLS封装步骤，也就没有了TLS帧头等相关信息，字节数等成本就减少了。 2.HPACK的字典需要双方传输同步，如果有的字典没有传过来就会阻塞，而HTTP/3解决了这个问题。
2019-12-25

12
阿锋
（1）http的队头阻塞，和tcp的队头阻塞，怎么理解？是由于tcp队头阻塞导致http对头阻塞，还是http本身的实现就会造成队头阻塞，还是都有。感觉有点模糊？（2）看完了QUIC，其流内部还是会产生队头阻塞，感觉没啥区别，QUIC内部还不是要实现tcp的重传那一套东西。QUIC没看出来比tcp好在哪里。（3）队头阻塞在http，tcp，流等这几个概念中是怎么理解和区分的，很迷惑。
作者回复: 1.队头阻塞在tcp和http层都存在，原因不同。http/2解决了http的队头阻塞，在http层是没有问题了，但在tcp层还有队头阻塞，所以会影响传输效率。 2.一个流就是一个请求响应，它阻塞不会影响其他流，所以不会发生队头阻塞。 3.QUIC有很多优于tcp的新特性，例如连接迁移、多路复用，加密。 4.队头阻塞确实不太好理解，可以再看看之前的课程，结合示意图来加深体会。
2019-08-09

7
-W.LI-
1.传输层TCP和UDP就够了，在多加会提高复杂度，基于UDP向前兼容会好一些。 2.在传输层解决了队首阻塞，基于UDP协议，在网络拥堵的情况下，提高传输效率 3.http3在传输层基于UDP真正解决了队头阻塞。http2只是部分解决。
作者回复: good。
2019-08-09

5
moooofly
我是不是可以这样理解，QUIC 之所以解决了队头阻塞，是基于UDP的乱序，无连接，以包为单位进行传出的特性，即当发生丢包时，当前流中对应的请求或应答就彻底“丢失”了，之后只需要通过在UDP基础实现的“可靠传输”功能，重传就好了，这样就避免了接收端死等尚未接收到的数据的“干着急”状态；
作者回复: 基本正确，udp的各个包之间没有依赖关系，所以就不会出现队头阻塞。 quic里的另一个关键是流概念，它和http/2的一样，把多个请求响应解耦，互不干扰。这样在上层应用层和下层的传输层就都没有了队头阻塞，但因为丢包而重传该等还是会等，只是不会影响其他的流。
2019-08-31
3
3
功夫熊猫
udp虽然可以节省时间和速度比tcp快，但是如果传输的是那种很机密的东西的时候，但是如何保证udp传输的数据是没有丢失的，（所以udp一般是传输视频，图片之类的东西吧）是换tcp还是对udp进行改装，还是http/3有什么特殊的方法
作者回复: 在udp之上，quic有自己的丢包重传机制。其实在tcp里也是有丢包的，它自己来保证数据的完整可达，类似可以去理解quic。
2021-10-31

2
Rick
请问连接迁移是如何做到的?毕竟它依赖于udp，而udp使用了ip/port。当一个连接的一端从一个ip/port转移到另外一个ip/port上的时候，怎么通知对端呢？需要使用QUIC的控制帧来完成吗？
作者回复: 这个跟控制端无关，因为在quic里标记连接的是连接id，所以两边都用这个id来标记连接，在quic这层是看不到ip+port的，只有id，这个道理和四元组是一样的。至于具体如何做到，那就要看rfc了，不过我个人觉得如果是做应用，了解的太细不是很有必要。
2021-03-20

2
cake
老师请问下这句话怎么理解呢 HTTP/2 那样再去定义流
作者回复: 在quic里已经有流的概念了，所以http/3就不需要再用一大段文字来定义流的格式、行为等，直接引用quic就可以。而http/2里的流概念是全新的，下面的tcp、tls没有，就必须花上很多篇幅去说明。
2021-10-05

1
Unknown element
gQUIC 混合了 UDP、TLS、HTTP，是一个应用层的协议。而 IETF 则对 gQUIC 做了“清理”，把应用部分分离出来，形成了 HTTP/3，原来的 UDP 部分“下放”到了传输层，所以 iQUIC 有时候也叫“QUIC-transport”。接下来要说的 QUIC 都是指 iQUIC，要记住，它与早期的 gQUIC 不同，是一个传输层的协议，和 TCP 是平级的老师问下这一段最后为什么说iQUIC是传输层协议？本来gQUIC是应用层协议，去掉传输层部分后反而变成了传输层协议吗？
作者回复: gQUIC把udp/tls/http混合在一起，所以是应用层协议。而iQUIC只专注于数据传输，是gQUIC的udp+tls部分，http那部分变成了http/3。可以去看rfc9000，里面写的很清楚。
2021-06-12

1
小童
老师这个QUIC 是如何保证UDP的可靠传输？还是没看明白。
作者回复: 底层的细节比较复杂，一下子也说不清楚，可以类比一下tcp和ip，quic就是在udp之上加了tcp的那套重传校验机制。
2021-04-28

1

收起评论