麒麟系统内核更新导致的新问题：发送大UDP数据包响应无响应的现象及其抓包结果分析
自从上一次关于麒麟系统下Conntrack工具删除命令无法使用的问题后，麒麟SP03版本发布的内核4.19.90-52.42又出现了一个新的问题，那就是在进行ping测试并尝试发送大的UDP数据包时出现了无响应的现象。具体的现象和操作过程如下：
在特定环境下使用系统时，输入uname -a命令显示的系统内核信息如下：
Linux node1 4.19.90-52.42.v2207.ky10.aarch64 4 P Tue Oct 8 16:54:49 CST 2024 aarch64 aarch64 aarch64 GNU/Linux。这说明我们正在使用的是麒麟SP03版本的特定内核。
在复现方法上，首先使用默认的ping命令，结果显示一切正常。当尝试使用ping命令自定义发送报文大小时，设置报文大小为4096时，却无法ping通目标地址。这种情况下的具体表现是，当尝试发送大的ICMP数据包时，系统无法成功响应。这给我们的网络通讯带来了极大的困扰。
UDP包验证及处理方法
为了验证UDP包，我们首先需要编写一个udp_client.cpp测试代码。此代码会创建一个UDP客户端，向服务器发送指定大小的包并接收回应。
测试代码的主要步骤如下：
1. 创建UDP套接字。
2. 设置服务器的IP地址和端口。
3. 创建要发送的消息。
4. 发送整个数据包。
5. 接收服务器的回应。
在测试环境中，我们需要一个UDP服务器来接收客户端的请求。这里我们使用Java实现了一个简单的UDPServer。服务端将在指定的端口上，接收数据并回发。
测试方法：在服务端所在的容器内启动服务端程序。然后，在客户端编译代码，分别发送不同大小（如1024、2048、4096、65535）的数据包进行验证。
在测试过程中，我们可能会遇到一些问题。例如，当数据包大小超过典型MTU（最大传输单元）限制时，可能会导致数据包分片。这时，我们会收到一个警告信息，提醒我们数据包大小超过了MTU限制。在某些情况下，如果数据包过大，可能会导致发送失败。
通过tcpdump命令，我们可以抓取网络中的UDP数据包，观察数据包的传输情况。在抓包结果中，我们可以看到客户端发送的数据包和服务器回应的数据包。
根据测试结果，我们发现问题可能由内核版本升级引起。麒麟操作系统官方已经确认这个问题，并计划在后续的内核版本中修复。
对于业务侧发送UDP大包的情况，建议主动进行数据分片。因为UDP本身不提供任何分片机制，它依赖于IP层的分片。如果发送的数据包大小超过网络的MTU，IP层会对其进行分片。如果数据包过大，可能会因为网络限制导致分片包被丢弃。最佳实践是在应用层中将包大小控制在安全范围内，而不是通过UDP发送单个大包。
为了确保UDP通信的顺利进行，我们需要关注数据包的大小，并确保其不超过网络的MTU限制。如果遇到问题，可以通过上述方法进行排查，并采取相应的解决方案。
