6月7日，IETF贡献者、HTTP/3和QUIC工作组成员Robin Marx在推特上宣布：“历时五年，HTTP/3终于被标准化为RFC 9114！”

作为HTTP的最新版本，HTTP/3将带来重大机遇和挑战。

HTTP/3和QUIC

与HTTP/2相比，HTTP/3中有哪些重大改进？

C++音视频开发学习地址：【免费】FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发-学习视频教程-腾讯课堂

作为网络协议，HTTP/3其实和HTTP/2非常相似，它提供相同的特性，如头部压缩（header compression）、服务器推送（server push，虽然依然不推荐普遍使用）、数据流优先级（stream prioritization，尽管以一种更简单、更易用的使用方式）。最主要的变化是HTTP的底层协议：HTTP/2所使用是TCP+TLS，而HTTP/3使用的是QUIC——这是一个与TLS深度集成的新型传输协议。相较于HTTP/2，QUIC和TLS的使用为HTTP/3提供了很多优势，尤其是在（网页加载）性能方面。

首先，QUIC拥有更快的连接设置，原因是它将传输层握手（TCP的SYN+SYN/ACK+ACK bootstrap）和加密握手（TLS设置）合并到一次RTT中（而HTTP/2需要2~3个RTT）。除此之外，HTTP/3可以受益于TLS 1.3的0-RTT特性，意味着可以发送HTTP请求，并能够在第一次握手期间接收到（部分）响应。尤其当客户端和服务器在地理上相距遥远时，快速连接十分有帮助。

C++音视频开发学习资料：点击领取→音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

其次，QUIC使用了HTTP/2中的多路复用概念，并将它应用到传输协议层。这一点在技术上不太好理解，不过结果就是QUIC（也指HTTP/3）对于丢包和重新排序的恢复能力得到了提升。这解决了TCP长期存在的“队头阻塞”问题：其中HTTP/2连接上的一个丢包就可能导致其后的数据在等待重传的时候遭到阻塞。在某些情况下，HTTP/3可以解决某些数据的阻塞，以便更早地处理、提交或者执行这些数据。

再次，QUIC还有很多其他性能上的优势。比如，新的“连接迁移”特性将使切换网络（如从Wi-Fi切换到4G）更加无缝（虽然目前少有部署支持）。QUIC在如何确认接收的数据包方面也更加智能，从而更容易决定如何/何时重传丢失的数据包并调整拥塞控制逻辑。这一优势对于HTTP/3并没有太大用处，但是它可以允许其他协议（比如WebTransport或者MASQUE代理）在QUIC之上运行。

总结一下，HTTP/3主要受益于重要的新型QUIC协议，并将随着不断添加新的优化和特性而继续获益。

配置该协议，又有哪些需要注意的地方呢？

HTTP/3与HTTP/2太相似了，所以网站想在HTTP/3上正常运行几乎不需要任何更改。这与我们从HTTP1.1迁移到HTTP/2非常不同，后者通常需要进行大量的更改。

对于应用程序（以原生应用为例）来说，你将为了HTTP/3（通常也包括QUIC的实现）而使用完全不同的软件库。这里我会推荐Cloudflare的quiche、ngtcp2或quickly，它们全部开源并且在GitHub上都能找到。在一些不常见的场景中，你可以使用一个内置平台实现：iOS/OSX已经在它的网络库中支持了HTTP/3和QUIC。

如果你只是想通过HTTP/3或者QUIC发送、接收一些数据，那么使用上述实现应该不会太难。不过当你真的想为了优化高级性能（如0-RTT或者连接迁移）而调整应用时，情况就会变得困难起来。为此，你需要真正理解HTTP/3和QUIC的工作原理、它们的局限性以及如何从各类实现的API中正确启动它们。这个时候你就得拿出几天时间深入研究源代码了。

它的一些高级特性和基于0-RTT的安全策略以及负载均衡，HTTP/3和QUIC是出了名的复杂。在这一点上，我强烈建议你不要自己部署HTTP/3，而是选择大型CDN公司（如Akamai、Cloudflare或者Fastly）已有的部署。很快，你将能够使用AWS和Azure中开箱即用的HTTP/3，到那时，它应该已经成为谷歌托管选项了。

对于其他应用场景，比如视频流媒体，QUIC意味着什么？它与WebRTC相比如何？新的WebTransport呢？

因为QUIC是一个通用传输协议，所以我们确实可以在更多的应用场景使用它（而不仅仅将它用于网页加载）。IETF中有一个特殊的“Media over QUIC”工作组正在认真思考视频传输（包括直播和点播）问题。然而，目前还不清楚如何能够/应该/将会以最佳方式实现，因为该领域中现有的产品（如WebRTC）已经相当强大并获得广泛部署，而QUIC是否（如何）将带来更多优势也未可知。除此之外，仅将现有的协议运行在新的QUIC上也相当困难，这些协议通常都需要某些更改。目前还在非常早期的阶段，但是学术界已经展示了一些有趣的概念：比如将可靠（关键帧）和非可靠（delta压缩帧）视频数据在单一QUIC连接中合并。我想我们将不会看到WebRTC-over-QUIC，但是未来肯定会出现它的替代。

WebTransport是另一个有趣的方向，目的是向Web开发者展示更广泛的网络特性。虽然我们在网页中被限制在HTTP（通过fetch()）或者长连接（通过WebTransport），但WebTransport将允许对网络性能进行更底层的访问。我们仍旧不能发送裸的UDP数据，但WebTransport至少允许在多人游戏以及自定义流媒体方面做更多的优化。

QUIC最终将取代TCP还是仅仅改进它？

QUIC并不会完全取代TCP。总会有人选择TCP更简单的设置或者运行那些无法轻松更新、相对陈旧的应用。我能想到的一个例子就是Netflix，这家公司已投入大量资金来优化他们的TCP+TLS+HTTP/2技术栈，用以直接从Linux内核传输视频。短时间内，他们不太可能切换到HTTP/3。我确实觉得随着时间的推移，大部分应用都将迁移到QUIC上，新的应用级别的协议也将被设计为只与QUIC一起使用（同时弃用TCP）。

互联网协议的未来发展会是怎么样的？

如此重度加密QUIC的主要原因之一就是防止它变得陈旧且难以发展——这是TCP的致命缺陷。TCP被广泛地部署与实现于如此多的不同设备中，核心协议的任何更改都要求大部分设备的更新，而这种更新可能需要10年以上的时间。

使用QUIC的话，好处就在于只有客户端和服务器将添加新功能用以更新，而其他（如防火墙和负载均衡器）仍保持稳定（至少在添加最初的QUIC支持后）。我并不十分确定这种情况是否真的会发生（你依然可以使用QUIC进行TLS拦截/代理），但我确实认为这是朝正确方向迈出的重要一步。

接下来几十年，我想我们很可能都将使用QUIC和HTTP/3（或者至少是它们的升级版本），然后再决定我们需要新的协议来应对量子网络和星际通信所带来的新机遇。