Windows 网卡高级设置指南 - RSS/LSO/EEE/Wake on LAN

Windows 网卡的 [高级] 选项卡 上，排列着一堆不太眼熟的字眼。 Jumbo Packet、Large Send Offload、Interrupt Moderation、Receive Side Scaling、Flow Control、Energy Efficient Ethernet。光看名字会想把它们全部打开，但实际上 要优先什么，正确答案就不一样。

• 是想提升大流量传输的吞吐量
• 是想压低小数据包的延迟
• 是想降低 CPU 使用率
• 是想让睡眠唤醒和 Wake on LAN 更稳定
• 还是想排查与驱动程序或交换机的兼容性问题

这一层还没想清楚就去做“总之全部打开”“总之 Jumbo 上 9014”“慢就固定成 1Gbps 全双工”，出事的概率相当高。

flowchart TB
    accTitle: 目的不清楚就动手容易出事
    accDescr: 在没想清楚要优先什么的情况下，先把所有项目都打开、启用 Jumbo 或固定速度，都容易出事；而先决定要优先什么之后，正确答案会随之改变的示意图。
    vague1["要优先什么还不清楚"] --> hasty1["总之全部打开、Jumbo、固定"]
    hasty1 --> acc1["相当容易出事"]
    clear1["先决定要优先什么"] -->|"正确答案随之改变"| pick3["该动的设置就能收窄"]

图1：不定目的就去碰看起来很强的设置容易出事，定好目的就能收窄该动的地方。

本文主要针对 Windows 10 / 11 / Windows Server 的有线 Ethernet 网卡，梳理在实务中调整网卡高级设置时的思路。 把每项设置的含义、把值调高／调低／启用／关闭后容易发生什么、在什么场景下才该动它，整理成可以一次通览的内容。

另外，网卡的显示名称和可选值 会因厂商和驱动程序而有相当大的差异。 Jumbo Packet 有时叫 Jumbo Frames，Receive Buffers 有时叫 Receive Descriptors，Priority & VLAN 有时叫 Packet Priority & VLAN。本文会把含义相近的项目归到一起讨论。

本文的使用方法

全文共 14 章，篇幅不短，所以先把导览放在前面。不需要全部读完。

我想最常见的读法应该是“从症状入手，第 11 章 → 对应设置的章节 → 第 10 章改回去”。

flowchart TB
    accTitle: 最常见的阅读导览
    accDescr: 从症状入手，先看第 11 章的按症状排查要点，再到对应设置的章节确认含义，最后用第 10 章的按目的指引改回去的阅读导览示意图。
    sym1["从症状入手"] --> ch11["第 11 章（按症状的排查要点）"]
    ch11 --> chd1["对应设置的章节（第 5～9 章）"]
    chd1 --> ch10["第 10 章（用按目的的指引改回去）"]

图2：从症状进入第 11 章，经过对应设置的章节，再用第 10 章的指引改回去，是典型的动线。

缩略语小词表

为了方便对照设置界面阅读，先把本文出现的缩略语汇总在这里。

1. 先说结论

先把实务上不容易出错的结论放在前面。

• Speed & Duplex 原则上用 Auto。遇到降到 100Mbps 的问题时，一上来就固定成 1.0 Gbps Full Duplex 是最后的手段。
• Checksum Offload / RSS / LSO / RSC 原则上保持启用或默认值。随意全部关掉容易白白消耗 CPU。
• Jumbo Packet 只在端到端全部对齐时才用。只把网卡设成 9014，中途路径还是 1500，就是个陷阱。
• Interrupt Moderation 是吞吐量与延迟之间的拉锯。调高后 CPU 会轻松，但延迟会增加。
• Flow Control 有时能往减少丢包的方向起作用，但也可能把拥塞扩散开。
• EEE / Green Ethernet / Selective Suspend 是为省电而设的项目，不是让速度变快的设置。
• VMQ / SR-IOV 是面向 Hyper-V 主机的，不是让普通台式机变快的魔法。
• Wake on Pattern Match 很容易成为非预期唤醒的原因，所以只是想要 Wake on LAN 的话，靠 Magic Packet 更安全。
• TCP Chimney Offload 之类的老项目现在最好别碰。

简单说，网卡的高级设置不是“把看起来很强的项目全部打开”的地方。 而是 先决定要拿吞吐量、延迟、CPU、功耗、兼容性中的哪一个，再一项一项去动的地方。

flowchart TB
    accTitle: 高级设置选项卡的定位
    accDescr: 网卡的高级设置不是把看起来很强的项目全部打开的地方，而是先决定要拿吞吐量、延迟、CPU、功耗、兼容性中的哪一个，再一项一项去动的地方的示意图。
    allon1["把看起来很强的全部打开"] -.->|"这里不是这种地方"| tab1["网卡的高级设置"]
    dec1["决定要取哪个维度"] --> one2["一项一项去动"]
    one2 --> tab1

图3：高级设置选项卡要当成先定好想取的维度、再一项一项去动的地方来用。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 26 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 在哪里查看设置

2.1 从 GUI 查看

从网络连接进入

1. 运行 ncpa.cpl
2. 右键点击目标网卡
3. 属性 → 配置
4. 高级 (Advanced) 选项卡

从设备管理器进入

1. 设备管理器
2. 网络适配器
3. 右键点击目标网卡 → 属性
4. 高级 选项卡

这里列出的项目，就是本文的主角。 不过 电源管理选项卡里的设置 在实务上影响也不小，后半部分会讲到。

2.2 用 PowerShell 查看

用 PowerShell 更容易一次列出当前值，也方便在变更前做备份。

Get-NetAdapter

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Sort-Object DisplayName |
  Format-Table DisplayName, DisplayValue, RegistryKeyword, RegistryValue -Auto

