以前总觉得类似IP和UDP在报文长度上应该是32位长度的，近期讨论媒体流某些比较大的帧为什么会被分片时，和同事讨论后深入地看了下协议，才发现报文长度确实只有16位。
我们知道IP包是因特网的精灵，它是网络传输的基本单位。对于这个基本单位受限于网络特质既存在最小报文限制也存在最大报文限制。IP报文的分片，在网络层提供了基本能力能够完成IP报文的组装。这样，我们可以认为，无论是TCP还是UDP，从网络侧得到的最小数据包就是单个IP包。所以，TCP一次读取socket操作能够读取多个字节，跟IP包的累积和IP包到的时机相关。UDP被称为数据报协议，我猜想的一个原因，就是源端尽量按照一个IP包进行承载，实在不行就发生IP分片，然后在目的段再次组成一个完整的IP包投送给UDP，在UDP协议头上并不支持UDP包的分片，所以，一次UDP数据发送，应该是小于65535个字节，大致64K。（至于应用层的分包，就是后续要讲到的帧分片）
我们在在处理流媒体的时间，一个完整的帧被收到，才能放到解码器中进行解码。当然我们也就自然地希望在流媒体的源端，最好就是按照一帧一帧发送，但是我们知道流媒体编解码算法，都是会产生好几种类型的帧，而其每个帧的大小，也不尽相同，有的帧类型的大小甚至是别的帧的好多倍。虽然视频编码部分，可以一次行地输出一帧数据，但是传输层，需要应对一些技术考虑(大报文丢失，误码率等)以及网络IP报文的基本限制(16位长度)，一包一帧，基本上很难，源端需要处理帧分片有关的逻辑。