下一代通讯协议：QUIC

在 HTTP 协议已经占据互联网大半江山的今天，尽管网速愈来愈快，可是人类仍是致力于将网络传输速率提高到极致。

从 HTTP/1.x 到 HTTP/2，TCP 已经不能知足人类贪婪的欲望了，他们开始向常年被忽视的 UDP 进军。

QUIC 是什么？

QUIC（Quick UDP Internet Connections），直译过来就是“快速的 UDP 互联网链接”，是 Google 基于 UDP 提出的一种改进的通讯协议，做为传统 HTTP over TCP 的替代品，开源于 Chromium 项目中。

为了加快 TCP 的传输效率，Google 提出了 BBR 拥塞控制算法，将 TCP 的性能发挥到了极致。因为 TCP 和 UDP 协议是系统内核实现的，要提出新的协议不是不行，只是普及起来会很是困难，就连 BBR 算法，都须要更新系统内核才能支持。那么，TCP 的性能已经到了极致，还能更快吗？

UDP 相比于 TCP，没有那么多的要求，只要将数据发出去就好了，不须要考虑数据是否送达了、不须要考虑数据的到达顺序、不须要考虑数据的正确性和完整性，因此效率比 TCP 要高出几个档次。

UDP 协议曾经被广泛用于视频直播、网络游戏之类实时性要求较高的应用，即便少数几个包没有送达对应用总体的影响也不大。但是，对于 HTTP 之类的协议，是须要保证数据的正确性、完整性的，因此 UDP 自己并不适合做为 TCP 的替代品。

UDP 不适合替代 TCP 是由于它自己不对数据进行校验，那么若是将数据校验放到其余地方去实现，是否是就可使用 UDP 了呢？

因而，QUIC 就诞生了，它聚集了 TCP 和 UDP 的优势，使用 UDP 来传输数据以加快网络速度，下降延迟，由 QUIC 来保证数据的顺序、完整性和正确性，即便发生了丢包，也由 QUIC 来负责数据的 纠错。

如今，Google 旗下的部分服务（好比 GMail）以及许多接口已经开始使用 QUIC 协议了。若是你使用的是 Chrome 浏览器，能够在浏览器的这个地址：chrome://net-internals/#quic 看到 QUIC 的链接状况。

QUIC 的优势

因为 TCP、UDP 协议是系统内核实现的，更新修改起来并不很方便，而 QUIC 是软件层面实现的，更新迭代起来很是方便。

UDP 自己是无序传输的，这在单个链接上并行传输多个数据有天生的优点：多个数据直接发送便可，由 QUIC 对收到的数据进行从新组合排序，而后送往上层应用。这中间不用等待各类数据确认包，效率很是高。

在创建 TCP 链接时，须要进行至少三次握手，若是要开启 TLS 加密，则还须要进行 TLS 握手。而 QUIC 采用了相似于 TCP Fast Open 的技术，若是以前链接过，那么以后能够不用重复握手而直接开始传送数据，以实现 0-RTT 往返时延。即使以前没有链接过，也能够在 1-RTT 内完成链接并开始传送数据。而且自身就拥有与 TLS 等效的加密措施。

在发生丢包时，TCP 会重传丢失的包。而 QUIC，则使用了一种很是神奇的前向纠错算法，经过连续的几个数据包的校验和，能够直接恢复出丢失的包内容，而不须要重传。

在移动端表现更好：用户的网络环境并不稳定，Wi-Fi、4G、3G、2G 之间来回变化，IP 一旦发生变化，TCP 的链接是不可能保持的。而 QUIC 就不存在这样的问题，经过 ID 来标识用户（而不是 IP + 端口），在链接切换后直接恢复以前的链接会话。

配合 HTTP/2 API 食用更佳：因为 HTTP/2 采用二进制帧传输机制，QUIC 直接使用这样的机制进行数据传输，效率更高！

QUIC 的缺点

如今不少网络运营商会下降 UDP 包的优先级，使得 UDP 丢包率特别高。（QUIC 不可用时，浏览器通常会 Fallback 到 TCP）

目前只有 Chrome、Opera 浏览器支持。

何时更适合使用 QUIC？

• 移动端 因为 QUIC 并不使用 IP + 端口来标识客户身份，而是使用 ID，这使得在网络环境切换后还能够保持链接，很是适合用在移动网站上面，在手机信号不稳定的状况下，TCP + TLS 的开销是很是大的！QUIC 的 0-RTT 能够极大限度地提高访问速度。

总结

QUIC 实现的目标，就是利用 UDP 实现一个 TCP，支持 TCP 的全部特性，而且比 TCP 更快更好用。

QUIC 是从 2012 年开始的项目，到目前也还只是草案阶段，而且一样处于草案阶段的 TLS1.3 也一样拥有了 QUIC 中的不少优势（好比 0-RTT）。对于访问速度的优化方式愈来愈多，适当的选择能够为网站增色许多。

---

关注微信公众号：创宇前端（KnownsecFED），码上获取更多优质干货！