揭秘！扒一扒能加速互联网的QUIC协议

今天早上，一则新闻《谷歌希望凭借其 QUIC 协议加速互联网》引起了笔者注意，这篇新闻中提到，大约有一半来自 Chrome 浏览器对谷歌服务器的请求，现在由 QUIC 协议负责处理。

QUIC 是什么？我们光从字面上来看，就知道它很快，它代表了快速 UDP Internet 连接（全称是 Quick UDP Internet Connections）。QUIC 是由谷歌开发，在 2013 年就实现的网络协议，当年 6 月就加入了最新版的 Chrome Canary 中。

QUIC 虽然类似于 SPDY，但根据维基百科介绍， 前者是一个实验性传输层协议，而后者则工作在传输层，它的目标主要是优化或替换面向连接中使用 TCP 协议的 Web 应用程序。另外，QUIC 某种程度上与 TCP Fast Open 也类似，但 2011 年面世的 TCP Fast Open 目前尚没有大范围使用。

QUIC 在两个 UDP 端点之间支持一组多路连接，这样的设计目的是为了给 TLS/SSL 提供安全保护，减少连接、传输延迟和宽带，从而避免在各个方向的拥挤。QUIC 主要优化对象是使用 TCP 连接的 Web 应用程序。

为什么要推出 QUIC？

新浪博客用户“逝去的青春”在他的一篇博文中有做介绍：

TCP、UDP 都是计算机网络通信层的主要协议。TCP 是面向连接的，更强调的是传输的可靠性，UDP 是面向无连接的，也即在通信双方进行数据交换之前，无需建立连接，只要知道对方地址即可发送数据，由于 UDP 协议是无连接方式的协议，所以它的效率高，速度快，占资源少。为了集合两者的优点，谷歌公司推出了 QUIC。

Via：访问 Google 的神器：Chrome 的 QUIC 协议

QUIC为什么能够在两者基础上进行优化？

Linux 平台软件工程师 Lenky 则在个人站点上一篇文章中做了说明：

因为光速不变，而且抛开网络繁忙这些额外整体因素（因为我们这里考虑的是局部，要做的目标也是局部优化，因此整体因素属于更上一 层的研究），那么在网络上，任意确定两端之间的往返时延 RTTs（round trip times）基本上是固定的，因此，减少单个连接网络延迟的唯一办法就是让建立一条连接所需耗费的 RTTs 个数尽量的少。从这个需求可以看出，对于 TCP 协议本身而言，已经很难做到对应的优化了，一方面是因为 TCP 所要求的握手协议、拥塞控制等固定了其所必须的 RTTs 个数，而另一方面是因为 TCP 实现于操作系统协议栈内，要改变实际用户的操作系统必定是相当难的。

QUIC 尝试解决那些 SPDY 无法涵盖的问题点。首先是 TCP 对头阻塞，其次是 TCP 拥塞阀门阻塞，也就是这两个点导致的 SPDY 优势无法充分发挥。

Via：QUIC 简介

ChinaUnix 博客用户 Henrystark 更为详尽地描述了优化原理

基于一条 TCP 连接的 SPDY 复用连接会面临这样的情况：当有丢包发生时，所有连接都将阻塞，这是由 TCP 的拥塞控制特性决定的。丢包必须恢复，而恢复过程中，或早或晚，滑动窗口总有停等的时刻，耗费一个 RTT。在广域网上，一个 RTT 相当于 50-100ms。相比较而言，当x条并行 HTTP 连接中，有一条丢包，只会阻塞一条。

QUIC 是和 HTTP 同一层的应用层协议，其核心是将丢包控制工作转移到应用层。由于 QUIC 基于 UDP，可以不理会丢包，快速投递，再用丢包恢复方法保证可靠性。除此之外，基于一条 TCP 连接的 SPDY 和多条并行 HTTP 连接相比，没有优势可言。多条连接中，每个连接都有一个拥塞窗口，不受彼此丢包影响。

Via：QUIC 和 TCP

QUIC 优点：

看了这么多，有些内容确实是比较生涩难懂，那还是挑开说吧，它都有哪些特性或优点：

• 拥有 SPDY 的所有优点（多路传输，支持优先级等等）
• 零往返时间连接
• 数据包同步，有效降低数据丢包率
• 转发问题连接，有效减少重发延迟
• 自适应拥塞控制（对 TCP 友好），有效减少移动客户端重新连接的次数
• 与 TLS 等效的加密措施
• Chrome 支持与 Google 的 QUIC 通信
• 前向纠错

大部分 Via： Google 期望使用 QUIC 给互联网加速

QUIC 的其中一个优势——通信通道的定义基于 ID 而不是 IP+ 端口，使得切换网络后继续转发连接成为可能（例如从 WiFi 网络进入移动网络）。值得一提的是，所有 QUIC 连接都使用特殊的机制进行加密。另外，QUIC 还能够快速迭代，这主要因为 QUIC 部署在客户端级别，而不是在内核级别，使得迭代周期由以年计算变为以周计算。

根据 Google 的开发人员 Robbie Shade 的说法，采用 TLS 时，在一次跨大西洋的连接中 TCP 握手要耗时 300ms，而 QUIC 可以将延迟降为 100ms，那效果究竟怎么样呢？天极在《谷歌欲用改良版的 UDP 协议 QUIC 提高网页速度》文章中，是这么提到：

数据表明 75% 的连接均可利用 QUIC 的优势，哪怕预先建立的优化连接(Google 搜索)采用 QUIC 后页面加载性能仍然能提高 3 个百分点。而时延严重的一些 web 应用，在采用 QUIC 后的改进效果则要更加明显。比如有用户报告 油Tube 重新缓冲次数减少了 30%。

对于安全性，谷歌特别表示，TCP 的支持往往是直接内置到操作系统内核，谷歌没有任何控制权。目前谷歌只是希望证明 QUIC 是有效的，如果确实很好，它会迁移到 TCP 和 TLS，而在未来还会向 IETF 提交，从而让 QUIC 能成为 HTTP2 中一个新的互联网标准。

谷歌为什么要做这件事呢？两年前谷奥的一篇文章道出了真相——谷歌一直在试图重塑各种互联网核心协议，以推进更快更可靠更安全的互联网。当然这肯定是有私心，只有更快、更可靠、更安全的互联网，才能让赖以搜索引擎为生的谷歌发展得更好。

最后：关于 QUIC 地内容大部分都在这里，如果这些信息还不能满足你，文中的一些链接打开后，你会发现会有更多内容和链接等着你，欢迎有心的人继续挖掘。