首页 > theory > network > > 正文

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

发布人:zhoulujun@live.cn    点击:

http从0 9 1 0 1 1 2 0 3 0不断演化,而http2算是综合性革新性产品,特别是quic协议更是把传输层TCP替换成UDP,安全加固。算得上佛陀舍利变成的孙悟空。

之前写过《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基础上由客户端自由发挥,只要有服务器能对接就可以

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解_WX20180104-122733@2x.png 

这些不止让传输速度更快,多路复用等优势,还可应付移动网络里面频发的切换。这些都是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 重传的歧义问题。

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解_3.jpeg 


在普通的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 按照顺序组织起来,交给应用程序处理。

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解_4.jpeg 

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解_9.jpeg 

FEC前向纠正拥塞控制

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

切换网络操持连接

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

不为人知的网络编程(六):深入地理解UDP协议并用好它_11.jpg 


更安全的传输协议

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

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

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

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

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

技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解_15.jpeg 

强烈推荐:

让互联网更快:新一代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