导读:网易云信作为音视频服务提供商的领导者,一直致力于提供顶级的音视频通话服务体验,为用户在各种恶劣环境下提供可靠的音视频服务。如何在极端弱网条件下仍然能给用户提供可靠的音视频服务,是网易云信关注的重中之重。本文将阐述网易云信对于 QUIC 协议的应用优化实践。

引言

QUIC 协议从传输层面相较 TCP 的几点优势

  • 0-RTT 建连

QUIC 协议基于 UDP,本身无需握手,并且其使用 Diffie-Hellman 或者 ECC 算法,只在 1-RTT 就完成对等秘钥的协商。QUIC 协议的 0-RTT 建连使用 TLS1.3,通过 early_data 完成加密数据透传。

  • 多路复用/无对头阻塞

相比于 HTTP/2 的多路复用,QUIC 不会受到队头阻塞的影响,各个流更独立,多路复用的效果也更好。

  • 连接迁移

与 TCP 用四元组标识一个唯一连接不同,QUIC 使用一个 64 位的 ConnectionID 来标识连接,基于这个特点,QUIC 的使用连接迁移机制,在四元组发生变化时(比如客户端从 WIFI 切换到蜂窝移动网络),尝试“保留”先前的连接,从而维持数据传输不中断。

  • 可定制的拥塞控制

QUIC 协议没有定义拥塞控制算法的使用,这部分实现在应用层,方便开发者自行优化迭代。

QUIC 协议从协议层面相较 TCP 的几点差别

  • Separate Packet Number Spaces

    QUIC 协议定义了 4 种不同的加密级别,各种加密级别使用不同包序列号空间。

  • Monotonically Increasing Packet Numbers

    相同包序列号空间中的包序列号单调递增,避免了重传歧义。QUIC 协议的包序列号空间只标识传输顺序,数据包内容的顺序则用 STREAM 帧当中的偏移(offset)来标识。

  • Clearer Loss Epoch

    当一个 QUIC 包被申明为丢失,QUIC 开启一段丢失检测的周期,在此之后发送的任何一个 QUIC 包被确认则刷新检测周期的时间。与 TCP 不同,TCP 会一直等待序列号空间中的空白被填满尽管有可能在传输过程中相同数据包发生了多次丢失。这样做的意义在于:QUIC 可以更精确地在每个往返时间(RTT)内去更新拥塞窗口的大小。

  • No Reneging

    不能食言。一旦一个包被对端确认,则改包不能再被申明为丢失。这样的设定大大简化了双端传输协议的设计,也减小了发送端的内存压力。

  • More ACK Ranges

    相比 TCP 的 SACK 只能确认三个段(范围),QUIC 协议的 ACK 帧支持更多的段(范围)确认。在高丢包场景下,加快了重传恢复的速度,避免零散的范围确认导致的传输中断。

  • Explicit Correction For Delayed Acknowledgements

    QUIC 协议将计算从接收包到发送该包 ACK 之间的延迟时间,并显式写入 ACK 帧中。这样的设定旨在更加精准地计算网路的往返时间。

  • Probe Timeout Replaces RTO and TLP

    QUIC 协议使用 PTO(probe timeout)探测超时机制,包含了对端的期望最大确认延时,而不是一个固定的最小超时。与 TCP 的 RTO 超时不同的是,QUIC 协议在 PTO 过期时不会去尝试折叠拥塞窗口,因为尾部数据的丢失并不能表示网路发生了持续的拥塞。发送方可以不受限制地发送更多的数据包在其还有剩余的拥塞窗口的条件下,即便此时已经发生了 PTO 超时。相对于 TCP 的 RTO 机制,PTO 机制更加激进。

  • The Minimum Congestion Window is Two Packets

    TCP 使用一个数据包作为最小拥塞窗口,如果这个数据包丢失了,意味着需要等待 RTO 来进行重传,这很可能远远大于一个往返时间(RTT),QUIC 协议建议使用两个数据包作为最小拥塞窗口,虽然这样做会增加流量,但是被认为是安全的。

QUIC 协议在网易云信的应用

在网易云信音视频服务的架构中,信令用于 SDP 的交互会话房间的创建与管理用户信息的上传与下发等,其传输的稳定性和及时性至关重要。传统的 WEBRTC 建议使用 WebSocket 作为信令传输协议,受限于 TCP 协议的缺陷,其在建连时间、传输效率和弱网抗性方面的效果不尽人意。而这些问题直接影响到音视频服务的基线指标,比如首帧时间、链路的稳定性以及弱网抗性等。

云信 QUIC 加速服务设计:

