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

jopen 9年前

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

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

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

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

来自: CSDN