订阅业界RSS CSDN首页> 业界

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

发表于2015-04-20 09:55| 次阅读| 来源CSDN| 0 条评论| 作者我是你的主题曲哥哥

摘要:日前谷歌在官博宣布,大约有一半的Chrome用户访问谷歌服务都由QUIC协议处理。QUIC是什么?谷歌为什么要推出它?QUIC的原理是什么?它为什么能够在UDP、TCP上进行优化?它究竟带来了多大的提升?本文对此进行了解读。


今天早上,一则新闻《谷歌希望凭借其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地内容大部分都在这里,如果这些信息还不能满足你,文中的一些链接打开后,你会发现会有更多内容和链接等着你,欢迎有心的人继续挖掘。

0
0