1. UDP协议格式

U D P不提供可靠性：
它把应用程序传给I P层的数据发送出去，但是并不保证它们能到达目的地

UDP封装
UDP：用户数据报协议
UDP首部

2. IP 分片

U D P是一个简单的面向数据报的运输层协议：

进程的每个输出操作都正好产生一个U D P数据报，并组装成一份待发送的I P数据报。
分片
       物理网络层一般要限制每次发送数据帧的最大长度。任何时候I P层接收到一份要发送的I P数据报时，它要判断向本地哪个接口发送数据（选路），并查询该接口获得其M T U。I P把M T U与数据报长度进行比较，如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发生在中间路由器上。
       把一份I P数据报分片以后，只有到达目的地才进行重新组装（这里的重新组装与其他网络协议不同，它们要求在下一站就进行进行重新组装，而不是在最终的目的地）。重新组装由目的端的I P层来完成，其目的是使分片和重新组装过程对运输层（ T C P和U D P）是透明的。
       已经分片过的数据报有可能会再次进行分片（可能不止一次）。I P首部中包含的数据为分片和重新组装提供了足够的信息。

回忆I P首部，对于发送端发送的每份I P数据报来说，其标识字段都包含一个唯一值。该值在数据报分片时被复制到每个片中。标志字段用其中一个比特来表示“更多的片”。除了最后一片外，其他每个组成数据报的片都要把该比特置1。片偏移字段指的是该片偏移原始数据报开始处的位置。另外，当数据报被分片后，每个片的总长度值要改为该片的长度值。
最后，标志字段中有一个比特称作“不分片”位。如果将这一比特置1，I P将不对数据报进行分片。相反把数据报丢弃并发送一个I C M P差错报文（“需要进行分片但设置了不分片比特”）给起始端。

U D P很容易导致I P分片
T C P试图避免IP分片

理论上，I P数据报的最大长度是6 5 5 3 5字节，这是由I P首部1 6比特总长度字段所限制的。去除2 0字节的I P首部和8个字节的U D P首部， U D P数据报中用户数据的最长长度为6 5 5 0 7字节。但是，大多数实现所提供的长度比这个最大值小

限制因素

应用程序可能会受到其程序接口的限制。socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于UDP socket，这个长度与应用程序可以读写的最大U D P数据报的长度直接相关。现在的大部分系统都默认提供
了可读写大于8 1 9 2字节的U D P数据报
第二个限制来自于T C P / I P的内核实现。可能存在一些实现特性（或差错），使I P数据报长度小于6 5 5 3 5字节。

不可靠
UDP并不保证数据报成功到达目的端口
IP分片
尽管IP分片对于应用程序是透明的，但是IP分片与组装会降低传输效率
用户可以发送指定字节长度的UDP数据报，但是应用程序应该读取多大的数据报呢？根据具体的实现，结果可能是不同的
讨论T C P时，我们发现它为应用程序提供连续的字节流，而没有任何信息边界。T C P以应用程序读操作时所要求的长度来传送数据，因此，在这个接口下，不会发生数据丢失