浅析HTTP/3协议

下一代HTTP协议真的来了！他就是HTTP/3，从2018年开始起稿，经过IETF反复商量定稿的RFC9114就是HTTP/3的标准了。目前已经有不少浏览器和移动端已经支持上了HTTP/3协议了，比如Chrome/Firefox发布版本就已经默认开启了。
HTTP协议被互联网广泛使用的时间可以追溯到1997年提出的HTTP/1.1版本。经过多年的发展，HTTP协议已经随着互联网规模的增加和传输内容的变迁进行了明显的更新了。
本页将深入浅出说明下HTTP/3协议，会从HTTP/3的特性出发描述下HTTP协议的演进历程，最后还会展望下HTTP/3协议加持下的互联网未来。
背景——为什么需要HTTP/3
HTTP催生互联网
按照Tim Berners-Lee的最初设想，超文本传输协议(HTTP)是“一行的协议”。HTTP/0.9有ASCII码文本字符串：GET请求方法，紧接着是文档地址，可选端口，并以回车符(CR)和结束符(LF)为结尾。每个HTTP请求都由ASCII码字节流组成。仅有HTML文档可以在没有HTTP头的情况下传输，没有状态码或错误码。
多年以来，HTTP协议经历了从HTTP/1.0到HTTP/1.1最后到HTTP/2的演进。每个版本迭代，都会加入新特性来处理耗时，例如应用层的需求，安全考虑，会话处理和媒体类型。
图1 HTTP协议的演进

图2 HTTP各协议版本的对比
[图片]
互联网增长下HTTP/2面临压力
在互联网和HTTP发展过程中，HTTP的底层传输协议大体上来说基本保持不变。但是，随着海量移动设备推高互联网流量，HTTP协议作为提供顺滑、高效的Web访问协议越来越困难，特别是随着实时应用增多，HTTP/2协议的短板越来越明显。

举个例子来说，HTTP/2最终版本没有囊括很多期望来提高HTTP/1.1的特性。为了后向兼容HTTP/1.1，HTTP/2协议不得不保留原始的POST和GET请求，以及状态码(200,301,404和505)等等。

同时，有些特性的实现会引入新的安全问题。且不说历史遗漏的加密算法的强度问题，这些压缩头和cookies也是很容易受到攻击。

HTTP/3协议为了提供一个快速、可靠和安全的网络连接，能够让各种类型的设备避免HTTP/2传输层的问题。为了达到这个，它用了不同的传输层协议叫做QUIC，这个QUIC是运行在UDP网络层协议之上，而不是之前所有HTTP版本使用的TCP协议。

不同于TCP的有序数据交换的机制，UDP能够允许各种方向上的数据传播，这个特性能够在数据包级别解决HoL（Head-of-Line）队首阻塞的问题。
图3 TCP和UDP的包序列差异
[图片]
除此之外，QUIC重新设计了客户端和服务端的握手流程，来减少重复建连的延迟。这里只说个大概，后续在TCP的局限章节详细说明。
图4 TCP+TLS和QUIC(TLS1.3)握手对比
[图片]
当然，你会说，TCP是比UDP更可靠的传输协议；为什么还要重新在UDP之上设计HTTP呢？本文后面会简短说明下TCP的短板。在此之前，我们先看下什么是HTTP/3协议，以及深入看下HTTP/3基于QUIC之上的设计考虑。
HTTP/3的出现
当IETF组织正式宣布HTTP/2的标准的时候，谷歌公司开始着手独自构建gQUIC协议，它是一个全新的传输层协议。起初的实验结果令人鼓舞，结果表明gQUIC在网络条件不好的情况能够极大地提升Web交互体验。
为了支持gQUIC的增长势头，它被重命名为QUIC。IETF主要成员进行了投票来决定起草一个全新的HTTP over QUIC的协议方案。这个新方案后来命名为HTTP/3。
HTTP/3在语法和语义上与HTTP/2接近。HTTP/3同样遵循请求和回复的数据交换，其数据格式同样包含请求方法，请求头，状态码和请求体。当时，HTTP/3最大的不同在于协议栈构建在UDP之上，如下图所示。
图5 HTTP/2和HTTP/3协议栈对比
[图片]
HTTP/3和QUIC是如何突破TCP局限的
HTTP/3的优势来自于下层的QUIC协议。在谈论QUIC和UDP之前，我们值得来列下TCP的一些局限性，这些局限性促使我们优先开发出QUIC协议。
TCP的局限性
TCP会间歇性的卡住你的数据传输
在TCP滑动窗口机制里，如果低序号的数据尚未到达，甚至高序号的数据已经到了，TCP的滑动窗口也不会更新。这就导致了TCP数据流随时可能卡住甚至关闭连接，即使只有一个数据包尚未到达，后续的数据包处理都不会进行。这个问题就是众所周知的TCP数据流的HoL队首阻塞问题。
图6 数据包级别的HoL问题会让连接关闭
[图片]
TCP不支持数据流的多路复用
TCP本不支持在一个连接上传输多路数据。HTTP/2协议在应用层构建了多个逻辑连接，能够让客户端服务端在一个TCP连接上同时传输多路数据，比如浏览器与服务器建立一个TCP连接，然后同时请求多个数据对象，有CSS，JavaScript以及其他文件。当一个TCP连接串行接收到这些数据后，最终根据请求对象的逻辑连接进行分开。
TCP通信有冗余
当TCP进行建连握手的时候，TCP协议会按顺序的交互数据，其实当与已知的主机建连的时候，其中一些数据是冗余的。
图7 TCP+TLS握手过程
[图片]
一个全新的传输协议——QUIC
QUIC协议为了解决TCP的局限性引入了一些传输机制的改变。这些改变有如下一些：
1）选择UDP作为底层传输层协议：在TCP之上建立新的传输机制，将继承TCP的上述所有缺点。因此，UDP是一个明智的选择。此外，QUIC是在用户层构建的，所以不需要每次协议升级时进行内核修改。

