我目前遇到的问题是，当大量 RTP 流（>800）进入一台服务器时，最大速度只有大约 70-80 Mbit（在千兆 LAN 上 - 所有硬件组件都是千兆组件）130 字节有效载荷 - 有效载荷较大时一切都很好（本地网络中为 700 Mbit+）。
我正在寻找这种行为的一些解释（Header Overhead 就是其中之一）以及如何优化网络组件（NIC、交换机等）以实现 RTP 和/或小包尺寸的指南/专业知识。
如果有人能帮忙就太好了——我也会在这里发布我的发现。
多谢
答案1
这Freeswitch 维基给出了几个技巧，包括减少 RX 和 TX 缓冲区以避免缓冲区膨胀，并尝试不同的TCP拥塞控制算法。
在协议网站有很多很好的通用技巧，而您最应该做的事情可能是减少发送较大数据包的频率以减少开销。
我对 RTP 了解不多，但如果您使用的是 TCP，那么可以尝试关闭不需要的选项，或者切换到 UDP。我通常不喜欢禁用 TCP 时间戳，但这可能是它有效的时候之一。
QoS RTP 贯穿整个网络，因此它具有优先权。尽可能少地检查流量，如果您可以执行 L2 QoS，理论上可能比 L3 QoS 更快，因为涉及的层较少，尽管交换机是用硬件完成所有这些工作的，因此交换机不太可能成为瓶颈。
答案2
线路上用于标头的额外容量通常不是限制因素。小数据包效率低下的原因还有另外一个。
每个转发数据包的节点都会对每个数据包进行一些处理，以便找出要转发到哪个接口，并可能更新校验和。
这意味着硬件不仅会限制每秒的位数，还会限制每秒的数据包数。将这两个数字相除将得到数据包大小，此时这两个因素会产生相同的限制。
这个数字通常远高于几百字节。只要大数据包能够充分利用线路带宽，小数据包的性能就不用太在意。这在一定程度上是由于市场营销关注的是每秒比特数，而不是每秒数据包数。