转载

揭秘！扒一扒能加速互联网的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后的改进效果则要更加明显。比如有用户报告YouTube重新缓冲次数减少了30%。

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

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

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

正文到此结束