2）流复用和流控：QUIC引入了连接上的多路流复用的概念。QUIC通过设计实现了单独的、针对每个流的流控，解决了整个连接的队首阻塞问题。
图8 UDP传输情况下无HoL
[图片]

3）灵活的拥塞控制机制：TCP的拥塞控制机制是刚性的。该协议每次检测到拥塞时，都会将拥塞窗口大小减少一半。相比之下，QUIC的拥塞控制设计得更加灵活，可以更有效地利用可用的网络带宽，从而获得更好的吞吐量。

4）更好的错误处理能力：QUIC使用增强的丢失恢复机制和转发纠错功能，以更好地处理错误数据包。该功能对于那些只能通过缓慢的无线网络访问互联网的用户来说是一个福音，因为这些网络用户在传输过程中经常出现高错误率。

5）更快的握手：QUIC使用相同的TLS模块进行安全连接。然而，与TCP不同的是，QUIC的握手机制经过优化，避免了每次两个已知的对等者之间建立通信时的冗余协议交换。
图9 不同协议建连的RTTs
[图片]

6）语法和语义：基于具有以上特性的QUIC协议，HTTP/3能够极大地利用这些优势并且可以保持和HTTP/2一样的语法。但是，你也必须注意到，HTTP/2不能直接与QUIC集成，因为从应用到传输的底层帧映射是不兼容的。因此，IETF的HTTP工作组建议将HTTP/3作为新的HTTP版本，并根据QUIC协议的帧格式要求修改了帧映射。

7）新压缩方法：除此之外，HTTP/3还使用了一种新的HTTP头压缩机制，称为QPACK，是对HTTP/2中使用的HPACK的增强。在QPACK下，HTTP头可以在不同的QUIC流中不按顺序到达。与HTTP/2中的TCP确保数据包的按顺序传递不同，QUIC流是不按顺序传递的，在不同的流中可能包含不同的HTTP头。因此，QPACK使用查找表机制对报头进行编码和解码。

8）优化的服务端推送：HTTP/2引入的服务端推送特性，能够让客户端预先获取请求数据。同样在HTTP/3里也支持了，当时实现方式有所不同，HTTP/3下的服务端推送能够被有效限制推送的内容。因为尽管服务端推送能够减少一半的RTT，但是确实也会增加带宽消耗。PUSH_PROMISE帧会送服务端发出，包含了当前请求会推送的内容，然后在新流上推送这些数据。客户端还可以限制服务端推送。每个推送内容可以用CANCEL_PUSH帧取消，即使前面的数据被认为已经接受了。
为何HTTP/3如此重要？
TCP已经有40多年的历史了。它在1981年通过RFC 793从而标准化。多年来，它经历了多次更新，是一个非常强大的传输协议，可以支持互联网流量的增长。然而，由于设计上的原因，TCP从来就不适合处理有损无线环境中的数据传输。在互联网的早期，有线网络将网络中的每一台计算机连接起来。

