翻译：Alex

技术审校：刘连响

本文来自Compira Labs，作者为Ravid Hadar。

▲扫描图中二维码或点击阅读原文▲

领会音视频技术大会更多信息

影音摸索#011#

当上世纪70年月TCP被发现的时辰，我想没有人会预感到50年以后我们仍然在利用它。但究竟是，我们现在还在利用TCP。

在曩昔几十年中，TCP不竭成长，并新增了与牢靠数据传输、流量控制、堵塞控制等相关的各类特征。但很多研讨者以及包括我在内的从业者都以为TCP已至末路。自从TCP发现以来，互联网已经成为社会生活中很是重要的组成部分，但遗憾的是，TCP并没有与时俱进以满足不竭增加的需求。

不外鼓舞民气的消息是，在取代TCP方面，有一位最重要的“候选人”——它可以使互联网传输继续成长，并处理很多困扰互联网多年的题目。具体来说，这个有能够替换TCP的协议被人们称为QUIC，人们对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传输之上的利用层中。

为什么需要QUIC？

虽然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协议所带来的一些已知题目。

QUIC若何处理TCP所带来的应战？

首先，在UDP之上构建QUIC这一务实的决议所带来的上风相当明显。UDP在互联网上被普遍摆设，所以无需从零起头界说传输层（如从零起头，能够要花费几十年）。

相较于TCP，UDP的开销要少很多，这个特点使它更快速、更简单也更高效。但它存在一个严重缺点，那就是缺少牢靠性。UDP没法确保每个经过它发送的数据包传输，也没法确保数据包以正确顺序发送给接收方。

QUIC继续了TCP的特征，将它们构建于UDP之上，并增加了更多其他特征。TCP是传输层，TLS和HTTP2位于其上方的利用层，QUIC同时包括了利用层和传输层机制。是以，它的目标就是取代TCP传输层。

QUIC利用UDP作为底层传输协议，同时内置TLS加密，并连系了TCP的牢靠性相关特征。QUIC在利用层（即用户空间）获得进一步实现。是以，无需更新内核，你便可以停止大量点窜。

谁在利用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仍然是一个新标准，它的目标是重新设想互联网的诸多方面。而对如此众多的特征停止标准化需要时候。虽然QUIC在2013年初次提交给IETF，但直到2021年5月才正式推出，所以它仍然没有获得分歧生态的完全支持。

QUIC初次公布与正式标准化之间相隔时候太久，这使得很多厂商起头开辟自己的协议版本。他们在获得到最初公布的QUIC后，将自己的版本构建在其上。可是他们所利用的协议分歧于终极及官方版本。是以，QUIC有很多分歧的版本，其中一些并不支持官方版本的必备特征，且分歧的厂商需要时候将自己的版本调剂为与2021官方版本连结分歧。我们可以看到，这类过渡还处在早期阶段，比照实现了自己的gQUIC版本的谷歌正在迁移到IETF公布的QUIC版本。

也就是说，加倍普遍的QUIC采用仍然要面临很多应战，包括企业平安规定对QUIC的接管度、支持TCP回退的请求以及标准仍然相当根本这一究竟。我将在后续文章中加倍具体地说明其中一些应战。

QUIC具有互联网传输的潜力

TCP是为曩昔的互联网时代所设想的协议，它没法适用于本日的互联网，而QUIC的目标是处理TCP的很多题目，使互联网变得更平安、更灵敏而且可以不竭成长。需要谨记的是，我们现在仍处在QUIC协议摆设的早期阶段，接下来的几年我们将见证它能否可以完成成为TCP继任者的使命。QUIC的潜力不但仅是成为TCP的替换计划，它在实时协议上的一些标准化行动有能够使其取代在视频会议和云游戏中利用的实时通讯协议（如WebRTC）。

正文：

[1]https://w3techs.com/technologies/details/ce-http3

[2]https://techcommunity.microsoft.com/t5/storage-at-microsoft/smb-over-quic-is-now-in-public-preview/ba-p/2482964

称谢：

本文已获得作者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翻开重要的新篇章。