QUIC协议能加速互联网将成为未来谷歌网站新标准

为什么要推出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地内容大部分都在这里，如果这些信息还不能满足你，文中的一些链接打开后，你会发现会有更多内容和链接等着你，欢迎有心的人继续挖掘。