现在，随着智能手机和便携式设备的数量超过台式机和笔记本电脑的数量，超过50%的互联网流量已经通过无线传输。这种趋势给整体的网络浏览体验带来了问题，其中最重要的是在无线覆盖率不足的情况下，TCP中的行头阻塞（关于TCP在移动网络下的不足，请阅读《5G时代已经到来，TCP/IP老矣，尚能饭否？》）。

Google的一些初步实验证明，QUIC作为Google部分热门服务的底层传输协议，极大地提高了速度和用户体验。部署QUIC作为YouTube视频的底层传输协议，导致YouTube视频流的缓冲率下降了30%，这直接影响了用户的视频观看体验。在显示谷歌搜索结果时，也有类似的改善。网络条件较差的情况下提升非常明显，这促使谷歌更加积极地完善该协议，并最终向IETF提出标准化。

由于这些早期的试验所带来的所有改进，QUIC已经成为带领万维网走向未来的重要因素。在QUIC的支持下，HTTP从HTTP/2到HTTP/3的改头换面，朝着这个方向合理地迈出了一步。
HTTP/3的最佳实践
HTTP/3将改善我们上网的体验，特别是在仍无法使用高速无线网络的地区。尽管HTTP/2已经解决了一部分问题，然而HTTP/3更进一步。
物联网(IoT)
HTTP可能不是物联网的首选协议，但在某些情况下，基于HTTP的通信非常适合特定的应用。HTTP/3可以解决从传感器收集数据的移动电话的无线连接损耗问题。这个问题同样适用于安装在车辆或可移动资产上的独立IoT设备。通过HTTP来访问这些设备，可以更加可靠。
大数据
全球各地的企业都在觉醒，意识到从多个部门收集数据的潜力，并将其整合成更大的信息共享API，供内部和外部受众共享。这些API也为数据的货币化铺平了道路，通过托管这些数据作为流API服务可以实现数据的货币化。随着时间的推移，这些服务会吐出海量的数据。通过HTTP/3托管的流API将使它们比HTTP/2更健壮、更有弹性。
Web VR
随着浏览器能力的提升，内容格局正在快速变化。其中一个领域就是基于网络的VR。虽然还处于起步阶段，但有很多的用例可以让VR在加强协作方面发挥关键作用。网络在促进VR互动方面占据了核心位置。VR应用需要更多的带宽来渲染虚拟场景中的复杂细节，因此迁移到HTTP/3会大有收获。
HTTP/3的局限性
过渡到HTTP/3不仅涉及到应用层的变化，还涉及到底层传输层的变化。因此，与它的前身HTTP/2相比，HTTP/3的采用更具挑战性，因为后者只需要改变应用层。传输层承受着网络中的大量中间层审查。这些中间层，如防火墙、代理、NAT设备等会进行大量的深度数据包检查，以满足其功能需求。因此，新的传输机制的引入对IT基础设施和运维团队来说有一些影响。

然而，HTTP/3被广泛采用的另一个问题是，它是基于QUIC的，在UDP上运行。大多数的Web流量，以及IETF定义的知名服务都是在TCP之上运行的。这也是为什么长时间运行HTTP/3的UDP会话会被防火墙的默认数据包过滤策略所影响的原因。

随着IETF正在进行的标准化工作，这些问题最终都会得到解决。此外，考虑到Google在早期QUIC实验所显示的积极结果，人们对HTTP/3的支持是压倒性的，这将最终迫使中间层厂商标准化。

针对受限的IoT设备，HTTP/3由于过于繁琐从而无法采用。许多IoT应用部署的设备的外形尺寸非常小。因此，它们的RAM和CPU功率都是有限的。为了使设备在电池功率、低比特率和有损连接等限制条件下高效运行，必须执行此要求。HTTP/3在现有的UDP之上，以QUIC的形式在传输层处理，增加了HTTP/3在整个协议栈

本文由 admin 创作，采用 知识共享署名4.0 国际许可协议进行许可。
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。