点击上方“LiveVideoStack”关注我们
作者 | 王盛 策划 | 包研、Alex 编辑 | Alex
QUIC
年终盘点
QUIC协议的发展
QUIC协议的现状
QUIC的一切特性始于“构建在UDP之上”
选择UDP也能让QUIC协议不依赖网络中间设备Middle-Boxes做调整。
TCP协议的开发、调试、观测的困难问题也会迎刃而解,无需通过复杂的BPF(Berkeley Packet Filter)来采集和调试协议栈程序,只需在用户态部署简单的数据收集程序。
应用程序的崩溃问题也不至于影响系统内核,而且可以留足崩溃现场做后续分析。
用户态有更多的程序库帮我们实现更复杂、更全面的策略,比如自适应CC(Congestion Control)算法。
利用UDP的数据包无序列依赖,QUIC多数据流之间多路复用,无队首阻塞问题,并且各自有独立的流控(Flow Control)。
耦合TLS1.3实现0-RTT建连,连接复用。
用户态实现和网络五元组无关的连接标识ID,ConnectionID,实现连接迁移,以及后续的多路径(Multipath QUIC)。
QUIC的使用量稳步提升中
Chrome和Opera都支持gQUIC和iQUIC。
2021年5月,Firefox在Firefox Nightly版本中开始支持QUIC。
2020年4月,Apple在WebKit引擎进行了试验性的QUIC支持,并正式在macOS Big Sur和iOS 14上的Safari 14中支持,但是需要手动打开HTTP/3。
Cronet是最早支持QUIC的客户端库,目前有比较多的客户端引用了Cronet库,其中包括Google Play Services、YouTube、Gmail等。
cURL 7.66版本(2019年9月发布)也支持了QUIC,不过cURL引用的QUIC协议栈是Cloudflare RUST开发的quiche开源库。
2020年10月,Facebook声称其下各APP也都支持了QUIC,包括Instagram,并且有75%的流量使用了QUIC协议。
Uber App也支持了QUIC协议。
2016年和2017年开始就已经有不少公开的QUIC服务端实现了,其中Google开源了其原型服务端源码:https://github.com/google/quiche/blob/main/quic/tools/quic_server_bin.cc。
开源Caddy Server也有一套基于Go语言实现的QUIC协议栈,能够提供QUIC服务。
2017年开始,LiteSpeed在其WebADC(Load balancer)和LiteSpeed Web Server产品上也支持了QUIC协议。
2018年开始,Facebook和Cloudflare也开始在其服务端支持QUIC协议。
2021年开始,微软在其Windows Server 2022和SMB上开始支持了QUIC协议,并开源了其协议栈MsQuic。
随后,Citrix的ADC(Application Delivery Controller)和NetScaler产品也支持了QUIC协议。
应用适配成本和收益之间的权衡。
过渡期可能还需要新旧网络库都存在,方便降级容错,增加应用体积。
不同的QUIC库的接口并不统一,不像Socket统一接口具备移植性。
网络事件模型需要适配QUIC协议栈做调整,同时还要考虑和TCP的兼容。
后端架构面临调整,4层Load Balancer是否支持QUIC,HTTP/3的QUIC流量如何换成HTTP/1转给Backend Service。
需要考虑到多Region、多节点之间的QUIC连接复用和连接迁移。
服务端QUIC流量的能耗比,如何做到和TCP一样的能耗性能。
UDP数据包收发性能
数据装包、拆包处理性能
数据包解析性能
ACK处理性能
加、解密性能
其他流程处理的性能:数据包Pacing、CC算法、内存使用等
原始的sendto/write的UDP Socket接口性能很弱。
批量收发数据sendmsg/sendmmsg提升不够明显。
内核GRO/GSO可以提升性能,但还不够。
内核XDP或者DPDK可大幅提升性能,但程序改造量极大。
硬件NIC Offload UDP收发能终极优化,同样程序改造量极大。
UDP流量五元组在NAT状态上连接老化的时间控制不够精确,时间设置太长会破坏低频通信的UDP连接,太短会导致UDP连接消耗比较多的设备性能。一般会选择一个折中的经验值,这就会伤害一些特定场景的UDP流量了。
运营商设备上包分类的优先级队列对于UDP五元组的管理比较困难,因为UDP的五元组会频繁变动,只能眼睁睁看着UDP流量挤占各级队列,却没办法实施精确地控制。一般来说,运营商会在特定时间段或者特定负载情况下对UDP流量做全局限制。
调试QUIC协议
QUIC协议的未来
虽然QUIC协议是因为HTTP/3而提出来,但我认为,QUIC的未来应该不仅限于HTTP/3。QUIC已具备的一些特性,不仅可以让现有的Web应用运行得更快更安全,还能适配到更多应用场景上,比如IoT、VR、音视频会议等。基于QUIC协议之上,工程师们可以定制开发更多场景的应用,同时也让QUIC协议具备的能力更加完善。
从我个人出发,结合B站的业务场景,我主要关注了QUIC协议在音视频传输领域的未来发展:QUIC Datagram[12]和QUIC Multipath[13]。
QUIC Datagram——QUIC的非可靠数据报文传输扩展
QUIC v1(RFC9000)提供了一个安全、可靠、多路复用的传输方案,QUIC Stream数据流是QUIC主要数据传输的载体,可靠传输是其需要保证的基本功能。
但是有些应用场景并不需要严格的可靠传输,例如实时音视频、在线游戏等。现在这些场景有些是直接基于自定义UDP或者WebRTC实现的。自定义UDP实现传输层功能的话比较麻烦,工程量大,有时候为了安全考虑还需要加上DTLS支持,而WebRTC的建立数据传输通道流程也比较繁琐,WebRTC主要场景是为了P2P设计的,长远来看并不适合客户端服务端的场景。
因此,QUIC支持不可靠数据传输能够让QUIC协议的应用范围更广,适合更多的应用场景,而且QUIC之上的不可靠数据传输能够很好地复用QUIC的安全特性。
QUIC Datagram特点
同一QUIC连接里面可以同时包含可靠Stream传输和不可靠数据传输,它们可以共享一次握手信息,分别可以作用于TLS和DTLS,可降低握手延迟。
QUIC在握手上比DTLS更加精准,它对每个握手数据包加上了超时重传定时器,能够快速感知握手包的丢失和恢复。
QUIC Datagram的不可靠传输也可以被ACK,这是一个选项,如果有ACK,可以让应用程序感知到QUIC Datagram的成功接收。
QUIC Datagram也适用于QUIC的CC。
这些特性能够让实时音视频流、在线游戏和实时网络服务等应用的传输得到极大的效率提升。
WebTransport呼之欲出
WebTransport是一个框架型的协议[14],该协议使客户端与远程服务器端在安全模型下通信,并且采用安全多路复用传输技术。注意:WebTransport是一个框架,在它下面是实际的协议,框架提供了一个一致的接口,因此它由一组可以安全地暴露给不受信任的应用程序的协议以及一个允许它们互换使用的模型组成。它还提供了一组灵活的功能,为我们提供了可靠的单向和双向流以及非可靠的数据报文传输。
QUIC Multipath
QUIC Multipath多路径传输,简言之就是用多个物理网络路径来传输数据,可以同时使用WIFI、LTE/4G或者IPV4/IPV6。随着音视频的消费码率越来越高,对网络连接的吞吐能力要求越来越高,单路径的网络情况开始捉襟见肘,MP-QUIC可以发挥比较大的作用。比如在超高清、超高码率视频8K、VR等场景。
MP-QUIC基本思路是: 用多个网络路径来组成一个QUIC连接进行数据传输,MP-QUIC其实也是对连接迁移特性的一次拓展,协议标准也在草案阶段[13]。用多个网络路径实现一个QUIC连接看似简单,其实实现上有很多事情需要考虑:
异构网络
数据包冗余分配和流量成本之间的ROI
多路径调度策略
协议标准目前只规定了多路径实现的机制,也就是多个单向的UniFlow组成QUIC连接,多路径调度和冗余包策略都需要额外单独实现。不过随着业务场景需求的展开和协议标准的正式推出,我相信MP-QUIC在音视频传输上的应用会越来越多。
参考文献
[1] QUIC Wiki: https://en.wikipedia.org/wiki/QUIC
[2] RFC9000: https://datatracker.ietf.org/doc/html/rfc9000
[3] RFC8999: https://datatracker.ietf.org/doc/html/rfc8999
[4] RFC9001: https://datatracker.ietf.org/doc/html/rfc9001
[5] RFC9002: https://datatracker.ietf.org/doc/html/rfc9002
[6] W3Techs HTTP/3 Usage Statistics: https://w3techs.com/technologies/details/ce-http3
讲师招募
LiveVideoStackCon 2022 音视频技术大会 上海站,正在面向社会公开招募讲师,无论你所处的公司大小,title高低,老鸟还是菜鸟,只要你的内容对技术人有帮助,其他都是次要的。欢迎通过 [email protected] 提交个人资料及议题描述,我们将会在24小时内给予反馈。
喜欢我们的内容就点个“在看”吧!
本文分享自微信公众号 - LiveVideoStack(livevideostack)。
如有侵权,请联系 [email protected] 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。