有些网卡的 RegistryKeyword 会是标准化的名称，可以看到 *RSS、*VMQ、*SRIOV、*EEE 这样的写法。 但是，DisplayName 与 DisplayValue 取决于驱动程序。要写变更脚本时，先在真机上列一遍会更安全。

flowchart TB
    accTitle: 用 PowerShell 确认时的顺序
    accDescr: 在写变更脚本之前，先认识到 DisplayName 和 DisplayValue 取决于驱动程序，因此要先在真机上列出清单再写脚本这一安全顺序的示意图。
    lst1["在真机上列出清单"] --> dep1["确认显示名取决于驱动程序"]
    dep1 --> scr1["然后再写变更脚本"]
    scr1 -.-> bk1["同时保留变更前的备份"]

图4：显示名取决于驱动程序，所以先看真机上的清单再写脚本。

3. 动手之前的大原则

调整网卡设置之前，这里要是没做好，多半会陷入泥潭。

3.1 先确定“想改善什么”

同样是一句“网络很慢”，实际内容可能完全不同。

• 大文件复制慢 → 吞吐量、RSS、RSC、LSO、Jumbo、缓冲区
• 小的 request/response 卡顿 → Interrupt Moderation、RSC、EEE、队列深度
• CPU 高 → offload、RSS、RSC、中断
• 睡眠唤醒之后不正常 → Selective Suspend、电源管理、WoL
• 偶尔断线／降到 100Mbps → 网线、对端设备、Speed & Duplex、EEE、驱动程序

目的不同却去动同样的设置，别说改善，反而会恶化。

flowchart TB
    accTitle: 先把“慢”的内容分开
    accDescr: 同样是网络很慢这一症状，实际内容完全不同，必须先确定想改善什么再去动对应的那组设置，否则别说改善反而会恶化的示意图。
    slow1["网络很慢"] --> split1["先把内容分开"]
    split1 --> aim1["只动符合目的的那组设置"]
    slow1 -.->|"不分开就动手"| worse1["别说改善反而恶化"]

图5：不先把症状的内容分开就动手，同样是“慢”也会产生反效果。

3.2 先怀疑物理层与对端设备

有些问题本来就不是网卡设置能修好的。

• 网线不良
• 交换机／路由器／扩展坞的兼容性
• 陈旧的固件
• USB 网卡供电不足
• 端口侧的错误
• 丢包或重传

特别是 降到 100Mbps、链路频繁抖动、只有大流量传输才出问题 这几类，先看物理和对端会更快。

flowchart TB
    accTitle: 先看物理层与对端设备
    accDescr: 出现降到 100Mbps、链路频繁抖动、只有大流量传输才出问题这类症状时，比起网卡设置，先怀疑网线和对端设备等物理层会更快的示意图。
    symp1["降速、抖动等症状"] --> phys1["先看网线、对端设备、物理层"]
    phys1 -->|"仍然存在"| nicw1["再去排查网卡设置"]
    phys1 -.-> nofix1["有些问题本来就不是设置能修好的"]

图6：链路类症状先怀疑物理层和对端设备，比先动设置更快。

3.3 一次只改一项

Jumbo、LSO、RSC、RSS、EEE 一口气全改，最后就分不清是哪一项起了作用。 先把变更前的设置导出来，一次只改一项，再测量变化，这是基本做法。

3.4 确定要测量什么

至少下面这些是想看到的。

• 连接速度（1G / 2.5G / 10G 等）
• 吞吐量
• 延迟
• CPU 使用率
• 网卡统计（丢包／错误／缓冲区不足）
• 睡眠唤醒的稳定性

设置变更不能只看主观感受，用数据来看更有说服力。

flowchart TB
    accTitle: 一项一项改并用数据对比
    accDescr: 先导出变更前的设置，只改一项，测量事先定好的指标，再用数据而不是主观感受来对比，这一设置变更基本流程的示意图。
    w1["导出变更前的设置"] --> w2["只改一项"]
    w2 --> w3["测量定好的指标"]
    w3 --> w4["用数据而不是感觉来对比"]

图7：改动一次只动一项，前后用数据对比，是基本套路。

4. 主要设置一览表

先放一张能一眼看完每项设置作用的表。

5. 链路与帧大小相关的设置

5.1 Speed & Duplex

这是关于 连接速度与全双工／半双工协商 的设置。显示名称有 Speed & Duplex、Link Speed、Link Speed & Duplex 等。

这项设置在做什么

在 Ethernet 中，网卡和对端设备会决定以什么速度、什么双工模式通信。

• Auto Negotiation
• 100 Mbps Full Duplex
• 1.0 Gbps Full Duplex
• 2.5 Gbps Full Duplex
• 10 Gbps Full Duplex

常见的就是这类选项。

改了会怎样

设为 Auto

• 在现代设备之间，原则上这样最稳定
• 1000BASE-T 以上的场景，很多时候以 Auto 为前提
• 也更容易与 EEE、master/slave 的协商保持一致

手动固定

• 对于旧交换机或对端被强制固定的设备，有时能改善兼容性
• 但是，只有一侧固定／只有一侧 Auto 这种状态是故障之源
• 一旦造成 duplex mismatch，就会引起降速、重传和异常延迟

实务上的基本方针

通常保持 Auto 就可以。 “跑不到 1Gbps 就固定成 1.0 Gbps Full Duplex”看起来很有气势，实际上多半没抓住要点。

