深入解读HTTP3的原理及应用

Posted 2021-04-26 高可用架构

HTTP3是HTTP协议的最新版本。从诞生之初，HTTP就是交换超文本文档的首选应用层协议。多年来，为了跟上互联网的发展，以及WWW上交换的内容种类增加，HTTP进行了几次重大升级。

本文将深入探讨HTTP/3，介绍HTTP协议的演变历程，重点介绍HTTP/3的特点，并对HTTP/3将会带来的互联网变化提供新的视角。

背景

什么是HTTP/3

当IETF正式标准化HTTP/2时，Google正在独立构建一个新的传输协议，名为gQUIC。它后来成为新互联网草案，并被命名为QUIC。gQUIC最初的实验证明，在网络条件较差的情况下，gQUIC在增强网页浏览体验方面的效果非常好。因此，gQUIC的发展势头越来越好，IETF的大多数成员赞成建立一个在QUIC上运行的HTTP新规范。这个新的倡议被称为HTTP/3，以区别于当前的HTTP/2标准。

从语法和语义上看，HTTP/3与HTTP/2相似。HTTP/3遵循相同的请求和响应消息交换顺序，其数据格式包含方法、标题、状态码和body。然而，HTTP/3的显著的偏差在于协议层在UDP之上的堆叠顺序。

HTTP/3 是如何工作的？

HTTP/3功能的核心是围绕着底层的QUIC协议来实现的。在讨论QUIC和UDP之前，我们有必要先列出TCP的某些限制，这也是导致QUIC发展的原因。

TCP可能会间歇性地挂起数据传输

如果一个序列号较低的数据段还没有接收到，即使其他序列号较高的段已经接收到，TCP的接收机滑动窗口也不会继续处理。这将导致TCP流瞬间挂起，在更糟糕的情况下，即使所有的段中有一个没有收到，也会导致关闭连接。这个问题被称为TCP流的行头阻塞（HoL）。

TCP不支持流级复用

虽然TCP确实允许在应用层之间建立多个逻辑连接，但它不允许在一个TCP流中复用数据包。使用HTTP/2时，浏览器只能与服务器打开一个TCP连接，并使用同一个连接来请求多个对象，如CSS、javascript等文件。在接收这些对象的同时，TCP会将所有对象序列化在同一个流中。因此，它不知道TCP段的对象级分区。

TCP会产生冗余通信

TCP连接握手会有冗余的消息交换序列，即使是与已知主机建立的连接也是如此。

QUIC协议在以下设计选择的基础上，通过引入一些底层传输机制的改变，解决了这些问题。

1.选择UDP作为底层传输层协议。在TCP之上建立新的传输机制，将继承TCP的上述所有缺点。因此，UDP是一个明智的选择。此外，QUIC是在用户层构建的，所以不需要每次协议升级时进行内核修改。

流复用和流控。QUIC引入了连接上的多路流复用的概念。QUIC通过设计实现了单独的、针对每个流的流控，解决了整个连接的行头阻塞问题。

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

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

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

通过在QUIC之上构建基于HTTP/3的应用层，您可以获得增强型传输机制的所有优势，同时保留HTTP/2的语法和语义。但是，你也必须注意到，HTTP/2不能直接与QUIC集成，因为从应用到传输的底层帧映射是不兼容的。因此，IETF的HTTP工作组建议将HTTP/3作为新的HTTP版本，并根据QUIC协议的帧格式要求修改了帧映射。

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

为什么HTTP/3很重要？

TCP已经有40多年的历史了。它在1981年通过RFC 793从而标准化。多年来，它经历了多次更新，是一个非常强大的传输协议，可以支持互联网流量的增长。然而，由于设计上的原因，TCP从来就不适合处理有损无线环境中的数据传输。在互联网的早期，有线网络将网络中的每一台计算机连接起来。

现在，随着智能手机和便携式设备的数量超过台式机和笔记本电脑的数量，超过50%的互联网流量已经通过无线传输。这种趋势给整体的网络浏览体验带来了问题，其中最重要的是在无线覆盖率不足的情况下，TCP中的行头阻塞。

Google的一些初步实验证明，QUIC作为Google部分热门服务的底层传输协议，极大地提高了速度和用户体验。部署QUIC作为YouTube视频的底层传输协议，导致YouTube视频流的缓冲率下降了30%，这直接影响了用户的视频观看体验。在显示谷歌搜索结果时，也有类似的改善。

网络条件较差的情况下提升非常明显，这促使谷歌更加积极地完善该协议，并最终向IETF提出标准化。

由于这些早期的试验所带来的所有改进，QUIC已经成为带领万维网走向未来的重要因素。在QUIC的支持下，HTTP从HTTP/2到HTTP/3的改头换面，朝着这个方向合理地迈出了一步。

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在整个协议栈中的占用空间。这使得HTTP/3较为笨重，不适合那些IoT设备。但这种情况很少出现，而且存在专门的协议，这就避免了直接在此类设备上支持HTTP的需要。此外，还有以物联网为核心的协议，如MQTT。

开始使用HTTP/3

参考阅读：

• 
  

• 
  
• 
  
• 
  

本文由高可用架构编译。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号