QUIC协议加速互联网

2015/05/24 17:35
阅读数 1.6K

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为跳板展现协议原型和效果,然后再提出作为协议草案,但结果尚待观察。

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

展开阅读全文
加载中

作者的其它热门文章

打赏
1
2 收藏
分享
打赏
0 评论
2 收藏
1
分享
返回顶部
顶部