LVS LD启用GRO导致用户访问业务出现卡顿

在某分公司机房部署并启用了一个业务集群，总部和分公司的架构都是Client--LVS--Svr集群。

但用户反馈，访问分公司的业务时，有1-2s的卡顿感。

用wireshark抓包，看到有“ICMP Destination unreachable (Fragmentation needed)”，如下图No.48、No.57、No.58：

这就奇怪了，上周因为其他问题，已经让网络组同事把FW的TCP MSS值改为1400了。

理论上协商出来的数据分片大小是1400，就算加上TCP/IP包头和LVS封装的20字节IPIP包头，也不会超过MTU的，为啥会提示分片呢？

注解：MSS最大传输大小的缩写，是TCP协议里面的一个概念。MSS就是TCP数据包每次能够传输的最大数据分段。为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以往往MSS为1460。通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。

接下来怎么办？TroubleShooting思路很关键：收敛范围

1、Client访问总部&分公司，两个场景都抓包，确认只有分公司出现“Fragmentation needed”？——是的

2、总部和分公司的配置，架构是否一样？——访问路径都是Client--FW--LVS--Svr集群--FW--Client，2套LVS架构不同，但工作模式、算法应该是一样的

3、Client端抓包结果有了，去LVS抓包看看？——也看到“Fragmentation needed”

4、绕过LVS，Client直接访问业务，是否ok？——不经过LVS的访问是正常的！排查范围迅速收敛到LVS

5、总部和分公司的LVS有啥区别？——问题根源找到了：内核不一样！！！总部是SUSE、分公司是CentOS

6、如果第5步没有发现区别，就计划在FW前后抓包对比（……之前一直怀疑是FW的问题）

大牛在分析抓包文件时，找出了端倪：tcp offload

查阅资料，问题出在这个generic-receive-offload的开关。

offload特性是是为了提升网络收/发性能。TSO、UFO和GSO是对应网络发送，在接收方向上对应的是LRO、GRO。

TSO(TCP Segmentation Offload)，是一种利用网卡对TCP数据包分片，减轻CPU负荷的一种技术，有时也被叫做 LSO (Large segment offload) ，TSO是针对TCP的，UFO是针对UDP的。如果硬件支持 TSO功能，同时也需要硬件支持的TCP校验计算和分散/聚集 (Scatter Gather) 功能。

GSO(Generic Segmentation Offload)，它比TSO更通用，基本思想就是尽可能的推迟数据分片直至发送到网卡驱动之前，此时会检查网卡是否支持分片功能（如TSO、UFO）,如果支持直接发送到网卡，如果不支持就进行分片后再发往网卡。这样大数据包只需走一次协议栈，而不是被分割成几个数据包分别走，这就提高了效率。

LRO(Large Receive Offload)，通过将接收到的多个TCP数据聚合成一个大的数据包，然后传递给网络协议栈处理，以减少上层协议栈处理 开销，提高系统接收TCP数据包的能力。

GRO(Generic Receive Offload)，基本思想跟LRO类似，克服了LRO的一些缺点，更通用。后续的驱动都使用GRO的接口，而不是LRO。

RSS(Receive Side Scaling)，是一项网卡的新特性，俗称多队列。具备多个RSS队列的网卡，可以将不同的网络流分成不同的队列，再分别将这些队列分配到多个CPU核心上进行处理，从而将负荷分散，充分利用多核处理器的能力。

——上述offload特性介绍，引自这里

关闭GRO抓包观察，果然不再出现“ICMP Destination unreachable (Fragmentation needed)”，结单。