xry*_*669 5 rtp fragmentation h.264
如果 UDP（或 IP）层进行分段，我不明白为什么我们要在 RTP 级别进行分段。
据我了解，假设我们在以太网链路上，MTU 为 1500 字节。
例如，如果我必须发送 3880 字节，在 IP 层分段，将产生 3 个数据包，分别为 1500、1500 和 940 字节（IP 标头为 20 字节，因此总开销为 60 字节）。
如果我在 UDP 层执行此操作，则开销将为 84 字节（3x 28 字节）。
在 RTP 层，它有 120 字节的开销。
在 H264/NAL 打包层，FU-A 模式多出 3 个字节（因此最终为 123 个字节）。
对于这么小的数据包，初始数据包大小最终增加了 3.1%，而在 IP 层，总体上只会浪费 1.5%。
知道它总是比低层碎片更糟糕，是否有任何正当理由在 RTP 层制定如此复杂的打包规则？
小智 5
除第一个分片外，分片的 IP 流量不包含源端口号或目标端口号。相反，它使用序列 ID 将数据包粘合在一起。这使得需要重新安装 QoS 的无状态中间网络设备（交换机和路由器）变得不可能（因为 .1p 或 DSCP 标志已被另一台设备清除或从一开始就不存在。）除非该设备具有管理资源在每个会话状态下，它要么必须冒着对来自不相关流的片段进行速率限制/优先排序的风险，要么不对任何片段进行优先排序，其中一些片段可以是语音/视频。
据我所知，RTP 数据包永远不会产生 IP 碎片，除非网络中存在 MTU 不匹配的情况。因此，每个 UDP 标头都有源端口号和目标端口号，因此，如果您可以让客户端使用已知的端口范围，则可以根据此信息重新建立 QoS 标记，并且可以将 IP 片段作为普通流量传递，而不必担心丢弃语音/视频数据。
RTP 的设计考虑了 UDP。
应用程序通常在 UDP 之上运行 RTP，以利用其多路复用和校验和服务；这两种协议都贡献了传输协议功能的一部分。
然而，添加到原始 UDP 的 RTP 服务（例如检测数据包重新排序、丢失和计时的能力）要求 UDP 数据由 RTP 有效负载和服务信息组成。
与其他分组网络一样，互联网偶尔会丢失分组并重新排序，并延迟不同的时间量。为了应对这些缺陷，RTP 标头包含定时信息和序列号，允许接收器重建源产生的定时，因此在本例中，音频块每 20 毫秒连续向扬声器播放一次。此时序重建是针对会议中的每个 RTP 数据包源单独执行的。接收器还可以使用序列号来估计丢失的数据包数量。
然后 RTP 被设计为可扩展的、通用的标头和数据特定的有效负载：
RTP是一个故意不完整的协议框架。本文档指定了那些预计在适用 RTP 的所有应用程序中通用的功能。与传统协议不同，传统协议可以通过使协议更通用或通过添加需要解析的选项机制来容纳附加功能，RTP 旨在通过根据需要修改和/或添加标头来进行定制。
所有引用均来自RFC 1889“RTP：实时应用程序的传输协议”。
也就是说，H.264 流的 RTP 开销不仅仅是带宽的浪费。RTP 标头和 H.264 有效负载格式允许以适中的成本以更可靠的方式处理视频数据流，同时利用定义明确且适用于不同类型数据的规范。