flowchart TB
    accTitle: 单侧固定引发的 duplex mismatch
    accDescr: 只有一侧固定、另一侧 Auto 的状态会造成 duplex mismatch，引起降速、重传和异常延迟，因此现代设备之间原则上两侧都用 Auto 最稳定的示意图。
    mix1["只有一侧固定、只有一侧 Auto"] --> mm1["duplex mismatch"]
    mm1 --> sl2["降速、重传、异常延迟"]
    auto1["两侧都用 Auto"] -->|"现代设备之间"| stb1["原则上这样最稳定"]

图8：固定与 Auto 混在一起会造成 duplex mismatch，所以通常两侧都设成 Auto。

5.2 Jumbo Packet / Jumbo Frames

这是 使用比标准更大的 Ethernet 帧 的设置。显示名称有 Jumbo Packet、Jumbo Frames、Jumbo Packet Size 等。

这项设置在做什么

一般的 Ethernet 大多以 MTU 1500 为前提工作。启用 Jumbo Frame 之后，就可以使用 9000 字节左右 的大帧。

不过，这里名称的陷阱很多。

• 驱动程序有时会像 9014 Bytes 那样显示 帧大小
• 操作系统或工具有时会像 MTU 9000 那样以 L3 视角 来看
• 交换机有时 把 CRC 或 VLAN 标签也算进去

只把数字并排比较，踩坑的概率相当高。

flowchart TB
    accTitle: Jumbo 数字的计数方式差异
    accDescr: 同样是 Jumbo 设置，驱动程序按帧大小、操作系统和工具按 L3 视角的 MTU、交换机把 CRC 和 VLAN 标签也算进去来计数，只把数字并排比较就会踩坑的示意图。
    drv1["驱动程序：显示帧大小"] --> cmp2["同一个东西用不同方式在数"]
    osv1["操作系统、工具：MTU 的 L3 视角"] --> cmp2
    sw1["交换机：连标签和 CRC 一起算"] --> cmp2
    cmp2 --> trap1["只把数字并排比较就会踩坑"]

图9：驱动程序、操作系统、交换机的计数方式不同，所以 Jumbo 的数字不要并排比较。

改了会怎样

调大／启用

• 发送大数据时数据包数量减少
• 包头处理次数减少
• CPU 使用率容易下降
• 另一方面，单个数据包的占用时间会变长
• 路径上任何一处不支持，都会成为丢包或分片的原因

改回标准／关闭

• 兼容性最高
• 数据包数量增加
• 大流量传输时 CPU 与包头开销容易增加

实务上的基本方针

Jumbo 只有 端到端 全部对齐才有意义。

• 自己的网卡
• 对端的网卡
• 中途的交换机
• 如果要经过 VLAN 或虚拟交换机，还要算上它的开销

只要其中任何一环还是 1500，不但没有效果，反而会成为故障之源。

flowchart TB
    accTitle: Jumbo 端到端对齐才有意义
    accDescr: Jumbo Frame 要从自己的网卡、中途的交换机一直到对端的网卡端到端全部对齐才有意义，只要其中一环还是 1500，不但没效果反而会成为故障之源的示意图。
    myn1["自己的网卡"] --> mid1["中途的交换机"]
    mid1 --> yrn1["对端的网卡"]
    yrn1 --> okj1["全部对齐才有意义"]
    mid1 -.->|"其中一环还是 1500"| ngj1["没有效果、还成为故障之源"]

图10：Jumbo 以路径上所有环节都对齐为前提，只要有一处还是 1500 就会适得其反。

5.3 Gigabit Master / Slave Mode

这是 1000BASE-T 中，关于 哪一侧作为 master、哪一侧作为 slave 来主导时钟 的设置。普通 PC 基本不会去动它。

基本方针

• 原则上用 Auto
• 只在与特定旧对端设备出现链路质量问题时才评估
• 除非有厂商指示，否则不要把它当成性能调优的旋钮

5.4 Wait for Link 等链路状态类设置

Wait for Link 这类设置关系到 驱动程序是否要等自动协商成功之后再报告链路状态。 Log Link State Event 则是把链路 up/down 记录到事件日志，用于诊断。

基本方针

• 普通 PC 保持默认值即可
• 与其说影响性能本身，不如说影响开机时的显示和故障切换的诊断
• 不是优先要动的项目

6. 影响 CPU 负载、吞吐量、延迟的设置

这一带看起来“最容易见效”。实际上确实经常见效，但见效的方向分得很清楚。

flowchart TB
    accTitle: 这一带的设置见效方向会分开
    accDescr: 影响 CPU 负载、吞吐量、延迟的这组设置，会清楚地分成合并处理以换取吞吐量和 CPU 的方向，以及细粒度处理以换取延迟的方向的示意图。
    band1["看起来容易见效的一带设置"] --> dir1["合并处理的方向"]
    band1 --> dir2["细粒度处理的方向"]
    dir1 -.-> g1["对吞吐量、CPU 有利"]
    dir2 -.-> g2["对延迟有利"]

图11：即使是同一带的设置，偏吞吐量和偏延迟的见效方向也不一样。

6.1 Checksum Offload

把 IP / TCP / UDP 的 checksum 计算交给网卡的设置。

基本方针

• 原则上启用
• 想降低 CPU 就保留它
• 抓包上看到的 checksum error，多半是 offload 造成的表面现象
• 为排查兼容性而临时关闭是可以的

6.2 Large Send Offload (LSO) / TSO / Offload TCP Segmentation

由网卡把较大的 TCP 发送数据切分成小帧的设置。

对什么有效

• 发送密集型的吞吐量
• 降低 CPU 使用率
• 较大的连续发送

基本方针

• 通常 启用
• 怀疑特定应用或驱动程序兼容性时，临时关闭看差异

6.3 Receive Segment Coalescing (RSC) / Large Receive Offload

在接收侧把多个 TCP 分段合并起来的设置。

