2018年11月，互联网工程任务组 (IETF) 在曼谷召开会议，通过了新的互联网草案。HTTP/2的继承者QUIC传输协议已重命名为HTTP/3。HTTP/3建立在用户数据报协议 (UDP) 之上，并且已经被谷歌和Facebook等知名互联网公司使用。如果您使用Chrome并连接到Google服务，那么您可能已经在使用QUIC。
新版本的HTTP协议受益于裸机、低级UDP协议，并在TCP层定义了许多以前版本的HTTP中的新特性。这提供了一种解决现有互联网基础设施内限制的方法。
第一个结果是有希望的，当IETF的Internet草案在2021年8月到期时，我们可以期待HTTP/3被推广为新的第三代HTTP标准。
- 2022年HTTP/3进展
- 一点背景知识——从HTTP/2开始
- 互联网协议 (IP)
- 了解TCP和UDP的作用
- QUIC和HTTP/3
2022年HTTP/3进展
有人说，网络行业对更快速度和更低延迟的渴望与谷歌浏览器对更多RAM的渴望相匹配。
我们曾经发表了一篇关于HTTP/2的文章，据W3Techs称，该标准目前已达到45%左右的全球采用率。根据Can I Use，所有现代网络浏览器也支持它。然而，我们在这里，正在写一篇关于协议的下一个版本HTTP/3的文章。
HTTP/2采用趋势
在撰写本文时，HTTP/3是IETF Internet-Draft或ID，这意味着Internet工程任务组（一个国际互联网标准机构，负责定义推广商定的互联网协议标准，如 TCP、IPv6、VoIP、物联网等。
它是一个开放的机构，它联合了网络行业并促进了关于互联网方向的讨论。目前，HTTP/3的“互联网草案”阶段是提案被提升到Request-for-Comments（或RFC）级别之前的最后一个阶段，出于所有意图和目的，我们可以考虑官方互联网协议定义。
尽管HTTP/3还不是官方的Internet协议，但许多公司和项目已经开始将HTTP/3支持添加到他们的产品中。
什么是HTTP/3 – 通俗地说
HTTP/3是超文本传输协议 (HTTP) 的第三个版本，以前称为HTTP-over-QUIC。QUIC（Quick UDP Internet Connections）最初由Google开发，是HTTP/2的继承者。谷歌和Facebook等公司已经在使用QUIC来加速网络。
对HTTP/3的Web浏览器支持
在Web浏览器前端，Chrome v87、Firefox v88和Edge v87都默认启用了HTTP/3。对于Safari用户，启用HTTP/3的选项已添加到Safari Technology Preview v104。但是，Safari的稳定版本目前不支持HTTP/3。
对HTTP/3的库支持
对于希望利用HTTP/3技术的开发人员，许多流行的库已经添加了对HTTP/3的支持。由于HTTP/3仍处于Internet草案阶段，因此在使用以下库之一时，您需要确保已调整到最新更新。
- Python – http3和aioquic
- Rust – quiche、neqo和quinn
- C – nghttp3和lsquic
- Go – quicgo
- JavaScript – Node.js
HTTP/3的基础架构支持
在基础架构方面，Cloudflare在其整个边缘网络中支持HTTP/3一直处于领先地位。这意味着启用Cloudflare的站点无需任何额外工作即可利用HTTP/3的安全性和性能增强。
要测试您的站点是否支持HTTP/3，您可以使用Geekflare的HTTP/3测试工具。只需输入您的域并按“Check HTTP/3”按钮，该工具就会让您知道您的网站是否启用了HTTP/3。
Geekflare HTTP/3测试工具
如果您的站点支持HTTP/3，您应该会看到如下所示的消息。
支持HTTP/3连接提示信息
您还可以使用浏览器的检查器来检查HTTP/3支持。对于本示例，我们将使用支持HTTP/3的最新版本的Google Chrome。
要打开检查器，请右键单击页面并单击“检查”并导航到“网络”选项卡。在“协议”列中，您可以看到用于连接的HTTP 协议。 HTTP/2连接显示为“h2”，而HTTP/3连接显示为“h3-XX”（XX 指的是特定的HTTP/3草案）。如下图所示，kinstalife.com支持通过“h3-29”进行连接，即“HTTP/3 Draft 29”。
Chrome支持h3-29协议
现在我们已经了解了HTTP/3的当前状态，让我们深入了解HTTP/2与HTTP/3之间的一些差异！
一点背景知识——从HTTP/2开始
HTTP/2在非阻塞下载、流水线和服务器推送方面带来了一些重大改进，帮助我们克服了底层TCP协议的一些限制。它使我们能够最大限度地减少请求-响应周期和握手的次数。
HTTP/2使得在单个TCP连接中推送多个资源成为可能——多路复用。我们在静态下载的顺序上也获得了更大的灵活性，我们的页面现在不再受到下载线性进展的限制。
HTTP/2推送
实际上，这意味着现在一个大型javascript资源不一定等于所有其他等待轮到它们的静态资源的阻塞点。
无流水线与流水线（图片来源：维基百科，作者Mwhitlock）
再加上HTTP/2的标头HPACK压缩和数据传输的默认二进制格式，在许多情况下，我们拥有一个明显更高效的协议。
HTTP/2 HPACK压缩
主要的浏览器实现要求网站实现加密 – SSL – 才能获得HTTP/2的好处 – 有时这会产生计算开销，导致速度提升不明显。甚至在某些情况下，用户在过渡到HTTP/2后报告速度变慢。
让我们说，采用此版本的早期并不是为了弱者。
Nginx实现也缺少server-push特性，依赖于一个模块。而Nginx的模块是不是你平时的Apache插入式模块，你可以复制- Nginx已经将这些重新编译。
虽然其中一些问题现在已经解决，但如果我们查看整个协议栈，我们会发现主要约束位于比HTTP/2敢于冒险的更低级别。
为了详细说明这一点，我们将从底层到顶层剖析当今的互联网协议栈。如果您想了解更多关于HTTP/2的背景知识，请务必查看我们的终极HTTP/2指南。
互联网协议 (IP)
互联网协议 (IP) 定义了整个互联网拓扑的底部。它是互联网堆栈的一部分，我们可以肯定地说，如果不改变一切，包括更换整个硬件基础设施，从路由器到服务器，甚至是最终用户的机器，它确实是不可协商的。
因此，虽然协议大修可能到期，但目前还没有出现如此深远的努力，主要是因为我们还没有提出一个可行的、开创性的、但向后兼容的替代方案。
我们可以将IP协议的起源追溯到1974年，由电气和电子工程师协会发表并由Vint Cerf和Bob Cahn撰写的一篇论文。它详细说明了通过网络发送的数据包，跨IP地址路由它们，以及网络/网络中节点的数字定义地址。该协议定义了这些数据包或数据报的格式——它的标头和有效负载。
在1980年的RFC 760定义之后，IETF在其Request For Comments 791中采用了至今广泛使用的定义。这是协议的第四个版本，但我们可以说它是第一个生产版本。
互联网协议（图片来源：RFC791）
它使用32位地址，将地址数量限制在40亿左右。这个限制解释了为什么非商业互联网用户从他们的ISP那里获得“动态IP地址”，而静态IP被认为是“附加值”并且经常需要额外收费。
他们正在配给。
不久之后，人们意识到32位地址是不够的，而且短缺迫在眉睫，因此发布了许多RFC试图解决这个问题。尽管这些解决方案在今天被广泛使用，并且是我们日常生活的一部分，但可以肯定地说这些相当于黑客。
Internet协议版本 6或IPv6是解决这些限制的一种方式，包括逐渐被以前的版本采用。它于1998年成为IETF的标准草案文件，并于2017年提升为互联网标准。
虽然IPv4地址空间受到其32位地址长度的限制，但IPv6标准被赋予128位，即 3.4 * 10 ^ 38 个可能的地址。这应该足以维持我们相当长的一段时间。
根据谷歌和用户之间的IPv6连接，截至2021年6月，IPv6的采用率刚刚超过35%。
IPv6采用
IP是互联网堆栈的基本层，定义了最基本的东西，但不保证交付、数据完整性或传输数据包的顺序。就其本身而言，它是不可靠的。IPv4的报头格式提供了报头校验和，传输节点使用它来验证报头的完整性。这使得它与 IPv6 版本不同，后者依赖于下面的链路层，使其速度更快。
互联网数据报头（图片来源：RFC791）
了解TCP和UDP的作用
现在是时候探索HTTP/3与TCP和UDP的匹配度了。
TCP
虽然IP是当今我们所有在线通信的底层，但TCP（传输控制协议）是Internet协议套件的更高级别部分，提供Web、邮件、文件传输 (FTP) 所需的可靠性 -用于互联网的应用层/协议。
这包括多步连接建立、握手、确保数据包顺序和丢失数据包的重传。它向发件人提供交付的反馈（Acks）等。还有校验和计算来检测错误。
所有这些都表明了使TCP成为可靠协议的许多步骤，使其成为我们今天使用的最臭名昭著的互联网服务的基础。
其可追溯到1974年 (RFC 675)和1981年 (RFC 793) 的规范至今未发生重大变化。
然而，TCP提供的可靠性并非没有代价。握手、交付反馈、订购保证和校验和所需的所有往返开销，这些开销可能被认为是弱且冗余的。它使TCP成为现代协议栈的瓶颈。HTTP/2已经达到了可以在TCP之上实现的速度提升的平稳期。
UDP
用户数据报协议(UDP) 也是Internet协议套件的组成部分之一，其规范可以追溯到1980年 (RFC 768)。
顾名思义，它是一种基于数据报的无连接协议。这意味着没有握手，也没有订购或交付的保证。这意味着确保交付、数据完整性和其他事情的任何可能步骤都留给了应用程序层。这意味着构建在UDP之上的应用程序可以根据具体情况选择将采用的策略，或者它可以利用链路层的元素（如校验和）来避免开销。
由于UDP与TCP一样广泛传播，因此无需在连接到Internet的各种设备上进行固件更新或对操作系统进行重大更改即可实现改进。
许多防火墙、NAT、路由器和其他只允许在用户和他们需要到达的服务器之间部署TCP或UDP的中间设备阻碍了新协议的部署。– HTTP/3解释
Hacker News上的这个帖子可以帮助我们开始理解在现有网络堆栈之上构建新HTTP版本背后的原因，而不是重新发明它（尽管还有更多内容）。
UDP数据包格式规范比较少，它的包头由包头和包数据的源端口、目的端口、长度（以字节为单位）和校验和组成。校验和可用于验证数据包标头和数据部分的数据完整性。
当底层协议层是IPv4时，校验和是可选的，对于IPv6是强制性的。到目前为止，UDP已被用于计算机系统时钟同步 ( NTP )、VoIP 应用程序、视频流、DNS系统和DHCP协议等。
QUIC和HTTP/3
QUIC（Quick UDP Internet Connections）由谷歌于2012年首次部署。它重新定义了网络层的边界，依赖于较低级别的UDP协议，重新定义了“用户空间”中的握手、可靠性特性和安全特性，避免了需要升级互联网系统的内核。
HTTP/2堆栈与HTTP/3堆栈
就像HTTP/2一样，由Google的SPDY或speedy带头的进步，HTTP/3将再次建立在这些成就的基础上。
虽然HTTP/2确实为我们提供了多路复用，并减轻了线头阻塞，但它受到TCP的限制。您可以将单个TCP连接用于多路复用在一起的多个流以传输数据，但是当其中一个流遭受数据包丢失时，整个连接（及其所有流）都 被扣为人质，也就是说，直到TCP完成它的事情（重新传输丢失的数据包）。
这意味着所有数据包，即使它们已经被传输并在目标节点的缓冲区中等待，也会被阻塞，直到丢失的数据包被重新传输。Daniel Stenberg在他关于http/3的书中称其为“基于TCP的行头块”。他声称，如果丢包率为2%，用户使用HTTP/1会做得更好，使用六个连接来规避这种风险。
QUIC不受此限制。QUIC建立在无连接的UDP协议上，连接的概念没有TCP的限制，一个流的故障也不必影响其余的流。
正如Cloudflare的Lucas Pardue所说：
卢卡斯·帕杜谈HTTP/3
专注于UDP流，QUIC实现了多路复用，而无需捎带一个TCP连接。QUIC在比TCP更高的层次上建立连接。QUIC连接中的新流不会被迫等待其他连接完成。QUIC连接还受益于取消TCP握手开销，从而减少延迟。
Cisco的人制作了一段有趣的视频，解释TCP的3次握手：
虽然QUIC取消了TCP可靠性特性，但它在UDP层之上弥补了这一点，提供了数据包的重传、排序等。谷歌云平台在 2018 年为其负载均衡器引入了QUIC支持，全球平均页面加载时间提高了8%，在延迟较高的地区提高了13%。
在谷歌浏览器、YouTube、Gmail、谷歌搜索和其他服务之间，谷歌能够在互联网的一大块上部署QUIC，而无需等待IETF。谷歌的工程师声称，在2017年，7%的互联网流量已经通过QUIC进行。
Google的QUIC版本只专注于HTTP传输，使用HTTP/2语法。IETF的人员（负责标准化QUIC的人员）认为，IETF版本的QUIC应该能够传输的不仅仅是HTTP。然而，就目前而言，任何基于QUIC的非HTTP协议的工作都被搁置了。
IETF工作组决定的另一件事是标准化版本将使用TLS 1.3加密而不是Google的自定义解决方案。与旧版本相比，TLS 1.3也有助于提高协议速度，因为它的握手需要更少的往返。
目前，谷歌继续在其产品中使用自己的QUIC版本，同时将其开发工作导向IETF标准。大多数其他互联网参与者都在IETF版本之上构建（除了加密之外，两者在其他方面有所不同）。
如果我们打开Chrome开发工具，并在Network选项卡的Protocol列中加载一些谷歌的产品，比如Gmail，我们会看到很多资源正在通过谷歌版本的QUIC协议加载。谷歌的产品如分析、谷歌标签管理器等也是如此。
谷歌服务QUIC
Cloudflare发布了关于标准化进展的非常广泛的更新。
虽然UDP确实为QUIC和HTTP/3提供了一些固有的优势，但它也带来了一些挑战。
TCP多年来一直是主流协议，而UDP不是，因此操作系统和它的软件堆栈通常没有得到优化。因此，据估计，QUIC的CPU负载/要求要高得多，是HTTP/2的两倍。
优化深入到操作系统的内核，以及不同的路由器和设备固件。这份Red Hat调优指南可能会为那些更倾向于技术的人提供更多关于该主题的信息。
可以说，QUIC尝试在更小、更灵活的协议之上重新设计TCP功能。
我们前面提到的QUIC连接结合了TLS和传输握手。一旦建立，它们将由唯一的CID（连接ID）标识。这些ID在IP更改中持续存在，并且可以帮助确保不间断的下载，例如从4G切换到WiFi。这是相关的，特别是因为越来越多的互联网流量是在移动设备上进行的。可能会出现问题，谷歌是否构思了这个元素来促进更好地跨不同连接和互联网提供商的用户跟踪。
TLS是强制性的，旨在使中间设备难以篡改或嗅探流量。这就是为什么经常看到防火墙提供商和供应商（如Cisco）将UDP协议视为一个问题，并提供禁用它的方法。中间商更难检查、监督或过滤QUIC流量。
QUIC流通过QUIC连接发送，单向或双向。流具有标识发起者的ID，以及流是单向的还是双向的，并且还提供流内流控制。
QUIC是传输层协议，而HTTP是其之上的层，即应用层协议或应用程序协议。
由于向后兼容至关重要，IETF推动了HTTP/3的实现，并将在响应中包含旧版本（HTT1或HTTP/2）。它将包含一个标头，通知客户端HTTP/3可用，以及端口/主机信息，如RFC7838中所述。
这与HTTP/2不同，后者可以在TLS握手中协商传输。但由于IETF几乎采用了基于QUIC的HTTP/3作为下一个标准，我们可以预期Web客户端会越来越多地期望对HTTP/3的支持。客户端可以缓存来自先前HTTP/3连接的数据，并在后续访问同一主机时直接连接（零往返或0-RTT）。
小结
有人认为，由于HTTP/2标准尚未完全采用，现在广泛推动HTTP/3可能还为时过早。这是一个有效的观点，但是，正如我们所提到的，这个协议已经看到了大规模的测试和实现。谷歌早在2015年就开始对其进行测试，Facebook也在2017年开始测试。
2022年，我们获得了来自Google Chrome和Brave等主要浏览器的HTTP/3支持。在基础设施方面，像Litespeed和Nginx这样的网络服务器都有HTTP/3的工作实现，而像Cloudflare这样的网络提供商已经部署了对HTTP/3的全面支持。
目前，HTTP/3仍处于Internet Draft阶段，最新的修订版将于2021年8月到期。未来将是令人兴奋的，因为我们可以期待看到主要软件供应商实施新版本的举措标准。
原文地址：https://www.wbolt.com/http3.html
