一、IP分片原理

IP分片是网络上传输IP报文的一种技术手段。
IP协议在传输数据包时，将数据报文分为若干分片进行传输，并在目标系统中进行重组。
不同的链路类型规定有不同最大长度的链路层数据帧，称为链路层MTU（最大传输单元）。
常见以太网的MTU为1500，若IP协议在传输数据包时，IP报文长度大于转发接口的MTU，则将数据报文分为若干分片进行传输，分片报文到达接收方时，由接收方完成重组。
对于不同的传输层协议，在IP层上，需不需要进行分片是不同的：
TCP协议：
对于TCP来说，它是尽量避免分片的。因为当在IP层进行了分片后，如果其中的某片数据丢失，则需对整个数据报进行重传。因为IP层本身没有超时重传机制，当来自TCP报文段的某一片丢失后，TCP在超时后重发整个TCP报文段，该报文段对应于一份IP数据报，没有办法只重传数据报中的一个数据报片。而且如果对数据报分片的是中间路由器，而不是起始端系统，那么起始端系统就无法知道数据报是如何被分片的，因此基于这种原因，TCP是经常要避免分片的。
那么TCP层是如何避免IP层的分片呢？首先，TCP在建立连接时会进行3次握手，而在这3次握手中，客户端和服务端通常会协商一个值，那就是MSS（最长报文大小），用来表示本段所能接收的最大长度的报文段。MSS=MTU-TCP首部大小-IP首部大小，MTU值通过查询链路层得知。
当两端确认好MSS后进行通信，TCP层往IP层传输数据时，如果TCP层缓冲区的大小大于MSS，那么TCP层都会将其中的数据分组进行传输，这样就避免了在IP层进行分片。
UDP协议：
对于UDP而言，由于UDP是不需要保证可靠性的，没有超时和重传机制，这使得UDP很容易导致IP分片。
那么数据报被分片后是怎样的呢，又是以何种算法进行分片呢？首先我们回忆IP首部：
对于每份IP数据报来说，其16位标识字段都包含一个唯一值。在数据报被分片时，这个值同时被复制到每个片中。
在IP首部中，我们看到有一个占了3位的标志字段（上图中Flags）。
其中第1位作为保留字段；
第2位分段用来表示一个数据报是否允许在IP层被分片；
而第3位更多分片字段，则是当数据报被分片时，让接收端知道在什么时候完成所有的分片组装，除了最后一片外，其他每个组成数据报的片都要把该比特置1。
而如果将其中的分段标志比特位置1，表示不允许IP层对数据报进行分片。例如当路由器收到一份需要分片的数据报，而在IP首部又设置了不分片（DF）的标志比特，路由器会丢弃数据报并发送一个ICMP差错报文（“需要进行分片但设置了不分片比特”）。
IP首部中13位的偏移量字段表示IP分片在整个数据流中的位置，第一个数据报分片的偏移量置为0，而后续的分片偏移量则是根据网络的MTU大小设置，且必须为8的整数倍。
需要注意的是，任何传输层的首部只出现在第一片数据中，后续报文均不带传输层信息。
这是IP分片的第一个数据分片，可以看出其IP的上层协议为ICMP协议，而在后续的分片报文中却无法看到上层协议的具体信息。
接收方在收到经过IP层分片的数据报文后，首先根据分片标志中的更多分段位判断是否是最后一个分片报文，如果是，则根据分片偏移量计算各个分片报文在原始数据报中的位置，进行重组。如果不是最后一个分片，则需等待所有分片到达后再完成重组。

二、分片在生产中的实际问题案例

在实际生产环境中遇到了UDP大包分片的问题：
在openstack云环境中，我们使用Linux bridge的iptables规则来实现安全组，但是当UDP的包大于MTU（1500）时，当数据包从tap口发到qbr（linux bridge），qbr会先将分片包进行重组（因为netfiler要针对有状态的数据包进行连接跟踪），当处理完毕后，再将数据包UDP封装发出（分片中都携带UDP报头，这种封装方式是错误的），导致客户端重组UDP报文出错，连接无法建立。
分片数据包的大小：
UDP包在MTU1500下的大小：（1500 Bytes） - IP头（20Bytes）- UDP头（8Bytes）= 1472（Bytes）
示例：数据包length为2730的报文，如何分两片：
length 2730 = 1472（1500-28） + 1258（1278-20因为除了一个分片外其余的分片不包含udp数据头）
第一片（既有IP头，也有传输层头）：length 1500 = 1472 + 8 （UDP头） + 20 （IP头）
第二片（只有IP头，不带传输层头）：length 1278 = 1258 + 20 （IP头）

qbr的错误重组后不再进行分片转发，直接封装UDP：
#https://bugs.launchpad.net/neutron/+bug/1542032

三、分片带来的问题

1.分片带来的性能消耗
分片和重组会消耗发送方、接收方一定的CPU等资源，如果存在大量的分片报文的话，可能会造成较为严重的资源消耗；
分片对接收方内存资源的消耗较多，因为接收方要为接收到的每个分片报文分配内存空间，以便于最后一个分片报文到达后完成重组。
2.分片丢包导致的重传问题
如果某个分片报文在网络传输过程中丢失，那么接收方将无法完成重组，如果应用进程要求重传的话，发送方必须重传所有分片报文而不是仅重传被丢弃的那个分片报文，这种效率低下的重传行为会给端系统和网络资源带来额外的消耗。
3.分片攻击
黑客构造的分片报文，但是不向接收方发送最后一个分片报文，导致接收方要为所有的分片报文分配内存空间，可由于最后一个分片报文永远不会达到，接收方的内存得不到及时的释放（接收方会启动一个分片重组的定时器，在一定时间内如果无法完成重组，将向发送方发送ICMP重组超时差错报文，，只要这种攻击的分片报文发送的足够多、足够快，很容易占满接收方内存，让接收方无内存资源处理正常的业务，从而达到DOS的攻击效果。
4.安全隐患
由于分片只有第一个分片报文具有四层信息而其他分片没有，这给路由器、防火墙等中间设备在做访问控制策略匹配的时候带来了麻烦。
如果路由器、防火墙等中间设备不对分片报文进行安全策略的匹配检测而直接放行IP分片报文，则有可能给接收方带来安全隐患和威胁，因为黑客可以利用这个特性，绕过路由器、防火墙的安全策略检查对接收方实施攻击；
如果路由器、防火墙等中间设备对这些分片报文进行重组后在匹配其安全策略，那么又会对这些中间设备的资源带来极大的消耗，特别是在遇到分片攻击的时候，这些中间设备会在第一时间内消耗完其所有内存资源，从而导致全网中断的严重后果。