对什么有效

• 接收侧的吞吐量
• 降低 CPU 使用率

注意事项

• 在低延迟场景或以数据包为单位观测时可能不利
• 抓包和时序观测的解读会略有变化

基本方针

• 想要接收吞吐量就启用
• 想看小 request/response 的延迟时列为评估对象

flowchart TB
    accTitle: RSC 的作用方式与评估分界
    accDescr: RSC 在网卡侧把接收到的多个 TCP 分段合并起来，对接收吞吐量和降低 CPU 有效，但在低延迟场景或以数据包为单位观测时可能不利，因而成为评估对象的示意图。
    seg1["接收到的多个 TCP 分段"] --> coal1["在网卡侧合并（RSC）"]
    coal1 --> up1["对接收吞吐量、CPU 有效"]
    coal1 -.->|"以低延迟、观测为优先时"| dn1["可能不利，成为评估对象"]

图12：RSC 是把接收合并起来处理的设置，如果想要的是延迟那一侧，它就成为评估对象。

6.4 UDP 方面较新的 offload（USO / URO）

在较新的网卡和操作系统上，UDP 的收发也可能出现较新的 offload 项目。

基本方针

• 即使出现了，也先不要偏离默认值
• 只在驱动程序足够新、目标 workload 明确时才去测
• 排查故障时不要硬去动它

6.5 Receive Side Scaling (RSS)

把接收处理分散到多个 CPU 的设置。在多核环境下相当重要。

基本方针

• 多核环境原则上启用
• 出现单个 CPU 被占满的症状时，先确认这里
• 在 Hyper-V 或高吞吐场景的前置环节，它也容易成为主角

flowchart TB
    accTitle: 有无 RSS 时接收处理的差别
    accDescr: 关闭 RSS 时接收处理集中在单个 CPU 上容易堵住，启用后会分散到多个 CPU，在多核环境下吞吐量容易提升的示意图。
    rin1["接收流量"] -->|"RSS 关闭"| one3["集中在单个 CPU 上容易堵住"]
    rin1 -->|"RSS 启用"| sp2["分散到多个 CPU"]
    sp2 --> sc1["多核环境下容易提升"]

图13：RSS 是把接收处理分散到多个 CPU 的机制，遇到单个 CPU 被占满的症状先确认它。

6.6 RSS Queues / RSS Processors / RSS Profile

决定 RSS 并行度的项目。

基本方针

• 从默认值开始
• 等看到 CPU 使用率或队列偏斜之后再增加
• 无端拉到最大，中断和 DPC 负载有时反而会增加

6.7 Interrupt Moderation / Interrupt Moderation Rate

抑制中断频率、用 CPU 负载换延迟的设置。

倾向

• 调高／Adaptive → CPU 容易轻松，但延迟容易增加
• 调低／Off → 延迟容易下降，但 CPU / DPC 负载容易上升

基本方针

• 以默认值 / Adaptive 为起点
• 在意小数据包的 jitter 就评估 Low / Off
• 大流量传输时，多半保持默认值更自然

flowchart TB
    accTitle: Interrupt Moderation 的拉锯
    accDescr: 把 Interrupt Moderation 调高或设为 Adaptive 时 CPU 会轻松但延迟容易增加，调低或设为 Off 时延迟会下降但 CPU 和 DPC 负载容易上升的拉锯示意图。
    im1["Interrupt Moderation"] -->|"调高 / Adaptive"| cpuok["CPU 容易轻松"]
    cpuok -.-> lat1["延迟容易增加"]
    im1 -->|"调低 / Off"| latok["延迟容易下降"]
    latok -.-> cpu2["CPU / DPC 负载容易上升"]

图14：抑制中断频率是 CPU 与延迟的交换，以默认值或 Adaptive 为起点来评估。

6.8 Receive Buffers / Receive Descriptors 与 Transmit Buffers / Transmit Descriptors

改变 ring / buffer 深度的设置。

见效方向

• 突发耐受度
• 持续吞吐量
• 避免丢包

副作用

• 内存占用增加
• 队列变深，排队延迟有时会增加

基本方针

• 只在已经看到丢包或缓冲区不足时才增加
• 避免无端拉到最大

flowchart TB
    accTitle: 缓冲区该在什么时候加深
    accDescr: 加深缓冲区对突发耐受度和避免丢包有效，但内存占用会增加、排队延迟也可能增加，因此只在已经看到丢包或缓冲区不足时才增加这一判断的示意图。
    obs1["已经看到丢包或缓冲区不足"] -->|"只在看到时"| inc1["增加缓冲区"]
    inc1 -.-> side1["内存占用和排队延迟可能增加"]
    non1["无端拉到最大"] -.->|"要避免"| inc1

图15：缓冲区只在症状已经用数据显现时才增加，避免无端拉到最大。

6.9 Flow Control

关于 802.3x pause frame 收发的设置。

基本方针

• 想减少丢包时它是候选项
• 但 pause 有时会把另一处的拥塞扩散开
• 在低延迟场景要谨慎看待
• 要和整体网络设计一起考虑

flowchart TB
    accTitle: Flow Control 的两面性
    accDescr: Flow Control 的 pause frame 有时能往减少丢包的方向起作用，但 pause 也可能把另一处的拥塞扩散开，因此必须与整体网络设计一起考虑的示意图。
    fc1["pause frame（Flow Control）"] -->|"有时会见效"| less1["往减少丢包的方向"]
    fc1 -.->|"也可能扩散"| cong1["另一处的拥塞"]
    fc1 --> tot1["与整体网络设计一起判断"]

图16：Flow Control 一方面减少丢包，一方面也可能扩散拥塞，不能单独判断。

