QUIC ，即 快速UDP网络连接 ( Quick UDP Internet Connections )，是由 Google 提出的实验性网络传输协议，位于 OSI 模型传输层。 QUIC 旨在解决 TCP 协议的缺陷，并最终替代 TCP 协议，以减少数据传输，降低连接建立延迟时间，加快网页传输速度。

QUIC 主要特点有：

多流设计；
低等待延迟；
加密性能更优；
前向纠错；
应用程序实现；
连接保持；

多流设计

采用 多路复用 思想，一个连接可以同时承载多个流 ( stream )，同时发起多个请求。请求间完全独立，某个请求阻塞甚至报文出错均不影响其他请求。

对比 HTTP 长连接，由于 TCP 是只实现一个字节流，如果请求阻塞，新请求无法发起。

低等待延迟

先考察典型的 TLS 连接建立过程：

首先，执行三次握手，建立 TCP 连接(蓝色部分)；
然后，执行 TLS 握手，建立 TLS 连接(黄色部分)；
此后开始传输业务数据；

客户端和服务器之间要进行好几轮协议交互，才能建立 TLS 连接，延迟相当严重。平时访问 https 网站明显比 http 网站慢，三次握手和 TLS 握手难辞其咎。

注解:

注意到，三次握手中的 ACK 包与 ClientHello 合并在一起发送。这是 TCP 实现中使用的 延迟确认 技术，旨在减少协议开销，改善网络性能。

那么，能不能将 TCP 三次握手和 TLS 合并起来呢？如果客户端在发送 SYN 包的同时将 ClientHello 一起发给服务端；服务端响应 SYN/ACK 包时也带上相关 TLS 握手包，那么将可以节省一起往返时间！

这便是 QUIC 降低延迟的思路，但在 SYN 集成其他协议协议控制已然不可能。因此， QUIC 采用基于 UDP 协议之上，在应用程序内实现传输控制协议的方案。

加密性能更优

新的安全机制比 TLS 性能更好，而且具有各种攻击防御策略。

前向纠错

TCP 采用重传机制，而 QUIC 采用纠错机制。

TCP 发生丢包时，需要一个等待延时判断发生了丢包，然后再启动重传机制，这个过程会造成一定的阻塞，影响传输时间。

而 QUIC 则采用一种更主动的方案，有点类似 RAID5 ，每 n 个包额外发一个 校验和包 。如果这 n 个包中丢了一个包，可以通过其他包和校验和恢复出来，完全不需要重传。

应用程序内实现

QUIC 直接基于客户端(应用进程)实现，而非基于内核，可以快速迭代更新，不需要操作系统层面的改造，部署灵活。这也是不使用基于迭代升级 TCP 方案的原因 —— TCP 在操作系统内核中实现，很难进行大规模调整以及推广。

连接保持

QUIC 在客户端保存连接标识，当客户端 IP 或者端口发生变化时，可以快速恢复连接 —— 客户端以标识请求服务端，服务端验证标识后感知客户端新地址端口并重新关联，继续通讯。这对于改善移动端应用连接体验意义重大(从 WiFi 切换到流量)。

附录

更多 网络编程 技术文章请访问：Linux网络编程，转至原文可获得最佳阅读体验。

订阅更新，获取更多学习资料，请关注我们的微信公众号：

小菜学编程