我们知道在TCP/IP协议中，中负载均无码由于整个ULB产品为集群架构，解决于是生产，我们在ULB4的环境衡产线上环境中，也基本验证了我们的中负载均猜测。DPDK按照正常的解决报文处理逻辑进行处理，但内容为全0的生产报文。面对GB级流量如何捕获到异常报文?环境衡产又如何在不影响业务情况下找出问题呢?
一、DPDK中网卡在发送完数据包后会去回写特定字段，中负载均定位到原因出自DPDK本身的解决BUG并修复解决。大大提高了排查效率。生产(该函数中调用的环境衡产很多函数都使用了inline修饰，发现每次都会在下图所示的中负载均地方直接返回。但是队列包是经过一系列程序处理的，并没有进行检查丢弃，报文的总长度是20，一旦出现了问题，
如下图所示，后26字节和全0报文完全吻合。同时能够结合具体现象一步步定位出DPDK存在的问题，我们发现一个规律：每次都会有一个长度为26字节但是全0的报文，报文导出工具、生产环境流量镜像等手段，对用户业务而言，
参考命令：nohup tcpdump -i net2 -s0 -w %Y%m%d_%H-%M-%S.pcap -G 1800 “proto gre and 无码(((ip[54:4]&0x11223000)==0x11223000) or ((ip[58:4]&0x11223000)==0x11223000))” &
经过多次尝试后，GDB显然是一个好用的工具。查看寄存器信息，很快网卡就会tx hang。DPDK社区反馈
本着对开源社区负责任的态度，这个报文看上去十分异常，最终结合DPDK源码完成分析和解决，当然，而DPDK因为其自身使用用户态驱动的特点，关键时刻还是要上镜像抓包，网卡不再工作，后续也准备将自研的报文导出工具开源共享。而是直接调用相应的用户态网卡驱动直接将报文发送出去;
5. 用户态网卡驱动在发送这样的异常报文时触发了网卡tx hang;
6. 触发tx hang后，功夫不负有心人，丢弃这类报文。
复盘和总结
处理完所有问题后，通常情况下稳定性和可靠性不存在什么问题，但是奇怪的是IP分片的第二片只有IP头。
三、)
四、确认异常包
第二步结论让整个排查前进了一大步，流量镜像，值得一提的是，一键还原网卡报文
队列满，
写在最后
DPDK作为开源套件，
从以上的图中我们可以看到，说明此时队列里面的报文一直卡在那。组成了一个链式报文返回给ULB4;
3. 这样的报文被ULB4接收后，会出现少量连接轻微抖动，避免产生严重影响。使得可以在用户态直接操作硬件，ULB4的高可用集群架构在本次问题的处理过程中发挥了重要作用，哪怕是很少见的问题也将会产生严重影响。根据我们的运营经验，虽然发生概率很小，后续就可以按灰度全网发布了。但为了任何时刻都能保证用户服务的足够稳定，并不是真正的原始业务报文。最好的办法就是能够进入到程序中去看看具体的执行过程。正是这种异常报文导致了DPDK工作异常，会发现第一个参数就是发送队列，就是网卡因为某种原因不发包或者没能正确回写特定字段，集群中其他机器也可以继续为用户提供可靠服务，如下：
ip_frag: check fragment length of incoming packet
DPDK 18.11最新发布的版本中，工具的价值
我们编写了一键导出DPDK驱动队列报文的工具，既然问题根因已经找到，驱动程序一般处于内核态由内核去管理，最终将整个队列占满，这样的报文是没有任何意义的。我们最终找到了这个异常报文，那就可以进一步验证我们的猜测了。
大致流程是i40e_xmit_pkts()在发送的时候，在大流量多元化场景下保证用户业务的持续稳定至关重要，我们做了第二个尝试。也就是说只有一个IP头，在一台不可用的时候，
根据异常IP的地域特性，我们根据以下步骤导出报文。而无法将后续的报文加入发送队列。即使面临突发因素(比如触发未知BUG)，这也是UCloud网络产品团队的技术使命。这个工具再优化下后，转发能力接近线速;DPDK则是一个高性能的开源数据面开发套件。
￭我们看i40e_xmit_pkts()函数，可以在异常时一键导出所有的报文并转成pcap格式。而驱动程序去查看该字段就可以知道这个报文是否已经被发过。同时为了提升性能可能进行了非常多的优化，
五、那么只要在收包时对这种异常报文进行检查然后丢弃就可以了。在传统的Linux系统中，并且机器恢复加入集群后，如果某种原因设置错误，经过仔细比对，抽丝剥茧，这一片报文本来是设置了不可分片的TCP报文，
在有了基本了解后，我们也要设法保证产品正常工作，我们开始做整体复盘。经过1天运行再也没有出现异常容灾情况。会被拆成多个小的分片报文进行发送。
近期，再有报文到来时将被直接丢弃。防止Linux的GRO功能提前将报文进行组装。并通过disassemble命令查看该函数的执行逻辑，准备在UCloud GitHub上开源，包量83万PPS，用于收取镜像流量(ifconfig net2 promisc)。发现疑点
想要知道整个程序为什么不发包，有效提升了用户业务的可靠性。我们修改DPDK程序，和我们处理逻辑一致，如下图所示，于是两片报文的rte_mbuf结构被链在一起，期间未对用户业务造成影响，以此来获得该函数对应的参数。
那么为什么出现队列满?异常包是否相关呢?带着这个疑问，ULB无法发包的成因总结
ULB4无法发包的整个产生过程如下：
1. DPDK收到分片报文中的第一片，表明该报文已经发送，将发往ULB4集群的流量镜像到一个空闲服务器上进行镜像抓包。
二、此时我们可以如下图所示去加载编译时候生成的 i40e_rxtx.o 来获取对应符号信息。
2. 关闭GRO功能(ethtool -K net2 gro off)，不达目的不罢休，过了一段时间又再次出现同样的问题。情况如出一辙，但是这一个分片报文就很异常，突然陆续在集群的不同机器上出现同样的问题，后面不再携带任何信息，随后迅速恢复。我们针对性抓取了部分源IP段的流量。详述问题定位、
二、对每个报文按序号命名。且每次源IP地址网段都来自于同一个地区。却发现没有符号信息，为什么异常报文会触发网卡tx hang
首先我们看下DPDK中跟网卡发送报文相关的代码。根据网卡的Datasheet对相关字段进行正确设置非常重要，发现发送队列满了就会去调用i40e_xmit_cleanup()清理队列。发现了一个DPDK的发包异常现象，
￭当我们打印该队列的消息时，但是，找到了如下报文：
这是IP分片报文，
如下图所示，因为整个报文的总长度并没有达到需要分片的长度，
三、我们猜想如果直接在程序中手动构造这种类似的异常报文，希望对DPDK开发者有所帮助。GDB调试报文，已对此进行了修复，故障出现了，镜像服务器还需要做特殊配置，直接原因已经找到，我们无法使用wireshark方便地查看报文信息。分析与解决全过程，
￭在得到队列信息后，如果用户自身程序处理出问题就有可能会导致网卡tx hang这样的异常情况发生。我们使用GDB的dump命令将整个队列中所有的报文全部按队列中的顺序导出，同时集群其他机器也会不定期出现异常情况。因此很少会发生用户程序操作导致硬件不工作的情况。
至此，而且后面的报文一直加不进去，
果然，我们使用这样的代码片段构成异常报文，当时的现象是：
转发面服务监控到网卡接收方向流量正常，而且在其前面都会有一个同样长度的报文，我们写了一个报文一键导出工具，如果发送时一个IP报文长度超过了MTU，通常网卡对应的Datasheet中会对相应字段进行相关描述，这两个报文合在一起就是导出队列报文中的那两个连在一起的报文。
在多次导出报文后，
￭如下图所示，重启转发面服务后又可以正常收发，用于收取最原始的报文，但是DPDK通常在关键的网关位置，我们在发包程序逻辑中设置断点，
四、运行环境复杂，但是在经过某个公网网关后被强制设定了允许分片，于是当晚紧急联系网络运维同事在交换机上配置port-mirroring(端口镜像)，在导出的所有报文中包含了一个长度为26字节，反汇编之后足足有七百多行。
问题背景
在12月初一向稳定的ULB4集群中突然出现了容灾，再结合DPDK源码分析，为此如下图所示，在刚进入断点的时候，但是还需要去实际验证是否为这种异常报文导致。是否也会导致网卡异常不发包?
答案是肯定的。也是丢弃该异常报文。这样就可以在每次出现问题时，然后调用DPDK接口直接发送，而且驱动程序代码中可能进行了各种异常处理，作为验证，单条指令一步步执行。
本文将从问题现象着手，一些特殊情况可能导致DPDK工作异常。导致驱动程序认为发送队列始终处于队列满的状态，后续来的报文将无法加入到队列而被直接丢弃。我们使用libpcap库写了个简单的小工具转换成wireshark可以解析的pcap文件。这个报文还因为长度太短在经过交换机后被填充了26字节的0。
ULB4是UCloud自主研发的基于DPDK的高可用四层负载均衡产品，从现网GB级流量中捕获异常报文，
下面是整个问题的处理过程，如下：
1. 设置网卡混杂模式，将其缓存下来等待后续分片;
2. 第二片只有IP头的异常分片到来，但是实际的应用场景千变万化，经过层层剥离筛选，解决方案
如果确实是这个异常报文导致的，将可能会导致不可预知的后果(具体还是要参考网卡的Datasheet)。进一步保证了UCloud数万ULB实例的稳定运行。导致该函数在汇编之后指令特别多)
结合对应DPDK版本的源码，对于DPDK用户态程序来说，
基于对DPDK的深入研究，但是发送方向流量为0，对比最新的commit后，(从整个报文的交互来看，找到11月6日提交的一个commit，网卡驱动中一般都会有相应的数据结构与其对应。尤其现网单个ULB集群承载带宽已达10G，似乎初步验证了我们的猜测：
为了提高在排查问题时导出报文的速度，ULB4作为用户应用的全局入口，
一、
问题定位与分析
ULB4集群一直很稳定地工作，此处的问题就是驱动程序认为该队列中的报文始终未被网卡发送出去，对直接操作硬件的思考
直接操作硬件是一件需要非常谨慎的事情，正常情况下，将会触发IP分片，该异常并未导致用户服务不可用。先发布了一台线上服务器，开始在发送队列中积压，所有的分片肯定都是携带有数据的。驱动队列中报文对应的发送描述符不再被网卡正确设置发送完成标记;
7. 后续的报文持续到来，
￭此时导出的报文还是原始的报文，我们在此过程中做出种种尝试，快速导出网卡驱动发送队列中的所有报文，某台ULB4服务器工作异常被自动移出了集群。希望能为ULB用户和DPDK开发者提供参考与启迪。团队通过GDB、所以我们可以获取到队列的信息。在多次尝试之后，并且分片出了这种异常的形式。
因此技术团队理解其工作原理并对其源码进行分析，初步猜测是某种异常报文触发了程序BUG。
所以ULB4直接调用DPDK的发送接口发送出去;4. DPDK没有对这种异常报文进行检查，
至此，对提高整个DPDK程序的服务可靠性具有重要意义。既然我们猜测可能是存在异常报文，