7. VLAN、QoS、虚拟化相关的设置

7.1 Priority & VLAN / Packet Priority & VLAN / NDIS QoS

处理 802.1Q VLAN 和 802.1p Priority 的一带。

基本方针

• 只在真的要用 VLAN / QoS 时才需要留意
• 单纯的 access port 环境保持默认值即可
• 会自动加上标签的配置会让排查变难，要注意

7.2 VMQ / VMMQ / SR-IOV

这是在 Hyper-V 主机或虚拟化平台 上才有意义的设置。

基本方针

• 不要当成普通台式机的调优手段
• 如果是 Hyper-V 主机，要连同 vSwitch 配置、队列分配、来宾侧设置一起评估
• 只看单侧很难得出正确答案

flowchart TB
    accTitle: VMQ / SR-IOV 的评估单位
    accDescr: VMQ 和 SR-IOV 是在 Hyper-V 主机或虚拟化平台上才有意义的设置，必须连同 vSwitch 配置、队列分配、来宾侧设置一起评估，只看单侧很难得出正确答案的示意图。
    vm1["VMQ / VMMQ / SR-IOV"] --> hv1["在 Hyper-V 主机上才有意义"]
    hv1 --> setb["与 vSwitch、队列、来宾侧一体评估"]
    vm1 -.->|"不作为对象"| dt1["普通的台式机调优"]

图17：虚拟化类设置要把主机、vSwitch、来宾放在一起看，才谈得上评估。

7.3 RDMA / DCB / PFC 是另一个世界

这一带包含 SMB Direct 和无损 Ethernet，是相当独立的另一个世界。

基本方针

• 要与普通的 1GbE / 2.5GbE 台式机调优分开考虑
• 要结合厂商资料和交换机侧的设计一起确认

8. 省电、睡眠、Wake on LAN 相关的设置

8.1 Energy Efficient Ethernet (EEE) / Green Ethernet

为了省电，在链路空闲时降低功耗的设置。

怎么看它

• 不是让速度变快的设置
• 对功耗确实有效
• 视对端设备和线材条件，它可能成为链路不稳定或降到 100Mbps 的排查候选

基本方针

• 一般用途保持默认值也可以
• 遇到链路不稳定、降到 100Mbps、以低延迟为重时，先把它列为排查候选

flowchart TB
    accTitle: EEE 的定位
    accDescr: EEE 是在链路空闲时降低功耗的省电设置，不是让速度变快的设置，视对端设备和线材条件可能成为链路不稳定或降到 100Mbps 的排查候选的示意图。
    eee1["EEE / Green Ethernet"] --> sv3["降低空闲时的功耗"]
    eee1 -.->|"不是让速度变快的设置"| spd1["速度、性能"]
    eee1 -.->|"取决于对端和线材条件"| tgl1["链路不稳定、降速的排查候选"]

图18：EEE 是省电设置，遇到链路不稳定或降到 100Mbps 时先把它列为排查候选。

8.2 Selective Suspend / Device Sleep / Standby 时的链路控制

说白了，就是 空闲或睡眠时网卡要睡到多深 的设置。

基本方针

• 笔记本从默认值开始
• 有唤醒问题时最先怀疑它
• 设备控制 PC 或 7×24 运行的场景，反而关掉更容易看清行为

8.3 Wake on Magic Packet / Wake on Pattern Match

这是通过网络唤醒睡眠中的 PC 的设置。

基本方针

• 需要 Wake on LAN 就启用 Magic Packet
• 不需要就关闭
• Pattern Match 只在必要性明确时才开

只把网卡这边打开却唤不醒的情况很常见。要把 BIOS / UEFI 侧和电源管理选项卡侧也一起对齐来看。

flowchart TB
    accTitle: Wake on LAN 生效的条件
    accDescr: Wake on LAN 不只取决于网卡的 Magic Packet 设置，还要 BIOS 或 UEFI 侧和电源管理选项卡侧都对齐才会唤醒，因此需要把三处一起确认的示意图。
    m1["网卡的 Magic Packet 设置"] --> wol1["Wake on LAN 生效"]
    m2["BIOS / UEFI 侧的设置"] --> wol1
    m3["电源管理选项卡侧"] --> wol1
    wol1 -.-> pt2["Pattern Match 容易成为误唤醒之源"]

图19：WoL 要网卡、BIOS/UEFI、电源管理选项卡三处都对齐才会生效。

8.4 ARP Offload / NS Offload

让网卡在睡眠期间代为做最低限度响应的设置。

基本方针

• 通常 启用／默认值 即可
• 在排查睡眠相关兼容性问题时常会临时动它

8.5 电源管理选项卡里的设置

除了高级选项卡之外，网卡属性里还有 电源管理 选项卡。这里看着不起眼，其实很重要。

常见的是下面 3 项。

• 允许计算机关闭此设备以节约电源
• 允许此设备唤醒计算机
• 只允许幻数据包唤醒计算机

基本方针

• 唤醒不良时，先怀疑 允许计算机关闭此设备…
• 想避免误唤醒就启用 只允许幻数据包…
• 如果根本不需要 Wake on LAN，唤醒相关的项目全部关闭即可

flowchart TB
    accTitle: 电源管理选项卡的看法
    accDescr: 唤醒不良时先怀疑允许关闭设备电源的设置，想避免误唤醒就启用只用幻数据包唤醒的设置，根本不需要 Wake on LAN 时就把唤醒相关项目全部关闭这一判断的示意图。
    q4["困扰的是什么"] -->|"唤醒不良"| a1["先怀疑允许关闭电源的设置"]
    q4 -->|"想避免误唤醒"| a2["只用幻数据包唤醒的设置"]
    q4 -->|"根本不需要 WoL"| a3["唤醒相关项目全部关闭"]

