如果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层制定如此复杂的打包规则，因为它知道它总是比低层碎片更糟糕？
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有效载荷格式化允许以适中的成本以更可靠的方式处理视频数据流，同时利用明确定义且适用于不同种类数据的规范。
除第一个片段外，分段IP流量不包含源或目标端口号。相反，它使用序列ID将数据包粘合在一起。这使得无状态中间网络设备（交换机和路由器）无法重新安装QoS（因为.1p或DSCP标志被其他设备清除或者从未存在过。）除非设备有资源需要管理对于每个会话状态，它要么必须对来自不相关流的片段进行速率限制/优先级排序，要么不对任何片段进行优先级排序，其中一些片段可以是语音/视频。
除非网络中存在MTU不匹配，否则AFAIK RTP数据包永远不会进行IP分段。因此，每个UDP头都有源和目标端口号，因此如果您可以驯服您的客户端以使用已知端口范围，您可以根据此信息重新建立QoS标记，并且您可以将IP片段作为普通流量传递，而不必担心丢弃语音/视频数据。
好了，经过深思熟虑之后，没有理由不使用高达64kB的基于IP的碎片（如果你有很多相同的时间戳的NAL单元需要聚合，例如通过STAP-A，就会发生这种情况） 。
RFC6184很清楚，你可以用这种方式使用高达64kB的NAL，因为每个NAL单元的大小恰好是2个字节（16位）都附加在实际的NAL单元之前，尽管保持低于MTU是首选。
如果“单次”NAL单位累计大小超过64kB会发生什么？ RFC6184没有说，但我想你必须将所有NAL作为单独的FU-A数据包发送，而不增加它们之间的时间戳（这是FU-A头中的开始/结束位的唯一原因）很有用，因为End位和RTP标记位之间不再有1：1的匹配。
RFC规定：
聚合数据包可以根据需要携带尽可能多的聚合单元;但是，聚合数据包中的数据总量显然必须适合IP数据包，并且应该选择大小，以便生成的IP数据包小于MTU大小
当“每帧单个NAL”大于MTU（例如，1460字节与以太网）时，必须用分段单元分组（例如，FU-A）进行分割。
但是，RFC中没有任何内容表明限制应该是1460字节。在进行仅以太网流传输时（例如上面计算的），有比这更大的意义
如果您的NAL单元大于64kB，则必须使用FU-A发送它，因为您无法将其放入单个IP数据报中。
RFC规定：
该有效载荷类型允许将NAL单元分段为若干RTP分组。在应用层上执行此操作而不是依赖于较低层碎片（例如，通过IP）具有以下优点：
o有效载荷格式能够通过IPv4网络传输大于64千字节的NAL单元，这可能存在于预先录制的视频中，特别是在高清格式中（每张图片的片数有限，这导致每张图片的NAL单位限制，这可能会导致大的NAL单位）。
o碎片机制允许分割单个NAL单元并应用第12.5节中描述的通用前向纠错。
据我所知：“如果您的NAL单元小于64k字节，而您不关心FEC，那么请不要使用FU-A，而是使用单个RTP数据包”
需要FU-A的另一种情况是在RTSP上接收具有RTP的H264流（交错模式）。 “数据包”大小必须适合2个字节（16位），因此即使在可靠的流套接字上发送，您也必须对更大的NAL单元进行分段。
我想补充一点，很多RTP服务器/发件人都在低效地发送拆分数据报。
这导致更多的系统调用，有时甚至长时间拉伸数据包，因为它们在数据包应该完成时没有上限，只是在发送下一批数据包之前完成。
如果您想扩展吞吐量或在低功耗嵌入式CPU上，这样的低效行为会受到严重影响。对于bw，网络和CPU效率的原因，通常更好的方法是将整个数据报一次性发送到内核并让它处理碎片而不是用户空间试图找出它。