有句话叫做一流企业定标准、二流企业做品牌、三流企业卖技术、四流企业做产品。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 为跳板展现协议原型和效果，然后再提出作为协议草案，但结果尚待观察。