图20：电源管理选项卡按困扰的类型不同，最先该动的地方也就定下来了。

9. 其他常见但很少有机会动的设置

9.1 Network Address / Locally Administered Address

手动覆盖 MAC 地址 的设置。

基本方针

• 平时不去动
• 不是性能设置
• 只在实验环境或特殊需求下使用

9.2 Adaptive Inter-Frame Spacing

相当资深的老设置。在现代的交换式全双工 Ethernet 上不是主角。

基本方针

• 在现代的普通局域网中保持默认值
• 只在旧设备或特殊环境下有厂商指示时才动

9.3 Header Data Split

主要面向服务器，通过把数据包包头与负载分开处理来减轻 CPU 负担的这类设置。

基本方针

• 面向服务器／面向特定 workload
• 普通客户端保持默认值

9.4 Low Latency Interrupts

有些厂商会提供 Low Latency Interrupts 这样的项目。

基本方针

• 只在测量之后确实有效时才用
• 不是靠感觉打开的那一带

9.5 TCP Chimney Offload / IPsec Task Offload 等老项目

在较老的网卡或驱动程序上，还能看到这类项目。

基本方针

• 现在不碰、不用 才是正解
• 不要被兼容性说法或旧资料带偏

flowchart TB
    accTitle: 第 9 章各项目的共同立场
    accDescr: 覆盖 MAC 地址、资深的老设置、面向服务器的设置和老的 offload 项目，平时都保持默认值不去动，只在有厂商指示或明确需求并且能测量时才动这一共同立场的示意图。
    rare1["第 9 章列出的这些项目"] --> keep1["平时保持默认值不去动"]
    keep1 -->|"要动的时候是"| cond1["有厂商指示、有明确需求时"]
    cond1 -.-> meas1["只在测量之后确实有效时才用"]

图21：即使看到了平时也不去动，只有在有明确指示或需求并且做过测量时才出手。

10. 按目的的粗略指引

下面会多次出现“评估关闭”“关闭候选”这样的写法。它的意思不是“把它关掉”，而是 把它列为评估对象。内容就是 3.3 和 3.4 的大原则本身，具体来说是这 4 步。

1. 保存变更前的设置（12.1 的 Export-Csv）
2. 只关闭 1 项（3.3）
3. 测量 3.4 中定好的指标（吞吐量、延迟、CPU、网卡统计、唤醒的稳定性）
4. 没有效果就改回去

漏掉第 4 步，没有意义的变更就会越堆越多，下一次排查也会更难。下面的各项，请当成循环这 4 步的候选清单来读。

flowchart TB
    accTitle: 评估关闭的 4 步
    accDescr: 保存变更前的设置、只关闭 1 项、测量定好的指标、没有效果就改回去，这一评估关闭的 4 步循环的示意图。
    h1["保存变更前的设置"] --> h2["只关闭 1 项"]
    h2 --> h3["测量定好的指标"]
    h3 -->|"没有效果就"| h4["改回去"]
    h4 -.->|"进入下一个候选"| h2

图22：“评估关闭”不是让你关掉它，而是循环这 4 步并做测量。

10.1 普通的台式机／笔记本

• Speed & Duplex：Auto
• MTU / Jumbo：1500 / 关闭
• Checksum Offload：启用
• LSO：启用
• RSC：启用
• RSS：启用
• Interrupt Moderation：默认值 / Adaptive
• Buffers：默认值
• Flow Control：默认值
• EEE / Green Ethernet：默认值
• Selective Suspend：默认值
• Wake on LAN：只在需要时

也就是说，先不要偏离默认值 才是基本做法。

10.2 NAS／备份／大容量复制

• Speed & Duplex：Auto
• Jumbo：专用链路能对齐的话就评估
• Checksum Offload：启用
• LSO：启用
• RSC：启用
• RSS：启用
• RSS queues：有需要就稍微增加
• Receive / Transmit Buffers：有丢包就稍微增加
• Interrupt Moderation：默认值 / 略高
• EEE：以稳定性为重就评估关闭

在大流量传输中，减少数据包数量、降低 CPU、避免队列不足 更容易见效。

10.3 工业相机／设备控制／以低延迟为重

• Speed & Duplex：原则上 Auto。必要时配合对端固定
• Jumbo：相机／网卡／交换机都能对齐的话就评估
• Checksum Offload：先启用
• LSO：怀疑发送兼容性时临时评估关闭
• RSC：以低延迟或观测为优先时列为关闭候选
• Interrupt Moderation：评估 Low / Off
• Buffers：不要加太多
• Flow Control：需要评估 pause 的副作用
• EEE / Green Ethernet：关闭候选
• Selective Suspend／电源管理：关闭候选

面向吞吐量优化的设置，未必对低延迟有利。

10.4 Hyper-V 主机

• VMQ / VMMQ / SR-IOV：按配置评估
• RSS：对主机侧流量很重要
• RSC：视 vSwitch 配置会有限制
• QoS / VLAN：与 vSwitch 设计保持一致
• Flow Control / PFC：与存储／RDMA 设计一体考虑

这已经不是台式机调优，而是 虚拟化平台设计。

10.5 排查故障用的临时设置

排查故障时，先把世界退回到简单状态是很有效的。

• Speed & Duplex：Auto
• MTU：1500
• Jumbo：关闭
• EEE：关闭
• LSO：临时关闭
• RSC：临时关闭
• Interrupt Moderation：默认值或偏低
• Wake / power save：不需要就关闭
• 变更前的设置：务必保存

排查时，让行为变简单比性能优化更重要。

11. 按症状划分的第一个排查点

