远程登录一台 VPS 抓包，tcpdump 里出现 64 KB“巨包”，iperf3 却接近 10GbE；换到对端，包长和校验和又恢复正常。矛盾来自 TSO 分段卸载、GSO 聚合卸载、GRO 接收合并和校验和卸载。它们改变报文形态，却不会突破宿主或运营商限速；抓包位置不同，结论就可能相反。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：novoserve（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
传统发送路径会先切出约 1500 字节报文。开启 TSO 后，大块 TCP 数据可交给网卡分段；GSO 范围更广，会形成待继续切分的大报文。因此，在来宾机或虚拟桥抓到 64 KB，不代表公网真出现巨型帧。接收方向相反：GRO 把多个小包合并后再交给协议栈，包数更少、包长更大。
校验和卸载把计算交给下层设备，抓包点可能看到零值或 partial 标志，直到相应卸载层后才成为有效校验和。虚拟环境还叠起来宾机驱动、vhost/tap 与宿主机网卡三层能力，不能只看一个开关。卸载可降低 CPU、软中断和复制开销；全部关闭后速度下降，也不等于线路故障。还要留意方向：发送端的大包是待卸载描述，接收端的合并结果也不能反推每个原始 TCP 段；抓包长度只代表观察层所见，不自动等于线路帧长。
先建立基线：用 ip -br link 确认接口，以 ethtool -k eth0 保存能力与开关状态，并记录 ethtool -S、ip -s link 计数。若用 ServLlama 巡检服务器，可把接口状态纳入变更记录。远程操作应保留第二条 SSH 会话，确认未误选宿主机物理口或错误 netns。
一次只改一个变量。先执行 ethtool -K eth0 tso off，再用 ethtool -k 确认 tso 为 off；随后依次执行 ethtool -K eth0 gso off、ethtool -K eth0 gro off、ethtool -K eth0 tx off 与 ethtool -K eth0 rx off，每项均单独复核。不要一次关闭全部功能，否则无法定位差异。若提示 feature is fixed 或 cannot change，说明驱动不允许调整，应停止并记录。
抓包结果校正不能只靠单端抓包。每改一项，就用同一流量验证：TSO、GSO 同时比较发送端大包与对端实际分段；GRO 检查入站包数和长度；校验和以接收端或物理出口抓包为准。测速固定 iperf3 时长、并发流和端点，至少重复三次并记录 CPU。回环只能验证本机路径，应加入经过网关或公网的对照。若关闭某项后吞吐突降，先看 CPU 是否饱和、队列是否积压，再判断卸载影响，不能立即归因于线路。
结束后按基线逐项恢复，再用 ethtool -k 复核。多数 ethtool 修改仅在当前运行期生效，重启可能回到驱动默认；若持久化配置被改写，还要撤销对应条目。变更窗口不要同时重启网络服务或升级内核，否则无法区分驱动重置与开关效果。常见坑是只抓来宾机、把虚拟大包当真实帧，或只跑一次测速。卸载改变的是报文由谁处理，不会凭空增加物理带宽，结论必须绑定接口、方向和抓包位置。
网卡执行 TSO分段卸载 时，内核先构造大报文，并把分段信息写入元数据；真正上网卡前，硬件才按 MTU 切成多个 TCP 段。因此，协议栈出口抓到的可能是一个超大包。接收方向相反，GRO接收合并 会把同一流的连续小包临时合并，抓包工具可能看到大包，邻居主机收到的却仍是原始分段。要核对线上真实形态，应在网卡前后分别采样，或关闭相应卸载后做对照。
GSO聚合卸载 由软件为网卡准备大报文，再依据协议分段；TSO 通常由硬件完成 TCP 分段，二者并非同一开关。校验和卸载 则把 TCP、UDP 及部分 IP 校验和延后计算，所以应用侧或协议栈侧抓包可能显示校验和为零、异常，甚至不存在完整 IP 头。这通常反映抓包位置，而非线路损坏。判断异常时应同时核对 ethtool 状态、MTU、驱动版本、虚拟化后端和抓包点，不能只凭 Wireshark 画面下结论。
最容易踩的坑，是把 TSO、GSO、GRO 当成链路聚合或交换机功能；它们不会合并独立连接，也不会增加物理带宽。另一个坑是直接执行 ethtool -K eth0 gro off，忽略 virtio 后端、云平台和驱动可能不支持；有时命令返回成功，重新启用后故障仍在，某些队列还会出现丢包。关闭卸载应作为对照试验，而非默认修复。
检查清单可按顺序执行：①用 ip -br link 与 ip link show dev eth0 确认接口、MTU 和状态；②用 ethtool -k eth0 记录 tx-checksumming、tso、gso、gro 开关；③用 ethtool -S eth0 查看错误、丢包及丢弃计数；④在协议栈侧与物理网卡侧同时抓包，比较包长、方向和校验和；⑤仅对可疑开关做一次关闭对照，随后恢复原值，并复测吞吐、softnet backlog、CPU 占用和业务时延。测试前保存基线，命令失败时先核对驱动与权限，不要盲目修改。
结论上，卸载开启并不等于网络异常，抓包显示的大包或零校验和也不能单独作为故障证据。应把链路状态、驱动能力、计数器变化和业务表现交叉验证；只有问题随某项卸载切换而稳定复现，才将其作为临时规避，并优先评估驱动升级或平台侧修复。
