我不明白如果UDP(或IP)层进行碎片化，为什么我们要在RTP级别进行碎片化。
据我所知，假设我们在以太网链路上，MTU是1500字节。
如果我必须发送，例如，3880字节，在IP层分片，将产生3个分别为1500,1500和940字节的数据包(IP头是20字节，因此总开销为60字节)。
如果我在UDP层这样做，开销将是84字节(3x 28字节)。
在RTP层是120字节的开销。
在H264/NAL分组层，它是3个字节(所以123字节最终)的FU-A模式。
对于这样一个小的数据包，它使初始数据包大小最终增加3.1%，而在IP层，它只会浪费1.5%。
在RTP层制定如此复杂的打包规则是否有任何正当理由，因为它总是比底层碎片更糟糕?
除第一个分片外，分片后的IP流量不包含源端口号和目的端口号。相反，它使用序列id将数据包粘合在一起。这使得需要重新安装QoS的无状态中间网络设备(交换机和路由器)不可能(因为。1p或DSCP标志被另一个设备清除，或者从一开始就不存在)。除非设备有资源来管理每个会话状态，否则它必须冒险限制速率/优先考虑来自不相关流的片段，或者不优先考虑任何片段，其中一些可以是语音/视频。
AFAIK RTP数据包永远不会ip分片，除非网络中有MTU不匹配。因此，每个UDP报头都有源端口号和目的端口号，所以如果你可以驯服你的客户端使用已知的端口范围，你可以根据这些信息重新建立QoS标记，你可以将IP片段作为普通流量传递，而不用担心丢失语音/视频数据。
RTP在设计时考虑了UDP。
应用程序通常在UDP之上运行RTP以利用其多路复用和校验和服务;两个协议都贡献了传输协议功能。
然而，添加到原始UDP的RTP服务，如检测数据包重新排序、丢失和定时的能力，要求UDP数据由RTP有效载荷和服务信息组成。
Internet，像其他分组网络一样，偶尔会丢失和丢失数据重新排序数据包并通过可变的时间延迟它们。应对由于这些缺陷，RTP报头包含计时信息还有一个序列号可以让接收器重建定时产生的源，所以在这个例子中，块音频每隔20毫秒连续播放一次。这对每个RTP源分别进行时序重构会议中的数据包。序列号也可以被接收方估计丢失了多少数据包。
RTP被设计成可扩展的，通用的头和数据特定的有效负载:
RTP是一个故意不完整的协议框架。本文档指定了期望在所有应用程序中通用的功能，这些功能适用于RTP。与常规协议不同，常规协议可以通过使协议更通用或通过添加需要的选项机制来容纳额外功能解析时，RTP旨在根据需要通过修改和/或添加报头来定制。
所有引用均来自RFC 1889"RTP:实时应用的传输协议"。
也就是说，H.264流的RTP开销不仅仅是带宽的浪费。RTP报头和H.264有效载荷格式允许以中等成本以更可靠的方式处理视频数据流，同时利用定义良好且适用于不同类型数据的规范。
我想补充的是，很多RTP服务器/发送者发送分割数据报的效率很低。
- 他们在动态缓冲区上下文中使用了大量的malloc/free。
- 它们还对消息的每个部分使用一个系统调用，而不是消息向量。 更糟糕的是，他们通常在发送数据报的每个部分之间做大量的时间计算/其他处理。
这会导致更多的系统调用，有时甚至会将数据包延长很长时间，因为它们没有数据包应该完成的上限，只有在发送下一批数据包之前完成。
如果您想要扩展吞吐量或在低功耗嵌入式CPU上，这样的低效行为会严重阻碍。出于性能、网络和CPU效率的考虑，将整个数据报一次性发送给内核并让它处理碎片，而不是用户空间试图找出它，这通常是更好的方法。
嗯，在仔细考虑了这个问题之后，没有理由不使用最多64kB的基于IP的碎片(如果您有很多相同的时间戳的NAL单元需要聚合，例如通过stp - 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字节。当只做以太网流(如上所述)时，更大的值是有意义的
如果您有一个大于64kB的NAL单元，那么您必须使用FU-A发送它，因为您无法在单个IP数据报中容纳它。
RFC声明:
此有效负载类型允许将NAL单元分割为多个RTP包。这样做是基于应用层，而不是依赖于较低层的碎片(例如，按IP划分)有以下优点:
o有效载荷格式能够运输更大的NAL单元超过64 kb的IPv4网络，可能存在于pre-录制的视频，特别是高清格式的每张图片的切片数的限制，结果是A每幅图片的NAL单位限制，这可能导致较大的NAL单位).
0碎片机制允许对单个NAL单元进行碎片化并应用通用前向纠错，如
12.5节。
我理解为:"如果您的NAL单位小于64kbytes，并且您不关心FEC，那么不要使用FU-A，而是使用单个RTP数据包"
另一种需要FU-A的情况是在RTP通过RTSP(交错模式)接收H264流时。"数据包"的大小必须符合2字节(16位)，所以即使在可靠的流套接字上发送，也必须分段更大的NAL单元。