翻译：Alex
技术审校：刘连响
本文来自Compira Labs，作者为Ravid Hadar。
影音探索 #011#——QUIC
当上世纪70年代TCP被发明的时候，我想没有人会预料到50年之后我们仍然在使用它。但事实是，我们现在还在使用TCP。
在过去几十年中，TCP不断发展，并新增了与可靠数据传输、流量控制、拥塞控制等相关的各种特性。但许多研究者以及包括我在内的从业者都认为TCP已至末路。自从TCP发明以来，互联网已经成为社会生活中非常重要的组成部分，但遗憾的是，TCP并没有与时俱进以满足不断增长的需求。
不过鼓舞人心的消息是，在代替TCP方面，有一位最重要的“候选人”——它能够使互联网传输继续发展，并解决许多困扰互联网多年的问题。具体来说，这个有可能替代TCP的协议被人们称为QUIC，人们对QUIC的出现激动不已。但这种激动是否合理，我们将在今后的文章说明。本文我们将来了解发明QUIC的原因以及QUIC的使用人群。
QUIC是一种通用、安全、多路复用的传输层新型网络协议。它的目的是替代TCP（目前是互联网上用于数据传输的主流协议）。2012年，QUIC协议由当时还在谷歌任职的Jim Roskind开发。2013年，QUIC正式对外公布。
2015年，QUIC被提交给IETF进行标准化，但是直到六年以后，也就是2021年5月，IETF才发布了第一版标准化的QUIC，被命名为RFC 9000。同时，IETF还发布使用了QUIC的HTTP/3标准化版本。
QUIC吸纳了很多与TCP类似的属性，还有TLS加密，将它们置于UDP传输之上的应用层中。
虽然TCP已经“英勇地”服务多年，但它很可能已经走到了尽头。它最初设计用于有线互联网，根本没有想到今天的无线互联网会发展到如此容量和规模。许多专家很清楚，它无法适应今日互联网的发展。而QUIC的出现可以使网络更快、更高效、更安全，而最重要的是，可以不断发展。
在QUIC出现以前，TCP的主要替代选择是UDP。简而言之，TCP提供了可靠的互联网传输，其中可以确保数据的传输，而UDP提供了更快、但却非可靠的传输。QUIC的目的就是结合TCP的最佳特性和UDP传输层。
TCP的主要限制包括：
TCP仅定义了40字节的可选位，且几乎全部填满。结果就是，没有新特性的位置了。
许多中间件（如防火墙）假设TCP数据包将以某种确定方式构造。如果数据包与它们的预期相差太大，就会被拒绝或者延迟，这使得TCP协议几乎无法发展。
由于TCP在内核里实现，那么任何TCP传输的更新都需要经过新的内核修改。对于一些基础设施相对陈旧的公司来说，需要耗费数年才能采用新的特性。
TCP是传输层，没有内置加密（即TLS），所以它需要在上层增加。导致的结果就是需要很长时间才能建立安全连接，并且一些通过TCP传输的数据（比如数据包头部）没有被加密，从而产生安全漏洞。
QUIC和HTTP/3一起使用的目的就是代替HTTP/1（或2）和TCP的组合，以及解决TCP协议所带来的一些已知问题。
首先，在UDP之上构建QUIC这一务实的决定所带来的优势相当明显。UDP在互联网上被广泛部署，所以无需从零开始定义传输层（如从零开始，可能要耗费几十年）。
相较于TCP，UDP的开销要少很多，这个特点使它更快速、更简单也更高效。但它存在一个重大缺陷，那就是缺乏可靠性。UDP无法确保每个通过它发送的数据包传输，也无法确保数据包以准确顺序发送给接收方。
QUIC继承了TCP的特性，将它们构建于UDP之上，并添加了更多其他特性。TCP是传输层，TLS和HTTP2位于其上方的应用层，QUIC同时包含了应用层和传输层机制。因此，它的目的就是代替TCP传输层。
QUIC使用UDP作为底层传输协议，同时内置TLS加密，并结合了TCP的可靠性相关特性。QUIC在应用层（即用户空间）获得进一步实现。因此，无需更新内核，你就可以进行大量修改。
作为一种通用传输协议，QUIC可以用于许多基于互联网的工作流，但部署的第一步就是将网页浏览转移到QUIC，因为它所带来的最直接的好处就是基于HTTPS的Web浏览。
作为TCP的继任者，QUIC只能与HTTP/3一起使用。为了使用该协议，客户端和网站都需要支持它，但因为只有少数网站使用HTTP/3，所以这也成为了QUIC协议被广泛采用道路上的一个阻碍。根据W3Tech[1]，截止2021年10月2日，约35%的网站仍然在使用HTTP/1；约45%的网站迁移到了HTTP/2，而只有大约20%的网站正在使用HTTP/3和QUIC。
截止2021年中旬，QUIC占据了互联网流量的12%。谷歌是第一家（也是最有名的）采用QUIC协议的公司（毫不意外，毕竟QUIC协议是由谷歌员工开发的）。在其生态中，谷歌拥有自己的服务器、应用程序、服务和客户端，所以它很容易实现QUIC，并将众多应用迁移到新的框架。30%的YouTube流量已经转移到了QUIC。
接着是Facebook（现更名为Meta），它已经将70%的流量迁移到了QUIC。Facebook和Instagram移动应用程序都已经在最大限度地使用QUIC。
这就是QUIC协议采用所面临的现状。微软只有少量流量使用了QUIC；在流媒体领域，只有YouTube和Facebook Live支持了QUIC。流媒体视频接近80%的Web流量，大部分依然使用的是TCP。流媒体巨头公司Netflix和Amazon Prime都没有支持QUIC。不过，微软有将其VPN产品从TCP迁移到QUIC的倾向[2]。
目前支持QUIC的生态包括：
浏览器： Chrome（默认）、Edge、Firefox、Safari和其他默认使用TCP的浏览器（但将QUIC作为可选选项）。
应用： 所有来自谷歌的应用，如Gmail和YouTube；Facebook的应用；Uber。
服务器/CDN： Akamai、微软、Apple、谷歌、Cloudflare、Fastly、Caddy和NetApp。其中一些CDN已经验证了QUIC的实现，但几乎它们所有的流量都还在使用TCP。
Web服务器： LiteSpeed、H20、Ngnix和Apache。
负载均衡器： LiteSpeed和F5 BIG-IP。
技术社区项目： 基于chromium实现的libquic、反向代理（充当反向代理服务器的Docker镜像）。
编程语言： Go（quic-go）、Quic.NET（C#）。
如你所见，基于Web的基础设施已经开始向QUIC迁移，但是在大多数情况下，QUIC还不是默认选项，而且一些大公司依然没有支持QUIC。
QUIC依然是一个新标准，它的目的是重新设计互联网的诸多方面。而对如此众多的特性进行标准化需要时间。虽然QUIC在2013年首次提交给IETF，但直到2021年5月才正式推出，所以它仍然没有获得不同生态的完全支持。
QUIC首次公布与正式标准化之间相隔时间太久，这使得很多厂商开始开发自己的协议版本。他们在获取到最初发布的QUIC后，将自己的版本构建在其上。但是他们所使用的协议不同于最终及官方版本。因此，QUIC有很多不同的版本，其中一些并不支持官方版本的必备特性，且不同的厂商需要时间将自己的版本调整为与2021官方版本保持一致。我们可以看到，这种过渡还处在早期阶段，比如实现了自己的gQUIC版本的谷歌正在迁移到IETF发布的QUIC版本。
也就是说，更加广泛的QUIC采用依然要面临许多挑战，包括企业安全规定对QUIC的接受度、支持TCP回退的请求以及规范依然相当基础这一事实。我将在后续文章中更加详细地说明其中一些挑战。
TCP是为过去的互联网时代所设计的协议，它无法适用于今日的互联网，而QUIC的目的是解决TCP的许多问题，使互联网变得更安全、更灵敏并且可以不断发展。需要谨记的是，我们现在仍处在QUIC协议部署的早期阶段，接下来的几年我们将见证它是否能够完成成为TCP继任者的使命。QUIC的潜力不仅仅是成为TCP的替代方案，它在实时协议上的一些标准化举措有可能使其代替在视频会议和云游戏中使用的实时通信协议（如WebRTC）。
注释：
[1]https://w3techs.com/technologies/details/ce-http3
致谢：
本文已获得作者Ravid Hadar授权翻译和发布，特此感谢。
原文链接：
https://www.compiralabs.com/post/quic-and-the-future-of-internet-transport/
历时五年，HTTP/3终于标准化了！
昨日，IETF QUIC和HTTP工作组成员Robin Mark在推特上宣布，历时5年，HTTP/3终于被标准化为RFC 9114！详情参见：
https://www.rfc-editor.org/rfc/rfc9114.html
同时， HTTP/2也被更新为新的RFC 9113，详情参见：
https://www.rfc-editor.org/rfc/rfc9113.html
Robin写道，新发布的HTTP/3标准将与RFC 9204（QPACK header压缩） 和 RFC 9218（可扩展的优先级）一起为Web打开重要的新篇章。
@2017-2024 LiveVideoStack版权所有. 京ICP备20010033号-1 
京公网安备 11010502042092号
