如果UDP（或IP）层执行碎片，我不明白为什么我们在RTP级别打扰碎片。
据我了解，让我们说我们在以太网链路上，MTU是1500字节。
如果我必须发送，例如，3880字节，在IP层分段，将导致分别为1500,1500和940字节的3个数据包（IP报头为20个字节，因此总开销为60个字节）
如果我在UDP层执行此操作，则开销将为84字节（3x 28字节）。
在RTP层，它有120个字节的开销。
在H264 / NAL分组层，它为FU-A模式增加了3个字节（因此最终为123个字节）。
对于如此小的数据包，初始数据包大小最终增加了3.1％，而在IP层，它只会浪费1.5％。
是否有任何正当理由在RTP层制定如此复杂的打包规则，因为它知道它总是比下层碎片更糟糕？
答案 0 :(得分：2)
RTP的设计考虑了UDP。
应用程序通常在UDP之上运行RTP以使用它 多路复用和校验和服务;这两个协议都有贡献 传输协议功能。
然而，添加到原始UDP的RTP服务（例如检测数据包重新排序，丢失和定时的能力）要求UDP数据由RTP有效负载和服务信息组成。
与其他分组网络一样，互联网偶尔也会失败 重新排序数据包并将其延迟不同的时间。应对 在这些损伤的情况下，RTP报头包含定时信息 以及允许接收器重建的序列号 由源产生的时序，因此在这个例子中，大块的 音频每20毫秒连续播放一次。这个 对于每个RTP源，分别执行定时重建 会议中的数据包。序列号也可以使用 接收器估计丢失的数据包数量。
然后RTP被设计为可扩展的，公共头和特定于数据的有效载荷：
RTP是一种故意不完整的协议框架。本文件规定了RTP适用的所有应用程序中预期的通用功能。与通过使协议更通用或通过添加需要的选项机制来适应附加功能的传统协议不同 在解析时，RTP旨在根据需要通过修改和/或添加到头部来定制。
所有报价均来自RFC 1889 "RTP: A Transport Protocol for Real-Time Applications"。
也就是说，H.264流的RTP开销不仅仅是浪费带宽。 RTP报头和H.264有效载荷格式化允许以适中的成本以更可靠的方式处理视频数据流，同时利用规范明确且适用于不同类型数据的规范。
答案 1 :(得分：1)
除第一个片段外，分段IP流量不包含源或目标端口号。相反，它使用序列ID将数据包粘合在一起。这使得无状态中间网络设备（交换机和路由器）无法重新安装QoS（因为.1p或DSCP标志被其他设备清除或者从未存在过。）除非设备有资源需要管理对于每个会话状态，它要么必须对来自不相关流的片段进行速率限制/优先级排序，要么不对任何片段进行优先级排序，其中一些片段可以是语音/视频。
除非网络中存在MTU不匹配，否则AFAIK RTP数据包永远不会进行IP分段。因此，每个UDP头都有源和目标端口号，因此如果您可以驯服您的客户端以使用已知端口范围，您可以根据此信息重新建立QoS标记，并且您可以将IP片段作为普通流量传递，而不必担心丢弃语音/视频数据。
答案 2 :(得分：0)
嗯，经过深思熟虑之后，没有理由不使用高达64kB的基于IP的碎片（如果你有很多相同的时间戳的NAL单元需要通过STAP-A聚合，就会发生这种情况例如）。
RFC6184很清楚，你可以这样使用多达64kB的NAL，因为每个NAL单元的大小正好是2个字节（16位），在实际的NAL单元之前被附加，但是优先保持低于MTU。
如果“单次”NAL单位累计大小超过64kB，会发生什么？ RFC6184没有说，但我想你必须将所有NAL作为单独的FU-A数据包发送而不增加它们之间的时间戳（这是仅的地方之所以FU-A报头中的开始/结束位是有用的，因为在结束位和RTP标记位之间不再有1：1的匹配。）
RFC声明：
聚合数据包可以 根据需要携带尽可能多的聚合单元;但总数 聚合数据包中的数据量显然必须适合IP 数据包，应该选择大小以便生成IP数据包 小于MTU大小
当“每帧单个NAL”大于MTU时（例如，带有以太网的1460个字节），必须使用分段单元分组（例如，FU-A）进行分割。
然而，RFC中没有任何内容表明限制应该是1460字节。当仅进行以太网流传输（如上所述）时，拥有更大的数据是有意义的
如果您的NAL单位大于64kB，那么您必须使用FU-A发送它，因为您无法将其放入单个IP数据报中。
RFC声明：
此有效负载类型允许将NAL单元分段为多个RTP 数据包。在应用程序层上执行此操作而不是依赖于此 低层碎片（例如，通过IP）具有以下优点：
o有效载荷格式能够传输更大的NAL单元 通过IPv4网络可能存在的64 KB以上 录制的视频，特别是高清格式（有 每张图片的切片数量的限制，这导致a 每张图片的NAL单位限制，这可能导致大的NAL 单元）。
o碎片机制允许分割单个NAL单元 并应用如下所述的通用前向纠错 第12.5节。
我理解为：“如果您的NAL单位小于64k字节，并且您不关心FEC，那么请不要使用FU-A，而是使用单个RTP数据包”
需要FU-A的另一种情况是在RTSP上接收具有RTP的H264流（交错模式）。 “数据包”大小必须适合2个字节（16位），因此即使在可靠的流套接字上发送，你也必须分割更大的NAL单元。
答案 3 :(得分：0)
我想补充一点，许多RTP服务器/发送器会低效地发送拆分数据报。
这会导致更多的系统调用，有时甚至长时间扩展数据包，因为它们在应完成数据包时没有上限，只是在发送下一批数据包之前已完成操作。
如果要扩展吞吐量或在低功耗嵌入式CPU上，这种低效行为会变得很严重。出于bw，网络和CPU效率的原因，通常最好是一次将整个数据报发送到内核，然后让它处理碎片而不是用户空间来解决这个问题。