11.1 本应是 1Gbps / 2.5Gbps 却变成 100Mbps

先看的顺序大致是这样。

1. 网线
2. 扩展坞／USB 网卡／转接器
3. 交换机侧端口
4. 更新驱动程序
5. EEE / Green Ethernet
6. 把 Speed & Duplex 改回 Auto
7. 还是不行的话，再试着配合对端做固定

一上来就手动固定是最后的手段。

flowchart TB
    accTitle: 降到 100Mbps 时的检查顺序
    accDescr: 按网线、扩展坞或 USB 网卡、交换机侧端口、更新驱动程序、EEE 的排查、改回 Auto Negotiation，还是不行再配合对端做固定的顺序来看的示意图。
    s1["网线"] --> s2["扩展坞 / USB 网卡 / 转接器"]
    s2 --> s3["交换机侧端口"]
    s3 --> s4["更新驱动程序"]
    s4 --> s5["排查 EEE"]
    s5 --> s6["把 Speed & Duplex 改回 Auto"]
    s6 -->|"还是不行的话"| s7["配合对端做固定"]

图23：降速的调查要从物理层按顺序推进，手动固定留作最后的手段。

11.2 大流量传输很慢，但 ping 正常

想看的是这几项。

• Checksum Offload
• LSO
• RSC
• RSS
• Receive / Transmit Buffers
• Jumbo Frame（专用链路的话）
• 网卡统计中的丢包／错误

这属于 吞吐量类问题，所以 Jumbo、队列、offload 容易见效。

11.3 小 request/response 的延迟大，在意 jitter

想确认的是这 5 项。

• Interrupt Moderation
• RSC
• EEE
• Flow Control
• Buffers 是不是加过头了

在这一带，合并处理类的优化 反而可能让体感延迟变大。

11.4 睡眠唤醒之后网卡消失／几秒钟连不上

以电源相关为主，想看的是这 5 项。

• Selective Suspend
• Device Sleep / Standby 相关设置
• 电源管理选项卡的 允许计算机关闭此设备…
• 扩展坞／USB 网卡的固件
• 唤醒设置的组合

唤醒问题与其说是网卡本身，多半是电源管理 的问题。

11.5 抓包时看到大量 checksum error

在急着说“线路坏了”之前，先确认这里。

• Checksum Offload 是否启用
• LSO 是否启用
• 抓包是在发送前，还是在线路上
• 换别的主机或镜像端口看是不是一样

本机抓包看到的 checksum error，是 offload 的表面现象 的情况真的非常多。

只对第 3 点“抓包是在发送前，还是在线路上”做点补充。在自己的 PC 上抓包时，看到的是网卡填入 checksum 之前的数据包。 如果 offload 是启用的，checksum 字段这时还是空的或临时值，分析工具当然会显示“不正确”。而实际流过网线的数据包是正确的，这种情况很常见。

flowchart TB
    accTitle: 本机抓包看起来像 checksum 错误的原理
    accDescr: 在自己的 PC 上抓包看到的是网卡填入 checksum 之前的数据包，因此 offload 启用时分析工具会显示不正确，但实际流过网线的数据包可能是正确的这一原理的示意图。
    lc1["在自己的 PC 上抓包"] --> pre1["看到的是填入 checksum 之前的数据包"]
    pre1 --> bad1["工具显示为不正确"]
    wire1["用镜像端口看线路上的数据"] --> okw1["实际的数据包是正确的"]
    okw1 -.-> ver1["两边对照就能确定是 offload 的表面现象"]

图24：本机抓包的位置在网卡之前，所以 offload 启用时的错误显示多半只是表面现象。

用来确认的工具，大致是下面 3 种。

pktmon 的日志 可以转换成 pcapng，因此可以直接用 Wireshark 打开。

pktmon etl2pcap log.etl --out capture.pcapng

如果“本机看是 checksum error，镜像端口看是正常的”，那就可以确定这是 offload 的表面现象。确认到这一步之后再去动设置。

11.6 只有 Hyper-V 的虚拟机慢／CPU 分布不均

该看的不只是台式机视角的 RSS。

• VMQ / VMMQ
• SR-IOV
• vSwitch binding
• VLAN / QoS
• 主机侧 RSS 与虚拟机侧队列的分工

在虚拟化环境中，把 是谁在处理数据包 画成图，会更容易理清。

12. 用 PowerShell 确认与变更时的实用备忘

12.1 先保存当前状态

变更前的备份很重要。

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Select-Object Name, DisplayName, DisplayValue, RegistryKeyword, RegistryValue |
  Export-Csv .\nic-advanced-backup.csv -NoTypeInformation -Encoding UTF8

12.2 列出清单

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Sort-Object DisplayName |
  Format-Table DisplayName, DisplayValue, RegistryKeyword -Auto

12.3 查看 RSS / RSC / 统计信息

Get-NetAdapterRss -Name "Ethernet"
Get-NetAdapterRsc -Name "Ethernet"
Get-NetAdapterStatistics -Name "Ethernet"

12.4 变更示例

实际的显示名称因网卡而异，所以先列出清单再变更。

