在 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），码上获取更多优质干货！