网易云信使用 QUIC 协议替代 WebSocket 协议进行信令的传输,并在应用和协议层面做了若干优化实践:

  • 多路复用:根据不同信令的特性,给请求分类分级。对于 Request/Reponse 类型的消息,其可靠性和实时性的要求最高,使用高优先级的 STREAM 进行传输。对于用于链路保活的心跳消息,则使用较低优先级的 STREAM 进行传输。

  • 不可靠的传输拓展:有一类 Notify 消息类型,不需要接收端进行回复,往往用于广播各端用户的网络状态或者其他信息。其对于实时性的要求很高,但是对可靠性没有很高的要求。对于这种信令,我们可以使用 QUIC 协议的不可靠传输特性进行传输。

    这种特殊的传输使用一种 DATAGRAM 帧,传输这种特殊的帧,需要在 Initial 包中的 CH 模块的 QUIC 传输参数表中进行申明(name=max_datagram_frame_size, value=0x20),用以通告对端对于 DATAGRAM 帧的支持。max_datagram_frame_size 传输参数是一个整数值(表示为可变长度整数),表示端点愿意接收的 DATAGRAM 帧的最大大小(包括帧类型、长度和有效负载),以字节为单位。

    DATAGRAM 帧用于以不可靠的方式传输应用程序数据。帧中的 Type 字段采用 0b0011000X 的形式(或值 0x30 和 0x31),最低有效位是 LEN 位(0x01),表示是否存在 Length 字段:如果该位设置为 0,则 Length 字段不存在,Datagram Data 字段扩展到数据包的结尾;如果该位设置为 1,则存在长度字段。DATAGRAM 帧的结构如下:

尽管 DATAGRAM 帧在检测到丢失时不会进行重传,但也是需要被 ack 的。

  • 报文压缩:云信在传输层引入了 Deflate 算法对 STREAM 帧进行压缩,旨在降低信令传输的带宽占用。

  • 动态的冗余策略:因为信令非流式数据,FEC 并不能适用于断续数据的传输,以 RTT 和丢包率等指标动态地增加冗余保护对提升传输的弱网抗性也有相当积极的作用。

云信 QUIC 的弱网表现

首屏耗时和登录耗时 

上图是云信音视频业务信令建连使用 TCP 和 QUIC 的对比。在首帧耗时的指标上,QUIC 有 20% 的提升。在登录耗时的指标上,QUIC 有接近 30% 的提升。主要的原因是 QUIC 的建连对比 TCP+TLS 有 2~3 个 RTT 的优化,在高 RTT 的场景下握手时间缩短尤为明显。在直播场景下,云信 QUIC 做了私有化的 0RTT 握手的优化,建连更加快速。

抗丢包性 

上图是云信信令数据在 QUIC 和 TCP 链路下能够抗住的最大丢包率。QUIC 在上行丢包率达到 70% 的条件下仍然可以提供服务,下行边界甚至可以抗住 75% 的丢包。TCP 链路在 45% 的丢包情况下就会出现断开重连。相对于 TCP 的信令链路 QUIC 链路有 50% 的提升。

主要原因:

  • 云信实现了动态冗余,会检测到丢包之后增加冗余度,这样就用冗余包弥补了高丢包,带来了抗丢包性能。

  • QUIC 改进的流量控制和拥塞控制算法让 QUIC 在弱网络下可能取得更大的传输优势。

带限 

我们还做了在带宽受限的情况下,QUIC 对于带宽的使用率,基本上 QUIC 对于带宽的使用率都能达到 90% 以上,然而 TCP 就要差很多。

展望&总结

网易云信在可靠数据加速上可靠数据传输上已经得到很大的提升,但是仍然还有一些需要优化的地方:一旦单向发生丢包,会引起服务器和端都增加双向的冗余度,带来不必要的冗余增加。后续会检测到单向丢包,只针对丢包的链路进行冗余度增加。对于高 RTT 和高丢包场景,QUIC 拥塞控制算法需要持续优化。网易云信将持续在音视频领域,在各种极端情况下为用户提供优质的服务。

