问题现象

某局点出现一个奇怪的现象，客户端给服务端发送消息，服务端仅能收到小部分消息，大部分消息从客户端发出后，服务端都未收到。

问题定位

• 初步分析

  • 根据现象初步分析，有可能是网络原因导致消息到服务端不可达，但是又无法佐证，因为确实有部分消息是能够被服务端接收到的。
  • 服务端应用问题，通过某些渠道了解到，接收端是客户自己实现的一个程序，可能是程序存在bug，导致消息丢失。该原因定位较困难，客户表示可以接收其他发送端消息，拒绝从接收端应用开始排查。

• 抓包

  • 根据初步分析的第一点猜测，我们决定进行抓包进行分析，由于发送端使用的是udp包，所以我们使用tcpdump工具，在发送端进行抓包，抓包后的结果是，所有的数据包均被tcpdump捕获。
  • 根据第一步的结果可以得出结论，问题并非出在发送应用端，接着我们在接收端进行tcpdump抓包，结果发现，发送端发出来的包，在服务端并没有全部被抓取到。问题已经显而易见了。

• 分析
  根据上述抓包结果，基本可以定界到中间的网络传输将数据包丢弃。而后排查网络问题，发现是网络中的防火墙将数据包大于1472字节的包拦截并丢弃了。而防火墙的这一行为为出厂时默认配置，目的是为了防止网络攻击。

问题根因

对于udp数据包，当数据包过大时，网卡会将其自动分片发送，而在这个案例中，udp报文里ip层的flag为0x02，即df(don’t fragment)位为1，表示不允许分片发送。

df = 1的情况有以下两种

1. 操作系统配置/proc/sys/net/ipv4/ip_no_pmtu_disc参数值
   若上述参数值为0（默认），则表示可分片。
   若上述参数值为2，则强制不进行分片。
   更详细的用法可以百度查一下。
   这个案例中发送端机器参数为。

2. 确认发送端网卡的mtu值是否大于1500
   这里为什么是1500呢？因为当udp数据包发出去后，会在报文中添加28字节的报文头，其中8字节的udp层，20字节的ip层，而1500 - 28 = 1472，所以防火墙会将大于1472字节的数据进行拦截。
   经过排查后发现发送端的机器的mtu值为8192，所以当从发送端将大于1472，小于8166的数据包发送出去时，报文中所携带的df值为1，后续经过的所有路由都没有进行分片，导致数据包到达防火墙后被过滤。

查询网卡mtu方法：ifconfig

正常情况下，该值都为1500，所以数据包能被正常分片在1472字节内。

解决方案

修改网卡mtu值，这个操作可以直接百度到了。
ifconfig 网卡名称 mtu 1500 up
或
vim /etc/sysconfig/network-scripts/对应网卡的ifcfg文件
新增一行MTU="1500"
保存后退出，并执行service network restart重启网卡服务。