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://lenky.info/archives/2013/08/06/2337 或 http://lenky.info/?p=2337