网易云信 QUIC 应用优化实践相关推荐

  1. 技术实践 | 网易云信 QUIC 加速服务架构与实践

    导读:网易云信作为音视频服务提供商的领导者,一直致力于提供顶级的音视频通话服务体验,为用户在各种恶劣环境下提供可靠的音视频服务. 文|纪松 网易云信资深音视频服务端开发工程师 如何在极端弱网条件下仍然 ...

  2. 亮相LiveVideoStackCon 2021,网易云信分享QoS优化之道

    2021年4月16日,多媒体技术领域盛会LiveVideoStackCon音视频技术大会在上海举行.本届会议以"新技术,新机会"为主题,聚焦在音频.视频.图像等技术的最新探索与应用 ...

  3. Kubernetes 在网易云中的落地优化实践

    本文来自网易云社区 今天我跟大家讲的是 Kubernetes 在网易的一些实践,目的是抛砖引玉,看看大家在这个方向有没有更好的实践方法.简单介绍一下网易云.网易云是从最早 Kubernetes 1.0 ...

  4. 连麦互动直播方案全实践3:网易云信连麦互动的实现方案

    毫无疑问直播是当前移动互联网最热门的领域之一,在超强热度的引导下直播领域也吸引了大量的商业资本.在各大直播应用万花齐放的时刻,也正是直播应用面临的真正风口.站在这个风口上,直播应用只把握好风向标,推出 ...

  5. 技术实践 | 网易云信在融合通信场景下的探索和实践之 RTMPGateway 服务架构

    导读:随着各个行业的互联网化进程不断演进,融合通信在越来越多的场景中得到应用,例如金融场景的视频面签.医疗场景的远程会诊.企业协作场景的多人视频会议等. 文|本森 网易云信资深音视频服务端开发工程师 ...

  6. 网易云信联合浙江大学信电学院成立创新与实践基地,探索音视频前沿技术

    在新冠疫情对各行各业的持续冲击下,以音视频为代表的非接触式产业成为数字经济的有力支撑,并呈现出极大的发展潜力.为夯实音视频技术研发能力,让创新驱动发展,11月28日,在网易创新企业大会上,来自网易核心 ...

  7. 连麦互动直播方案全实践2:网易云信连麦互动直播方案的演变过程

    毫无疑问直播是当前移动互联网最热门的领域之一,在超强热度的引导下直播领域也吸引了大量的商业资本.在各大直播应用万花齐放的时刻,也正是直播应用面临的真正风口.站在这个风口上,直播应用只把握好风向标,推出 ...

  8. mysql group 更新递增_MySQL Group Replication在网易使用和优化实践

    本文由作者授权网易云发布,未经许可,请勿转载 作者:温正湖,网易数据库技术专家 MGR(MySQL Group Replication)是MySQL官方推出的领先的服务高可用和数据高可靠方案,网易从2 ...

  9. 网易云信合作伙伴招募计划全面开启!

    在"互联网+"背景下,网易云信致力于帮助合作伙伴,一起构建基于网易云信的成功业务实践和解决方案.网易云信可为合作伙伴提供产品的培训认证.销售咨询.技术对接和解决方案服务. 具体而言 ...

最新文章

  1. 如何挖掘系统的业务价值
  2. 2020年最具“钱途”的编程语言
  3. pandas dataframe column_数据处理的瑞士军刀pandas | 火星技术帖
  4. C#学习-程序集和反射
  5. red hat 5.5 vncserver搭建
  6. i7台式电脑配置推荐_2020年台式电脑配置推荐
  7. 下午去公司无聊了一下午
  8. 【毕设】ASP.NET基于.NET的城市公交查询系统的设计与实现(源代码+论文)
  9. 为什么要使用自增ID作为主键
  10. 软件获取手机的ime权限_【干货】解锁VIP会员权限,两款手机必备剪辑软件,免登陆,1080P输出无压力!...
  11. 不用写代码也能学会采集海量企业电话及邮箱数据
  12. LabelImg 图片标注工具 for Mac
  13. 如何写出高性能SQL语句?-性能设计沉思录(6)
  14. 极力推荐收藏的几个高清免费图片素材网站
  15. 安卓模拟器安装教程_无限多开仙境传说RO!第一安卓模拟器BlueStacks蓝叠安卓模拟器多开教程...
  16. Golang入门之——文件锁操作flock
  17. Telegram被封禁的原因
  18. 安装redis时 提示执行make命令时提示 CC adlist.o /bin/sh: cc: 未找到命令
  19. 木材材积表快速计算器_木材材积表计算器
  20. 华为写代码的这13年,成为了我最宝贵的人生历程

热门文章

  1. Exhaustive search 和 Beam search 详解(图文并茂)
  2. mysql分组查询只获取第一条
  3. 天翼弹性云服务器的SSH登录与文件上传
  4. IDEA官网打不开,详细解决方法(有图解)
  5. suricata的简单探究
  6. Scala 优雅的异常处理之 try 与 Try
  7. 刻意练习好好学习_如何使用刻意练习更有效地学习编程
  8. R语言glm.nb函数构建负二项分布回归模型、epiDisplay包的poisgof函数对拟合的负二项分布回归模型进行拟合优度检验、即模型拟合的效果、验证模型是否有过度离散overdispersion
  9. 嵌套的process.nextTick问题
  10. 分布式事务解决方案——基于Atomikos的实现