谈谈网络通信中的流量整形

最新推荐文章于 2024-09-10 20:26:49 发布

double2li

最新推荐文章于 2024-09-10 20:26:49 发布

阅读量750

点赞数

分类专栏：网络通信文章标签：网络通信

原文链接：https://blog.51cto.com/ticktick/2473071

版权

网络通信专栏收录该内容

2 篇文章 1 订阅

订阅专栏

前面的两篇文章《谈谈网络通信中的 ACK、NACK 和 REX》和《谈谈网络通信中的 FEC 基础》介绍了网络通信中的丢包重传和 FEC 的相关理论和方法，他们都是在网络发生丢包的情况下的补救措施，本文则往前进一步，介绍下如何通过流量整形技术，尽可能地避免网络发生丢包。

从堵车说起

堵车的原因有很多种，我们先聊聊图中的这种：假设某公路是 3 股道，也就是说，每时刻能同时进入该公路的车辆并行是 3 辆，那么，如果某一时间段，同时试图进入该公路的车辆超过 3 辆，则必然会出现由于公路的承载能力不够带来的 “堵车”。

网络传输也类似，假设网络带宽是 2Mbps，如果在每秒硬塞给网络的数据包 > 2Mbps，网络通道也会受不了。不过它的表现形式与公路不一样的地方在于：超出网络承载能力的数据包，可能会被网卡/路由器/交换机给丢掉，即我们常说的丢包（loss）。

对于网络传输而言，丢包带来的成本是很高的，因为一些重要的数据包丢失后，是需要 “重传” 的，而 “重传” 太多，来回反复会增加了数据传输的延时，也会进一步恶化网络负荷，最终极大地降低了传输的效率。

因此，我们需要从根本上尽可能地减少 “丢包” 的产生，简单来说，就是控制单位时间内送入网络传输的数据量，尽量平滑且不要超过网络带宽承载能力。

控制对象

既然要控制送入网络传输的数据量，就得先找到数据是怎么产生的，又是在通过哪个环节送入到网络的。

如图，音视频传输的数据 “源头” ，无外乎就是本地的音视频文件、麦克风采集的音频流、摄像头采集的视频流、桌面采集到的屏幕流等，它们经过编码压缩和封包处理，然后经过 “发送模块” 送入到网络中。

设置和修改采集的配置（如：分辨率、帧率）、编码器的配置（如：GOP 间隔、码率）等，是可以减少实时产生的总数据量的，但是数据的产生并不是 “平滑” 的，特别是视频流/屏幕流，画面的突变，会带来数据量的突变，因此，送入到 “发送模块” 的数据量，也并不会总是 “平滑” 的。

从上面的 “堵车” 理论，为了避免丢包，我们需要尽可能地将数据 “平滑” 地送入网络中，因此，“流量整形” 在此派上了用场，它作用于 “发送模块”，目标是调整数据传输的平均速率，防止突发性的流量暴增导致网络拥塞和丢包。

流量整形

如何平输入和输出，一个最容易想到方法，就是增加 “缓冲”，让输入的数据先进入 “缓冲区” ，然后用恒定的 “速率” 从缓冲区取数据输出。这种方法称之为 “漏桶算法”。

漏桶算法（Leaky Bucket）

如图，使用一个 packet buffer（漏桶），把所有输入的 packet 缓存起来。

设置一个目标的输出码率（比如：3Mbps），固定的时间间隔（比如：10ms），读取 packet buffer（漏桶）中固定数量的 packet（如：3Mbit * 10ms / 1000 = 0.03Mbit）进行网络发送。注：如果某时刻缓冲区没有数据，则不用发送了。

漏桶算法的缺点

漏桶算法有一个明显的缺点，因为非常精准的网络带宽无法预判，那么假设你设置了一个比较小的目标码率（如 3Mbps），可能小于真实的网络带宽（如 10Mbps），这时，如果业务上产生了一些突发的流量，真实的网络带宽本可以允许更快地完成发送，但经过了漏桶算法后，依然会以恒定的目标码率慢慢地发送。所以说，漏桶算法无法充分用满网络资源来降低传输延时。

解决方案有 2 个：