有句话叫做一流企业定标准、二流企业做品牌、三流企业卖技术、四流企业做产品。Google似乎在冲着一流企业的目标迈进。去年，Google已经从以SPDY为基础的HTTP协议16年来的首个更新HTTP/2正式定稿中尝到了甜头。最近Google又开始考虑更进一步，用改进版的UDP协议QUIC给web提速。根据它近日公布的性能评估，这一融合了UDP与TCP优势的协议似乎提升效果明显。

QUIC是Quick UDP Internet Connection的简称，是Google制定的一种基于UDP的低时延的互联网传输层协议。我们知道，TCP/IP协议族是互联网的基础。其中传输层协议包括TCP和UDP协议。与TCP协议相比，UDP更为轻量，但是错误校验也要少得多。这意味着UDP往往效率更高（不经常跟服务器端通信查看数据包是否送达或者按序），但是可靠性比不上TCP。通常游戏、流媒体以及VoIP等应用均采用UDP，而网页、邮件、远程登录等大部分的应用均采用TCP。

Google想到能否把这两种协议的优势结合起来，同时实现低时延和高可靠并将其应用到更高安全的协议上，于是就有了QUIC。

以往典型的安全TCP连接（TCP+TLS）往往需要在发送与接收端先进行2、3轮的握手通信才能正式开始数据传输。而利用QUIC协议，如果双方此前通信过的话马上就可以对话（即便双方此前未通信过时延也只有100毫秒，是TCP+TLS用时的1/3）。此外，QUIC还增加了拥塞控制和自动重传等功能，所以可靠性上要比UDP更高。

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

不过这样也许你会问为什么Google不干脆改进TCP？根据Google的解释，不这么做的原因是TCP往往直接内置到了操作系统内核当中，这是Google所无法控制的。所以他们就拿UDP改良版来开刀，以期更快地测试性能改进效果。

Google从去年开始就已经在Chrome浏览器上进行了实验，实际上目前Chrome到Google服务器的请求当中大概有一半已经在采用QUIC协议。数据表明75%的连接均可利用QUIC的优势，哪怕预先建立的优化连接（Google搜索）采用QUIC后页面加载性能仍然能提高3个百分点。而时延严重的一些web应用，在采用QUIC后的改进效果则要更加明显。比如有用户报告YouTube重新缓冲次数减少了30%。

Google希望QUIC的性能得当证明后能够移植到TCP和TLS上面，称未来打算将HTTP2-over-QUIC作为新的协议提交给IETF。但是这显然需要与IETF的配合以及长期努力。这一套路跟SPDY很像，都是以Chrome为跳板展现协议原型和效果，然后再提出作为协议草案，但结果尚待观察。

转自 http://36kr.com/p/532016.html