RTP分片与UDP分片

Question

我不明白，如果UDP (或IP)层进行分段，我们为什么还要费心在RTP级别进行分段。

据我所知，假设我们在以太网链路上，MTU是1500字节。

例如，如果我必须发送3880字节，则在IP层分段将导致分别为1500、1500和940字节的3个分组(IP报头为20字节，因此总开销为60字节)。

如果我在UDP层这样做，开销将是84字节(3x28字节)。

在RTP层，它是120字节的开销。

在H264/NAL分组层，FU-A模式多了3个字节(所以最后是123个字节)。

对于如此小的数据包，它最终会使初始数据包大小增加3.1%，而在IP层，它只会浪费1.5%。

在知道它总是比低层碎片更糟糕的情况下，在RTP层制定如此复杂的打包规则有什么合理的理由吗？

Answer 1

RTP在设计时考虑到了UDP。

应用程序通常在UDP之上运行RTP以利用其多路复用和校验和服务；这两种协议都贡献了传输协议功能的一部分。

然而，添加到原始UDP中RTP服务，例如检测分组重新排序、丢失和定时的能力，要求UDP数据由RTP有效载荷以及服务信息组成。

与其他分组网络一样，

互联网偶尔会丢失和重新排序分组，并将它们延迟不同的时间。为了应对这些损害，RTP报头包含定时信息和序列号，其允许接收器重建由源产生的定时，从而在该示例中，音频块每20ms连续地向扬声器播放。对于会议中的RTP分组的每个源，分别执行该定时重建。接收器还可以使用序列号来估计有多少数据包正在丢失。

然后RTP被设计成可扩展的、通用的报头和特定于数据的有效负载：

RTP是一个故意不完整的协议框架。本文档指定了RTP适用于所有应用程序的通用功能。与其中可通过使协议更通用或通过添加需要解析的选项机制来适应附加功能的传统协议不同，RTP旨在通过根据需要修改和/或添加报头来定制。

所有报价均来自RFC 1889 "RTP: A Transport Protocol for Real-Time Applications"。

也就是说，H.264流的RTP开销不仅仅是带宽的浪费。RTP报头和H.264有效载荷格式化允许以中等成本以更可靠的方式处理视频数据流，同时利用定义良好且适用于不同类型数据的规范。

Answer 2

除第一个分段外，分段的IP流量不包含源端口号或目的端口号。相反，它使用序列ID将数据包粘合在一起。这使得需要重新安装QoS的无状态中间网络设备(交换机和路由器)不可能重新安装DSCP (因为.1p或DSCP标志已被其他设备清除，或者根本就不存在)。除非设备拥有管理每个会话状态的资源，否则它要么必须冒险对来自不相关流的片段进行速率限制/优先排序，要么不对任何片段进行优先排序，其中一些片段可能是语音/视频。

除非网络中存在MTU不匹配，否则AFAIK RTP数据包从不进行IP分段。因此，每个UDP头都有源端口号和目的端口号，因此，如果您可以驯服客户端以使用已知端口范围，则可以根据此信息重新建立QoS标记，并且可以将IP片段作为普通流量传递，而不必担心丢失语音/视频数据。

Answer 3

我想补充的是，许多RTP服务器/发送器都在低效地发送分离的数据报。

• 在动态缓冲区上下文中使用了大量的malloc/free。
• 他们还在消息的每个部分使用一个系统调用，而不是消息向量。
• 雪上加霜他们通常在发送数据报的每一部分之间做大量的时间计算/其他处理。

这会导致更多的syscall，有时甚至会在很长一段时间内拉伸数据包，因为它们没有数据包应该完成的上限，只有在发送下一批数据包之前完成。

如果您想要扩展吞吐量或在低功耗的嵌入式CPU上，像这样的低效行为会严重阻碍您的工作。出于带宽、网络和CPU效率的原因，通常最好将整个数据报一次性发送到内核，让它处理碎片，而不是让用户空间试图弄清楚它。