QUIC进入IETF最后征求意见，互联网的又一次巨大飞跃

在 2020 年 10 月 22 日，Cloudflare 发布一篇官方博文《 A Last Call for QUIC, a giant leap for the Internet 》。这篇文章宣告了在 IETF（互联网工程任务组）发展近 4 年后，描述 QUIC 和 HTTP/3 的文件系统的草案 32 被纳入 IETF 最后征求意见。

IETF QUIC 工作组联合主席 Lucas Pardue 表示，“对于工作组来说，这是一个重要的里程碑。现在，我们将告诉整个 IETF 社区，我们已经几乎完成了工作，欢迎他们的最终审核。”

腾讯 TEG 云架构平台部专家工程师，腾讯云 CLB 研发负责人罗成对 InfoQ 记者说：“last call 意味着 QUIC 在社区范围内的公开讨论即将结束。在接下来的几周时间有可能发布正式的 RFC。QUIC RFC 如果定稿，对于后续 QUIC 协议的工程化和开源社区的支持也将有极大的推动作用，QUIC 的使用将会越来越普及。

如果你访问一个启用了 HTTP/3 的网站，比如 https://cloudflare-quic.com 。你会看到响应头包含 Alt-Svc: h3-29="…。一旦最后征求意见完成且 RFC 发布，你就会看到网站简单返回 Alt-Svc: h3="…。

QUIC 源起

Quic，全称为 quick udp internet connection，即快速 UDP 网络连接。最初，它是一种由谷歌开发的网络传输协议，2013 年实现。据悉，QUIC 使用 UDP 协议，在两个端点间创建连线，且支持多路复用连线。

据罗成介绍，一直以来，谷歌对用户的 web 访问速度非常重视，投入很大：2012 年，谷歌开始实验性研究 QUIC 协议，目的是提升用户使用谷歌搜索的访问速度。当时，一起研发的还有一个协议——SPDY，即 HTTP2 的前身。但是，SPDY 是基于 TCP 实现的，存在一些无法克服的缺陷。

“所以，谷歌希望另起炉灶，完全抛开 TCP，使用 UDP 来实现一套可靠的快速的传输协议。”他说。

2013 年，QUIC 协议开始在数百万 Chrome 用户上进行实验；2015 年，QUIC 的收益和演进路线已经非常明确。2015 年 6 月，QUIC 的网络草案被正式提交至互联网工程任务组（IETF）。

IETF 则在 2016 年正式成立 QUIC 工作组，对 QUIC 协议草案进行讨论和改进。最终，2018 年 10 月，互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP（HTTP over QUIC）重命名为 HTTP/3，成为互联网下一代标准传输协议，引起业界极大的兴趣。

罗成表示，“在国内，腾讯也很早就开始了对 QUIC 的研发，2015 年，开始研发 QUIC 协议；2016 年，在内部大规模使用；2017 年，我们在腾讯云的 CLB 负载均衡器和 CDN 产品上发布了对 QUIC 的支持。也是继谷歌之后，第二家这么早大规模使用 QUIC 协议的互联网厂商。“

QUIC 协议和 HTTP/3 的影响

在罗成看来，QUIC 的普及会对互联网带来三方面的影响：

第一，提升整个互联网的访问速度。因为协议本身支持 ORTT 建立连接、多路传输等特性。

第二，提升互联网的传输安全。因为 QUIC 传输的内容默认都是加密的，这对人们的隐私保护非常重要。

第三，由于 QUIC 基于应用层实现，减少了对操作系统内核和中间设备的依赖。QUIC 也能推动互联网流量工程和拥塞控制算法的快速演进，进一步促进访问速度、QOS、流量成本等方面的优化。

据了解，只要在访问速度、访问安全以及网络健壮性有要求的领域，QUIC 都能带来明显的作用，比如云游戏、音视频、页面浏览、搜索引擎、广告加载等。

具体说来，服务端和 App 在支持 QUIC 协议后，用户访问同样的业务会更快、更安全、更顺畅。比如，在无需任何修改的情况下，App 的访问速度提升 15%以上；WiFi 切换到 4G 或 5G 时，你不会感觉到卡顿。