# 示例: 变更 Jumbo Packet（取值因网卡而异）
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -DisplayName "Jumbo Packet" `
  -DisplayValue "9014 Bytes"

# 示例: 设置 RSS 的接收队列数
Set-NetAdapterRss -Name "Ethernet" -NumberOfReceiveQueues 4

12.5 Jumbo 的连通性确认

# 相当于标准 MTU 1500
ping <对端IP> -f -l 1472

# 相当于 MTU 9000
ping <对端IP> -f -l 8972

1472 与 8972 是扣掉 IP / ICMP 包头之后的负载大小。驱动程序界面上的 9014 Bytes 与这个 ping 的数字并不一致。

12.6 实务备忘

• 部分设置需要 禁用／启用网卡 或重启才生效
• DisplayName 有时是本地化过的
• 即使是同一厂商，驱动程序版本不同，项目名称也可能变化
• 要用 PowerShell 做自动化，先在真机上列出取值再写脚本 会更安全

13. 小结

Windows 的网卡高级设置，光看项目名称个个都“很强”。 但实际上，这是一个 要拿吞吐量、延迟、CPU、功耗、兼容性中的哪一个，正确答案就随之改变 的世界。

把本文的要点归纳起来是这样。

• Speed & Duplex 原则上用 Auto
• Jumbo 只在端到端对齐时才用
• Checksum / RSS / LSO / RSC 原则上默认值最稳
• Interrupt Moderation 是吞吐量与延迟的取舍
• Buffers 只加需要的量
• EEE / Selective Suspend / Wake 相关是功耗与唤醒的话题
• VMQ / SR-IOV 是 Hyper-V 的话题
• 老的 offload 项目不要碰

而最重要的是下面 3 点。

1. 先确定想改善什么
2. 一次只改一项
3. 用数据对比变更前后

网卡设置不是让速度变快的魔法开关。 但只要目的对得上，它就相当有效。反过来，目的一旦偏了，也会相当直接地产生反效果。

flowchart TB
    accTitle: 最重要的 3 个套路
    accDescr: 先确定想改善什么、一次只改一项、用数据对比变更前后这 3 个套路，只要目的对得上，网卡设置就相当有效的示意图。
    r1["先确定想改善什么"] --> r2["一次只改一项"]
    r2 --> r3["用数据对比变更前后"]
    r3 --> eff1["目的对得上就相当有效"]
    r1 -.->|"目的偏了就"| back1["直接产生反效果"]

图25：守住目的、一项、数据这 3 个套路就能见效，偏离就会产生反效果。

14. 参考资料

以下是撰写本文时作为基础参考的官方资料／厂商资料。 Windows 和网卡驱动程序的用语差异很多，最终还是要结合 自己网卡的驱动程序名称与版本 来确认才安全。

• Microsoft Learn: NIC advanced properties
• Microsoft Learn: Network Adapter Performance Tuning in Windows Server
• Microsoft Learn: Hardware Only (HO) features and technologies
• Microsoft Learn: Overview of Single Root I/O Virtualization (SR-IOV)
• Microsoft Learn: Standardized INF Keywords for NDIS QoS
• Microsoft Learn: Standardized INF Keywords for Power Management
• Microsoft Learn: Setting RSS parameters
• Microsoft Learn: Overview of receive segment coalescing
• Microsoft Learn: How to optimize network adapter power management settings
• Microsoft Learn: Deprecated networking features in Windows Server
• Microsoft Learn: Packet Monitor (Pktmon)
• Microsoft Learn: pktmon etl2pcap
• Microsoft Learn: UDP Segmentation Offload (USO)
• Microsoft Learn: UDP Receive Segment Coalescing Offload (URO)
• Intel Support: Advanced Settings for Intel Ethernet Adapters
• Intel Support: 速度固定、Jumbo、Interrupt Moderation、EEE、WoL 等，建议按网卡型号从对应的支持文章来确认会更安全

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

Large Send Offload（LSO）应该关闭吗？

通常应该保持启用。LSO 是由网卡把较大的 TCP 发送数据切分成小帧的机制，对发送密集型通信的吞吐量以及降低 CPU 使用率都有效果。随意关闭反而容易白白消耗 CPU。会考虑关闭的场景只有两类：一是怀疑特定应用或驱动程序存在兼容性问题时，临时关闭以观察差异，用于排查；二是像工业相机或设备控制那样需要评估发送兼容性的场合。即使为了排查而关闭，一旦确认原因在别处，原则上也要改回默认值。

Receive Segment Coalescing（RSC）是什么？是不是关掉比较好？

RSC 是在接收侧由网卡把多个 TCP 分段合并起来的设置，也叫作 Large Receive Offload。它对接收吞吐量和降低 CPU 使用率有效，所以以接收为重时，基本方针是保持启用。另一方面，在低延迟场景或以数据包为单位做观测时它可能不利，抓包和时序观测的解读也会略有变化。想压低小请求／响应的延迟，或者环境以低延迟和可观测性为优先时，它就成为评估关闭的候选项。当前状态可以用 Get-NetAdapterRsc 查看。

本应是 1Gbps 却只协商到 100Mbps 时，应该确认什么？

一上来就手动固定 Speed & Duplex 是最后的手段。检查顺序是：先看网线，再看扩展坞／USB 网卡／转接器，然后是交换机侧端口、驱动程序更新、EEE 与 Green Ethernet 的排查、把 Speed & Duplex 改回 Auto，如果还是不行，才配合对端做固定。因为降速到 100Mbps 和链路中断，原因往往不在网卡设置，而在物理层或对端设备。只有一侧固定、另一侧 Auto 的状态会造成 duplex mismatch（双工不匹配），进而引起降速、重传和异常延迟。

Windows 的网卡高级设置，到底该启用哪些？

如果是普通的台式机或笔记本，基本方针是先不要偏离默认值。Speed & Duplex 用 Auto，Checksum Offload、LSO、RSC、RSS 原则上保持启用或默认值，Jumbo Packet 只在网卡、对端以及中途的交换机能端到端全部对齐时才使用。EEE 和 Selective Suspend 是为省电而设的项目，不是让速度变快的设置。要改动时，铁则是先确定想改善什么（吞吐量、延迟、CPU、功耗），一次只改一项，并用数据对比改动前后的差异。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。