QUIC协议加速互联网

2015-04-21 12:06 | DevStore编辑 陈儿

最近Google开始考虑用改进版的UDP协议QUIC给web提速。根据它近日公布的性能评估，这一融合了UDP与TCP优势的协议似乎提升效果明显。

那QUIC与其他协议的区别和优势又在那里，谷歌究竟是怎么想的呢？

讨论这个问题前，先来普及一下网络协议的基础知识

QUIC协议是怎么回事

QUIC，Quick UDP Internet Connections）的缩写，一种实验性的传输层网络传输协议，由Google公司开发，在2013年实现出来。QUIC使用UDP协议，在两个端点间创建连接，支持多路复用连接。在设计之初，QUIC希望能够提供等同于SSL/TLS层级的网络安全保护。减少数据传输及创建连接时的延迟时间，双向控制带宽，以避免网络拥塞。Google希望使用这个协议，来取代TCP协议，使网页传输速度加快。

以往典型的安全TCP连接（TCP+TLS）往往需要在发送与接收端先进行2、3轮的握手通信才能正式开始数据传输。而利用QUIC协议，如果双方此前通信过的话马上就可以对话（即便双方此前未通信过时延也只有100毫秒，是TCP+TLS用时的1/3）。此外，QUIC还增加了拥塞控制和自动重传等功能，所以可靠性上要比UDP更高。

QUIC比UDP更快，那UDP究竟怎样

TCP/IP协议族是互联网的基础。其中传输层协议包括TCP和UDP协议。与TCP协议相比，UDP更为轻量，但是错误校验也要少得多。这意味着UDP往往效率更高（不经常跟服务器端通信查看数据包是否送达或者按序），但是可靠性比不上TCP。通常游戏、流媒体以及VoIP等应用均采用UDP，而网页、邮件、远程登录等大部分的应用均采用TCP。

提到QUIC协议，就不能不说谷歌上一次的HTTP协议改进：HTTP 2，这也是万维网（WWW）的基础协议HTTP 16年来的首次重大升级，其中HTTP/2主要以SPDY技术为主。

SPDY协议

SPDY，一种开放的网络传输协定，由Google开发，用来传送网页内容。基于传输控制协议（TCP）的应用层协议 。Google最早是在Chromium中提出的SPDY协议。目前已经被用于Google Chrome浏览器中来访问Google的SSL加密服务。

SPDY当前并不是一个标准协议，但SPDY的开发组已经开始推动SPDY成为正式标准（现为互联网草案），HTTP/2主要以SPDY技术为主。Google Chrome，Mozilla Firefox，Opera和Internet Explorer均已支持SPDY协议。SPDY协议类似于HTTP，但旨在缩短网页的加载时间和提高安全性。SPDY协议通过压缩、多路复用和优先级来缩短加载时间。

2012年，谷歌推出改协议，今年2月IFTF HTTP工作组主席Mark Nottingham博客消息，HTTP 2正式定稿，已提交RFC Editor，开始全面标准化的工作。尽管HTTP/2的全面标准化尚未完成，但目前已有Firefox、Chrome（PC及Android版）、Safari、Opera、iOS版Safari、Windows 8 IE 11都已经支持HTTP/2.0。

关于谷歌为什么要推出QUIC，以及优化原理一些行业人士给出了自己的理解：

为什么要推出QUIC

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

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

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

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

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

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

基于一条TCP连接的SPDY复用连接会面临这样的情况：当有丢包发生时，所有连接都将阻塞，这是由TCP的拥塞控制特性决定的。丢包必须恢复，而恢复过程中，或早或晚，滑动窗口总有停等的时刻，耗费一个RTT。在广域网上，一个RTT相当于50-100ms。相比较而言，当x条并行HTTP连接中，有一条丢包，只会阻塞一条。
QUIC是和HTTP同一层的应用层协议，其核心是将丢包控制工作转移到应用层。由于QUIC基于UDP，可以不理会丢包，快速投递，再用丢包恢复方法保证可靠性。除此之外，基于一条TCP连接的SPDY和多条并行HTTP连接相比，没有优势可言。多条连接中，每个连接都有一个拥塞窗口，不受彼此丢包影响。

QUIC优点：

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

1) 拥有SPDY的所有优点（多路传输，支持优先级等等）

2) 零往返时间连接

3) 数据包同步，有效降低数据丢包率

4) 转发问题连接，有效减少重发延迟

5) 自适应拥塞控制（对TCP友好），有效减少移动客户端重新连接的次数

6) 与TLS等效的加密措施

7) Chrome支持与Google的QUIC通信

8) 前向纠错

从目标来看，QUIC跟SPDY（HTTP/2基础）很多方面是类似的，但是后者仍然基于TCP，所以仍然会存在部分相同的时延问题。

不过这样也许你会问为什么Google不干脆改进TCP？根据Google的解释，不这么做的原因是TCP往往直接内置到了操作系统内核当中，这是Google所无法控制的。所以他们就拿UDP改良版来开刀，以期更快地测试性能改进效果。

Google从去年开始就已经在Chrome浏览器上进行了实验，实际上目前Chrome到Google服务器的请求当中大概有一半已经在采用QUIC协议。

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

Google希望QUIC的性能得当证明后能够移植到TCP和TLS上面，称未来打算将HTTP2-over-QUIC作为新的协议提交给IETF。但是这显然需要与IETF的配合以及长期努力。这一套路跟SPDY很像，都是以Chrome为跳板展现协议原型和效果，然后再提出作为协议草案，但结果尚待观察。

一流的公司做标准，谷歌就是这样做的，一直以来，谷歌都在试图重塑各种互联网核心协议，以推进更快更可靠更安全的互联网，当然，谷歌费尽心力去优化底层协议，也是为自己考虑，只有更快、更可靠、更安全的互联网，才能让赖以搜索引擎为生的谷歌发展得更好。