根据罗成的解释，QUIC 之所以能更快，原因有三：

• QUIC 协议支持 ORTT 握手建连。QUIC 基于 UDP 传输，不像 TCP 需要三次握手来建立连接。而在安全传输层面，它以前使用 QUIC crypto 协议，现在支持 TLS 1.3 协议，都能实现更高比例的 ORTT 安全建连。相比 HTTP/2 协议，建立连接的 RTT(round trip time)从 2-3 个直接减少到 0-1 个，这意味着 QUIC 发送第一个数据包时有了几百毫秒的优势。此外，QUIC 的 ORTT 还能实现更多的定制。
• QUIC 改进的拥塞控制算法。一方面，协议层做了更明确的限制也能携带更多的信息，比如严格递增的序列号、更准确的 ack delay、更大范围的 sack 范围等。另一方面，由于 QUIC 基于应用层实现，可以有更大的扩展性。
• QUIC 支持多路复用且减少了队头阻塞。HTTP/2 虽然也支持多路复用，但是由于 TCP 协议的 head of line block（队头阻塞），导致多路复用的效果也打了折扣。但是，QUIC 可以避免这样的拥塞，因为它基于应用层实现，协议栈能允许部分已经完成的 stream 进行交互，不会因为丢了几个包就导致后面的 stream 也被阻塞。

在安全性上，由于 QUIC 协议默认使用了安全传输协议，实现了证书认证、秘钥协商、内容加密、一致性校验等安全功能。这对人们的隐私保护也会很彻底，而被中间者劫持的可能性也非常低。

在连接迁移方面，罗成举了一个例子。用户经常在移动网络下切换，家里用 WiFi 看直播，一出门，WiFi 就断了，只能连上 4G。由于网络断了，直播一定会中断几秒钟。如果使用 QUIC 的连接迁移后，用户从 WiFi 切换到 4G，他不会感到卡顿。

“其主要原理就是 QUIC 的连接迁移功能。连接没有中断，用户的数据传输也没有中断。但是，连接中断的概念虽然容易理解，在服务端支持上却比较困难，比如腾讯云 CLB 就需要 4 层负载均衡、7 层负载均衡以及进程间联动，还包括进程重启以及平滑退出时的设计。”他说。

企业面临的挑战

无论是安全性，还是用户体验，QUIC 协议和 HTTP/3 对企业都是更好的选择。

但是，罗成对 InfoQ 记者表示，“大规模使用 QUIC 的话，会有很多挑战。”

挑战一，如何实现 QUIC 协议的支持。由于 QUIC 协议非常复杂，且 RFC 尚未定稿，导致目前缺乏一个成熟通用的服务框架支持。并且，一些开源的框架也很不完善，比如 Nginx、MSQUIC 等。

挑战二，QUIC 非常消耗 CPU 资源，这会极大增加服务器成本。不管是默认加解密，还是 UDP 协议栈以及 QUIC 协议栈，相比传统的基于 TCP 的协议，比如 HTTPS，要增加一倍以上的机器成本。

挑战三，QUIC 的运营工具非常欠缺，问题排查非常困难。QUIC 协议比较新，而类似 TCP 的 tcpdump、wireshark 等工具都不完善。另外，由于 QUIC 协议的序列号都进行了加密，协议栈也是重新在用户态实现的，所以以前 UDP/TCP 的一些抓包和分析工具都失效了，需要重新开发。比如，用户丢的包，以前用 tcpdump，外加 wireshark 就能分析在哪丢的包、为什么丢包，但是这无法适用于 QUIC，因为不仅传输层帧格式变了，而且帧的头部是加密的，传统工具都无法解析。

写在最后：

QUIC 协议不仅给互联网用户带来全新的体验，更快的访问，而且更加安全。对于它的意义，正如 IETF QUIC 工作组联合主席 Lucas Pardue 所说，“新协议是互联网的一个巨大飞跃，因为它带来了新的机遇和创新。”