当采用 UDP 进行数据传输时，一旦报文长度大于 MTU，则需要 IP 层介入进行数据分片和*，除了第一个 IP 分片包含 UDP 的 Header 信息，之后的 IP 分片仅包含 UDP 的剩余数据，不再携带 UDP Header 信息。
IP 分片示意图
Wireshark IPv4/IPv6 协议的默认参数中勾选了 IP 分片*，影响我们分析 IP 分片，建议取消勾选
Wireshark 取消 IP 分片*的设置
IP 分片*失败场景背景：时间同步协议 IEEE 1588v2 规定了 PTP 事件报文的默认端口号为 319，PTP 通用报文的默认端口号为 320。
UDP 报文格式
如果 IP 分片数据从第二个（以此类推） IP 分片数据开始， 排除 IP 首部之后，前两个字节可能被识别为 UDP 报文的源端口号，如下图，在车载领域，一旦使用 PTP 进行时间同步，当普通的 IP 分片数据到达 Switch 芯片的 Ingress 时，如果刚好分片数据的前两个字节对应的端口号为 319 ，Switch 可能会将 IP 分片数据识别为 PTP 报文（UDP 报文），进而修改 PTP 报文中的时间戳字段，导致在目标端出现 IP *异常。
IP 分片异常示例
- 01 3f 即 319 会被 Switch 识别为 PTP 事件报文源端口号
- 对于事件报文，43 62 5e c1 表示被 Switch 内部修改过的 PTP 时间戳
PS：参考 IEEE 802.1As-2020 ，关于 gPTP 通用报文头的定义如下，上述的时间戳字段就位于 messageTypeSpecific
gPTP Common Header 定义
总结由于车载以太网通信主要基于简单的二层网络拓扑结构，为了考虑时效性，很多时候会采用 UDP 作为传输层协议，一旦应用层数据超过链路 MTU，就可能会触发 IP 层的分片机制（IP 分片会影响数据传输效率，且存在网络攻击风险），如果要发送的数据过大，建议在应用层做分包和组包处理，优化网络传输效率。
参考链接：
