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的使用，降低相应的开销。
在此之前。Googleproject师已经针对这些详细问题提出了一些解决方式。比方TCP Fast Open（TFO）可用于降低连接到曾经已经訪问过的同样server的RTTs。QUIC揉合了这些旧解决方式，以及一些新的方案，用于重点解决一个应用场景，即从同一台server。利用携带多个数据流的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