首页 > *nix技术, 内核技术 > QUIC简介

QUIC简介

2013年8月6日 发表评论 阅读评论 8,917 次浏览

QUIC,即Quick UDP Internet Connection,类似于SPDY,同样也是由Google公司在现有已存协议之上进行了扩展设计,而旨在减少网络延迟。之前我曾介绍过SPDY的相关信息,SPDY工作在应用层,而这里的QUIC工作在传输层。虽然QUIC的名字暗示着它类似于一个被修改过的UDP协议,但它的目标却是优化或替换那些需要使用面向链接的应用程序中所采用的TCP协议。

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

QUIC尝试解决那些SPDY无法涵盖的问题点。首先是TCP对头阻塞,其次是TCP拥塞阀门阻塞,也就是这两个点导致的SPDY优势无法充分发挥。这很好理解,我们知道SPDY是跑在TCP协议之上的,如果瓶颈在TCP这一层,那么上层做再多的优化都是白搭。

另外,SPDY采用的SSL/TLS也会带来两个性能问题:1,恢复已断的开会话将引进一个额外的握手,而这纯粹只是SSL/TLS协议的设计如此,并非安全或其他什么特别的原因。2,对历史数据包的解决需要按顺序进行,这将导致延迟数据包所带来的延迟影响更大。因此,QUIC一开始就被设计有类似于TLS加密这样的功能,从而避免对SSL/TLS的使用,减少对应的开销。

在此之前,Google工程师已经针对这些具体问题提出了一些解决方案。比如TCP Fast Open(TFO)可用于减少连接到以前已经访问过的相同服务器的RTTs。QUIC揉合了这些旧解决方案,以及一些新的方案,用于重点解决一个应用场景,即从同一台服务器,利用携带多个数据流的TLS加密连接传输数据的Web应用程序服务。

简单来看,QUIC的目标是在UDP协议之上提供一种可建立面向链接的服务。嗯,听上去不错,虽然我对具体细节也是茫然不清,但貌似看懂了它的意思是想针对具体的场景,结合传统TCP和UDP协议两者各自的优点,合二为一。

http://blog.chromium.org/2013/06/experimenting-with-quic.html

http://lwn.net/Articles/558826/

转载请保留地址:http://www.lenky.info/archives/2013/08/2337http://lenky.info/?p=2337


备注:如无特殊说明,文章内容均出自Lenky个人的真实理解而并非存心妄自揣测来故意愚人耳目。由于个人水平有限,虽力求内容正确无误,但仍然难免出错,请勿见怪,如果可以则请留言告之,并欢迎来讨论。另外值得说明的是,Lenky的部分文章以及部分内容参考借鉴了网络上各位网友的热心分享,特别是一些带有完全参考的文章,其后附带的链接内容也许更直接、更丰富,而我只是做了一下归纳&转述,在此也一并表示感谢。关于本站的所有技术文章,欢迎转载,但请遵从CC创作共享协议,而一些私人性质较强的心情随笔,建议不要转载。

法律:根据最新颁布的《信息网络传播权保护条例》,如果您认为本文章的任何内容侵犯了您的权利,请以Email或书面等方式告知,本站将及时删除相关内容或链接。

分类: *nix技术, 内核技术 标签: ,
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.