之前写过《http1.0 与 http1.1的区别》 与 《再谈HTTP2性能提升之背后原理—HTTP2历史解剖》，QUIC协议，现在nginx官方也即将支持。所以还是得跟上时代脚步。

QUIC简史

QUIC(Quick UDP Internet Connection)是谷歌推出的一套基于UDP的传输协议，它实现了TCP + HTTPS + HTTP/2的功能，目的是保证可靠性的同时降低网络延迟。因为UDP是一个简单传输协议，基于UDP可以摆脱TCP传输确认、重传慢启动等因素，建立安全连接只需要一的个往返时间，它还实现了HTTP/2多路复用、头部压缩等功能。

为什么要使用QUIC

众所周知UDP比TCP传输速度快，TCP是可靠协议，但是代价就是 双方确认数据而衍生的一系列消耗，可以参看《再深谈TCP/IP三步握手&四步挥手原理及衍生问题—长文解剖IP》。其次TCP是系统内核实现的，如果升级TCP协议，就得让用户升级系统，这个的门槛比较高，而QUIC在UPD基础上由客户端自由发挥，只要有服务器能对接就可以。

这些不止让传输速度更快，多路复用等优势，还可应付移动网络里面频发的切换。这些都是quic的优势。

QUIC优势连接建立延时低

QUIC只需要一次往返就能建立HTTPS连接

改进的拥塞控制

TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。

QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法

QUIC的NACK比TCP的延迟确认机制高效

TCP 为了保证可靠性，使用了基于字节序号的 Sequence Number 及 Ack 来确认消息的有序到达。

QUIC 同样是一个可靠的协议，它使用 Packet Number 代替了 TCP 的 sequence number，并且每个 Packet Number 都严格递增，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。而 TCP 呢，重传 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不变，也正是由于这个特性，引入了 Tcp 重传的歧义问题。

在普通的TCP里面，如果发送方收到三个重复的ACK就会触发快速重传，如果太久没收到ACK就会触发超时重传，而使用NACK可以直接告知发送方哪些包丢了，不用等到超时重传。TCP有一个SACK的选项，也具备NACK的功能，QUIC的NACK有一个区别它每次重传的报文序号都是新的。

但是单纯依靠严格递增的 Packet Number 肯定是无法保证数据的顺序性和可靠性。QUIC 又引入了一个 Stream Offset 的概念。

即一个 Stream 可以经过多个 Packet 传输，Packet Number 严格递增，没有依赖。但是 Packet 里的 Payload 如果是 Stream 的话，就需要依靠 Stream 的 Offset 来保证应用数据的顺序。如错误! 未找到引用源。所示，发送端先后发送了 Pakcet N 和 Pakcet N+1，Stream 的 Offset 分别是 x 和 x+y。

假设 Packet N 丢失了，发起重传，重传的 Packet Number 是 N+2，但是它的 Stream 的 Offset 依然是 x，这样就算 Packet N + 2 是后到的，依然可以将 Stream x 和 Stream x+y 按照顺序组织起来，交给应用程序处理。

FEC前向纠正拥塞控制

FEC是Forward Error Correction前向错误纠正的意思，就是通过多发一些冗余的包，当有些包丢失时，可以通过冗余的包恢复出来，而不用重传。这个算法在多媒体网关拥塞控制有重要的地位。QUIC的FEC是使用的XOR的方式，即发N + 1个包，多发一个冗余的包，在正常数据的N个包里面任意一个包丢了，可以通过这个冗余的包恢复出来，使用异或可以做到

切换网络操持连接

经常会有从4G切换到wifi网络或者是从wifi切换到4G网络的场景，由于网络的IP变了，导致需要重新建立连接，而QUIC使用一个ID来标志连接，即使切换网络也可以使用之前的建立连接的数据如交换的密钥，而不用再重新HTTPS握手，不过切换的过程可能会导致有些包丢了，需要利用FEC恢复或者重传。

更安全的传输协议

TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。

但是 QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。

这样只要对 QUIC 报文任何修改，接收端都能够及时发现，有效地降低了安全风险。

如下图所示，红色部分是 Stream Frame 的报文头部，有认证。绿色部分是报文内容，全部经过加密。

这一切，归功于 UDP的不可靠 变为可靠。

强烈推荐：

让互联网更快：新一代QUIC协议在腾讯的技术实践分享

QUIC协议的分析，性能测试以及在QQ会员实践

如何部署QUIC

如今业界nginx打头阵(反向代理、负债均衡、转发)的头号代表(占统治地位)，且看官方：

…………

And we’re not stopping there. Our plan for 2019 is to accelerate open source development with even more capabilities. Notable roadmap items include:

NGINX – QUIC and HTTP/3 implementations, as well as support for asynchronous file open

NGINX Unit – Java servlet containers, proxying capabilities, static file support

njs – Support for JavaScript modules (import/export) and deeper NGINX integrations

…………

现在上的话，就Canddy(监听UDP 443端口) 和nginx配合打法。

具体步骤，推荐 ：《前卫一下：给你的网站开启 QUIC—— 》

参考网站：

怎样把网站升级到QUIC及QUIC特性分析

转载本站文章《浅谈QUIC协议原理与性能分析及部署方案》,请注明出处：