浅谈QUIC协议原理与性能分析及部署方案

之前写过《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协议在腾讯的技术实践分享https://www.cnblogs.com/jb2011/p/8458549.html

QUIC协议的分析，性能测试以及在QQ会员实践 https://wetest.qq.com/lab/view/384.html

如何部署QUIC

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

https://www.nginx.com/blog/nginx-f5-continued-commitment-open-source/

…………

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——https://www.bennythink.com/quic.html 》

参考网站：

怎样把网站升级到QUIC及QUIC特性分析 https://zhuanlan.zhihu.com/p/37919534

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

请注明出处：https://www.zhoulujun.cn/html/theory/ComputerScienceTechnology/network/2016_0217_5689.html