基于UDP的新一代多路传输协议—QUIC（一）

TCP、UDP都是计算机网络通信层的主要协议。TCP是面向连接的，也即通信双方在进行数据交换之前，需要经过“三次握手”建立一条“连接”，然后才能进行通信，类似生活中的“打电话”需要有“线路”保证；UDP是面向无连接的，也即在通信双方进行数据交换之前，无需建立连接,只要知道对方地址即可发送数据,类似生活中的“寄信”。

由于UDP协议是无连接方式的协议，所以它的效率高，速度快，占资源少，在各种关键及任务密集环境下得到广泛应用，但是其传输机制为不可靠传送，必须依靠辅助的算法来完成传输控制。相比之下，TCP则更强调的是传输的可靠性，但建立“专有”连接的开支较大。

其中传输层协议包括TCP和UDP协议。与TCP协议相比，UDP更为轻量，但是错误校验也要少得多。这意味着UDP往往效率更高（不经常跟服务器端通信查看数据包是否送达或者按序），但是可靠性比不上TCP。通常游戏、流媒体以及VoIP等应用均采用UDP，而网页、邮件、远程登录等大部分的应用均采用TCP。

为了集合两者的优点，各个通信巨头都在探寻提升与改进UDP通信协议，如RUDP（可靠UDP通信），如思科公司的RUDP，微软公司的R-UDP等，中国网民日常使用的即时通信工具QQ所使用的主要通信协议就是UDP的改进版。最近Google用改进版的UDP协议QUIC给web提速。Google在4月份透露大约有50%的来自Chrome浏览器对Google服务器的请求，现在由QUIC协议负责处理。75%的连接均可利用QUIC的优势，哪怕预先建立的优化连接（Google搜索）采用QUIC后页面加载性能仍然能提高3个百分点。而时延严重的一些web应用，在采用QUIC后的改进效果则要更加明显。比如有用户报告YouTube重新缓冲次数减少了30%。

什么是QUIC

QUIC是Quick UDP Internet Connection的简称，是Google制定的一种基于UDP的低时延的互联网传输层协议。在SPDY成功作为HTTP/2标准的基础后，Google从2013年初就开始悄然致力于QUIC协议，Google想到能否把这TCP和UDP协议的优势结合起来，同时实现低时延和高可靠并将其应用到更高安全的协议上，于是就有了QUIC。

    从目标来看，QUIC跟SPDY(HTTP/2基础)很多方面是类似的，但是后者仍然基于TCP，所以仍然会存在部分相同的时延问题。

为什么不用TCP

TCP往往直接内置到了操作系统内核当中，除非所有机器的操作系统都更新到最新，否则考虑到兼容性不太可能大范围采用新技术。这是Google所无法控制的。

QUIC直接基于客户端实现，而非基于系统内核，可以进行快速迭代更新，不需要操作系统内核层面的更改。所以基于UDP是一个更有效的选择。

为什么要寻求类似QUIC的新型通信协议

 

 据HTTPArchive的统计，1990的一个网络页面是由一个资源文件、一个域名组成的静态页，而2014年的一个网络页面，平均尺寸增长到1,200KB，引用多达80个资源文件，这些资源来自30个不同的主机/域名。尽管网络带宽增加了，但面对日益增长的大尺寸页面，寻求类似QUIC的新型通信协议，仍具有重要意义。

QUIC的基本特点

QUIC的主要目标是实现零往返的连接开销。Google的开发人员Robbie Shade在最近的一个视频中对QUIC做了介绍，QUIC为传输层协议，与TCP、UDP、SCTP同级，主要有以下特性：

·          基于UDP的多路传输（单连接下）；

·          极低的等待时延（相比于TCP的三次握手）；

·          快速迭代更新；

·          开源于Chromium项目中。

QUIC的发展路线

·          QUIC成为一个独立的传输层方案，成为更多应用层的高性能选择；

·          QUIC的理念被TCP和TLS所采纳，使得TCP的性能得到充分发展，融合统一；

综上所述，Google并不是想取代TCP，但是确实想改TCP又改不了（内核实现的劣势），所以独立实现了QUIC协议作为替补方案。

由于大小受限，未完。。。。

QUIC的核心技术

QUIC优点

QUIC不足

请参考

基于UDP的新一代多路传输协议—QUIC（二）

声明：本文仅是对于QUIC的整理和学习，部分资料均来至各个大神的博客和微信。仅供大家学习，连接如下：

http://www.infoq.com/cn/news/2014/02/quic#theCommentsSection

http://www.leiphone.com/news/201504/nMrwN5Wnp4Z5r5n3.html

http://www.zhihu.com/topic/20016701/newest

http://www.williamlong.info/archives/3879.html