综述部分阅读
主要介绍了以下几个方面:
应用层的优化
- 编码器解码器的优化
- 协议设计
- 结合网络情况自适应调整, 例如自适应编码
传输层的优化
- 拥塞控制优化
- 丢包恢复优化
网络层的优化
- 优化路由器(调整缓冲区大小)
- 优化路由器(管理队列和算法控制延迟)
- 端网直接消息传递
数据通路应用层相关工作
| 学界/业界方案 | 解决方案 | 主要思路 |
|---|---|---|
| - Swift (NSDI’22) CGEncoder (MMSys’20) VP9 (Google’13) | 实时编解码器 | 通过更新编解码设计在弱网等情况下依然保证内容解码 |
| BB (SIGCOMM’14) Pensieve (SIGCOMM’17) Puffer (NSDI’20) | 自适应码率算法 | 通过让码率适配带宽，以降低卡顿 |
| RTP/RTCP (RFC8888) RTSP (RFC7826) DTP (ICNP’21) | 多媒体传输协议 | 通过协议设计来传递应用需要的信息 |
编码解码相关工作
因为视频一帧一帧之间有关联, 因此可以根据这些关联, 把视频进行压缩, 以节约带宽成本, 再利用这些关联, 把视频还原回来. 这便是编码器和解码器.
目前比较常见的编码器还是以 H.264 为主, 优化工作主要集中在两个方面
- 优化编码器的性能
- 针对场景, 进行设计和优化
谷歌的VP9编码器, 包含在 WebRTC 实时音视频传输框架
评估图像或视频质量的指标 : SSIM , PSNR
由于接编码需要硬件支持, 目前已经有专门的芯片做这方面的工作, 但是现在新兴的接编码机制并不一定适配硬件, 因此 H.264 编码 20 年来一直是最为广泛的编解码机制
自适应码率优化
自适应码率算法早在实时多媒体传输诞生时便被提出. 例如 Buffer-based 算法
其创新性的提出, 通过估计在点播多媒体视频中客户端缓冲区的情况, 来调整码率.
- 客户端缓冲区较低时, 就降低编码码率来尽快发新内容
- 客户端缓冲区较高时, 就增加编码码率来提高内容质量
个人思考 : 可以用机器学习预测的方法, 来进行自适应码率的优化, 可以对缓冲区的变化, 以及网速的变化进行数据挖掘, 训练模型
孟哥说了一句, 在应用层不关注自适应码率工作, 我没太懂这个东西, 但是他又把这个内容放到应用层, 我觉着有点奇怪.
多媒体传输协议设计
设计新的应用层协议, 也是近年来的重要研究工作. 应用最广的协议是 RTP/RTCP(基于 UDP)
- RTP 协议从服务器向客户端发送数据包(数据通路)
- RTCP负责从客户端向服务器反馈网络状态, 视频状态等信息(控制通路)
两种控制方式, 这里是在应用层进行了控制, 还有一种是在传输层进行控制(RTSP等), 应用层不做控制,减去应用层的控制开销.
数据通路传输层相关工作
| 学界/业界方案 | 解决方案 | 主要思路 |
|---|---|---|
| Sprout (NSDI’13)、GCC (MMSys’16)、 NADA (RFC8698)、SCREAM (RFC8298)、 Copa (NSDI’18)、Vivace (NSDI’18) | 拥塞控制 | 通过让发送速率适配带宽以减少延迟 |
| WebRTC (ICIP’13)、AdaptFEC (MM’19)、 StreamMelt (NSDI’23)、TLP (RFC8985) | 丢包恢复 | 通过减少重传来减少端到端延迟 |
拥塞控制
经典的算法有 Reno 和 Cubic , 但是这些算法都是尽可能挤占队列来提升网络资源利用率
谷歌 2016 年提出的 BBR 算法, 通过测量链路中的带宽瓶颈和往返时延, 判断有多少数据报文在网络中, 以此为速率发送数据包, 就不至于一直挤占瓶颈.
丢包恢复
丢包恢复目的是为了保证可靠传输.
TCP 区别于 UDP 便是 TCP 有丢包恢复.
TCP 使用重传超时(RTO)进行判断是否丢包
其次是通过引入冗余的方式进行丢包恢复. 比如说校验码.
例如 : 发 3 个包, 然后把校验码放到第四个包里, 如果有问题就立即nak.
还可以动态调整冗余包的数量, 丢的多了, 就多发点冗余包, 保证其可以接收到
例如: FEC技术, Bolot 和 USF 算法分别根据历史丢包进行参数调整
万物都可 AI , 也可以 AI预测
数据通路网络层相关工作
| 学界/业界方案 | 解决方案 | 主要思路 |
|---|---|---|
| CoDel (CACM’12)、RED、BLUE、GREEN、Yellow | 主动队列管理 | 尽早丢包迫使发送端降速以避免超发 |
| BDP/n (SIGMETRICS’21)、ABS (INFOCOM’22) | 队列大小优化 | 设置合适的队列大小以降低延迟 |
| XCP (SIGCOMM’02)、RCP (INFOCOM’08)、Kickass (ICNP’16)、ABC (NSDI’20) | 端网消息传递 | 携带更多维度的网内状态以便决策 |
广域网存在可部署问题, 因为不存在一个实体控制一条路径上所有设备的情况.
主动队列管理
较早的主动队列管理算法 : RED, 其通过在早期以概率性随机丢弃的方式告诉当前网络恶化的情况
目前边缘路由器上部署的默认主动管理队列算法是 2012 年提出的 CoDel, 主要解决的问题是:
- 根据队列长度的估计
- 难以适应不同带宽的路由器
- 采用在队列中的停留时间可以进准控制延迟目标
就是说, 我们不关注队列长度, 我们关注在队列中的停留时间.
队列大小优化
队列过小会导致面对突发流量频繁丢包
队列过大会导致速率调整不好时, 导致排队时延过长
ABS 自适应队列大小
以及理论分析 : 例如瓶颈队列的大小应该不小于带宽延时积
端网消息传递
设计新的协议, 在端主机和网络设备之间进行更好的消息传递, 来控制延迟
实际很难做到, 因为需要同时改变服务器(阿里,腾讯)和中间路由器(华为), 从现实角度很难调和
