那天是周五深夜 1 点，香港荃湾机房外面依旧是霓虹生动。客户在微信语音里只说了一句话：“直播间卡得观众骂娘。”我盯着 NOC 大屏上几条线路的丢包曲线，一眼就看出问题在 UDP：码率很高、包很碎、CPU 抢不过编解码线程。那一刻我决定把这台跑 Windows Server 2022 的香港边缘节点彻底“洗一遍”，把 UDP 分段卸载（Windows 下的 USO，类比 Linux 的 GSO） 全链路打通，再顺手把 RSS、RSC、队列和 QoS 一套带走。
下面是我当晚在机房里的完整实操记录——不管你是刚上手的运维，还是已经维护过一堆媒体服务的老兵，都能照着复刻，并避开我踩过的坑。

1) 背景与目标

问题：上行码率 6–12 Mbps 的实时音视频在高并发时抖动和丢包明显，CPU 飙升，RTP 重传/修复帧增多。

判断：UDP 包在主机侧被过度分片，内核/协议栈承担了大量小包分段开销，NIC 没有替我们干活。

目标：

• 打通/核验 UDP Segmentation Offload（USO）；
• 协同开启 RSS/RSC/校验和卸载 与合理 MTU；
• 在不改变应用代码的前提下，显著降低 CPU、抖动和重传。

2) 环境与硬件清单

注：你不一定必须是同款硬件，但新版驱动 + 支持 UDP offload 的 NIC 基本是硬指标。

3) 核心概念：GSO vs USO（以及为什么它能救实时音视频）

GSO（Generic Segmentation Offload） 是 Linux 侧的概念：让内核或驱动在“更靠后”的阶段再把大包切成合规的小包，减少栈内频繁处理小包的成本。

USO（UDP Segmentation Offload） 是 Windows 里的对应思路：把 UDP 的分段工作尽量卸载给网卡/驱动层（或更靠近硬件的路径），让 CPU 从“把大流拆成一堆小包”的琐事里解放出来。

对实时音视频的意义：更少的每秒包数（PPS）+ 更低的 CPU 抢占 + 更稳定的 RTT/Jitter。你同样的 8–10 Mbps，不再被小包风暴拖垮。

4) 网络路径与 MTU 规划

我做了一个简短的路径 MTU 盘点（你也应该做）：

经验法则：公网侧别上 Jumbo，私网/复制/缓存同步可上；应用侧 UDP payload 以 1200–1400 为目标值，减少公网分片。

5) 实操步骤

5.1 确认 OS/驱动/虚拟化支持

# 列出网卡、驱动时间与 NDIS 版本（新版更稳）
Get-NetAdapter | Get-NetAdapterHardwareInfo |
  Select-Object Name, InterfaceDescription, DriverVersion, DriverDate, NdisVersion | Format-Table -Auto

# 查看网卡高级属性（不同厂商命名不同）
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Sort-Object DisplayName | Format-Table -Auto

# Hyper-V 场景（如果是 VM）：确认 SR-IOV 与 vRSS
Get-VMNetworkAdapter -VMName "MediaVM" | Format-List *Sriov*,*Vrss*

如果你在 VM 里，优先 SR-IOV/直通 或使用支持高级 offload 的 vNIC（VMXNET3 / Hyper-V vNIC）并确保宿主也开启 RSS/RSC。

5.2 打开/校准 USO、Checksum Offload、RSS、RSC、队列

说明：USO 在 Windows Server 2022 上通常是“驱动支持则默认可用”。我们能做的是确保没被关掉、并把周边的协同开关（RSS、校验和、RSC）一起拉好。不同厂商的高级属性名字不一样，下面给出“通用写法 + 常见范例”。

5.2.1 校验和卸载（UDP Checksum Offload）

# 通用：优先用 DisplayName
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -DisplayName "UDP Checksum Offload (IPv4)" -DisplayValue "Enabled"
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -DisplayName "UDP Checksum Offload (IPv6)" -DisplayValue "Enabled"

# 若你的驱动只暴露注册表关键字（示例，不同驱动数值可能是 0/1/3）
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -RegistryKeyword "*UDPChecksumOffloadIPv4" -RegistryValue 3
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -RegistryKeyword "*UDPChecksumOffloadIPv6" -RegistryValue 3

5.2.2 RSS（Receive Side Scaling）与队列

# 开启 RSS、设定队列/亲和
Enable-NetAdapterRss -Name "Ethernet"

# 查看硬件支持的队列数，留意 NUMA 节点
Get-NetAdapterRss -Name "Ethernet" | Format-List *

# 合理分配 RSS 使用的 CPU（例如前 8 颗逻辑核）
Set-NetAdapterRss -Name "Ethernet" -BaseProcessorNumber 0 -MaxProcessors 8

小贴士：如果是双路 CPU，避免跨 NUMA 抢内存，RSS 的基础核尽量固定在同一 NUMA。

5.2.3 RSC（Receive Segment Coalescing）

# 全局查看/开启 RSC（接收侧合并；对 CPU 也友好）
Get-NetOffloadGlobalSetting
Set-NetOffloadGlobalSetting -ReceiveSegmentCoalescing Enabled

注：RSC 原生更偏 TCP，但新驱动对 UDP 的接收路径也做了优化（不同厂商实现有差异），建议开启并压测验证。

5.2.4 USO（UDP Segmentation Offload）可用性自检

没有统一的“USO=Enabled”开关，但新驱动常内建。我的做法是通过流量 ETW 验证是否走了分段卸载路径：

# 抓一段 UDP 大流的 ETL
netsh trace start capture=yes scenario=InternetClient tracefile=C:\logs\udp.etl maxsize=1024
# 10~20 秒后停止
netsh trace stop

# 用 Windows Performance Analyzer 打开 C:\logs\udp.etl：
# 观察网络栈 CPU、发送路径事件，注意是否由驱动/NDIS 层完成分段（PPS 明显降低）

5.2.5 中断调优、队列和延迟
# 把中断调节（Interrupt Moderation）从“自适应/高”改为“低/开销更高但延迟更小”
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Interrupt Moderation" -DisplayValue "Low"

# 对 Intel X710 之类：适当拉大 Descriptor 队列（不同驱动名字不同，如 "Receive Buffers"/"Transmit Buffers"）
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue "2048"
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Transmit Buffers" -DisplayValue "2048"

修改后重启网卡以生效：

Restart-NetAdapter -Name "Ethernet"

5.3 MTU/Jumbo、NUMA 亲和与进程绑核

公网链路坚持 1500 MTU；私网（例如 TURN ↔ SFU、缓存/转推）可上 9000，但路径上每一跳都得支持。

# 仅在内网口启用 Jumbo（示例值视驱动而定：9014/4088/16128）
Set-NetAdapterAdvancedProperty -Name "Ethernet-Private" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"

# 公网口保持 1500（默认）

应用进程绑核（让编解码与网络线程别互相抢）：

# 示例：把媒体进程绑到 0~7 号逻辑核（十六进制位图 0xFF）
$proc = Get-Process -Name "mediaserver"
$proc.ProcessorAffinity = 0x000000FF

5.4 防火墙与 QoS（DSCP）

放通必须的 UDP 端口，并给音频优先级（EF=46）：

# 防火墙
New-NetFirewallRule -DisplayName "RTC-UDP" -Direction Inbound -Protocol UDP `
  -LocalPort 3478,5349,49152-65535 -Action Allow

# QoS：对 UDP 端口打 DSCP=46
New-NetQosPolicy -Name "RTC-Audio" -IPProtocolMatchCondition UDP `
  -IPDstPortMatchCondition 40000-40959 -DSCPAction 46

New-NetQosPolicy -Name "RTC-Video" -IPProtocolMatchCondition UDP `
  -IPDstPortMatchCondition 40960-65535 -DSCPAction 34  # 视频稍低一档（AF41），可按需调整

企业网络/跨域时，确认中间设备不“洗”DSCP；否则该策略只能在本机内核调度层面受益。

5.5 压测与可观测性

5.5.1 UDP 吞吐与抖动

# 服务器侧
iperf3.exe -s

# 客户端（另一台到香港节点的机器）
iperf3.exe -c <HK-Server-IP> -u -b 8M -l 1200 -t 60 --get-server-output

5.5.2 UDP Ping/Jitter 采样
# 以 1200 字节 Payload 连续 UDP Ping
psping -u -l 1200 -n 10000 <HK-Server-IP>:50000

5.5.3 性能计数器采样
typeperf "\Processor(_Total)\% Processor Time" `
         "\UDPv4\Datagrams Received Errors" `
         "\UDPv4\Datagrams/sec" `
         -si 1 -sc 60 > C:\logs\udp_perf.csv

5.5.4 路径 MTU 探测（黑洞排查）

# 以 DF 位探测
ping <Client-IP> -f -l 1472   # 1472 + 28(IPv4头+UDP头) ≈ 1500

5.6 应用侧配合（WebRTC/QUIC/RTP）

USO 负责发送侧分段优化，但公网分片仍要靠应用层控制包大小。建议：

• WebRTC/QUIC：保持 1200B 的最大 UDP payload（与 HTTP/3 最小初始大小一致）。
• RTP：把 maxPacketSize/mtu 设到 1200–1300，避免公网分片；TURN 中继也同步调整。
• FEC/PLI：在高丢包时优先 FEC，别把 RTX（重传）打满带宽。

一个典型的（伪）配置示例：

{
  "rtp": {
    "mtu": 1200,
    "minBitrateKbps": 300,
    "maxBitrateKbps": 12000,
    "useFec": true,
    "useRtx": true,
    "absSendTime": true
  },
  "turn": { "ports": "3478,5349", "udpMin": 49152, "udpMax": 65535 }
}

6) 真实数据对比（我的当晚实测）

注：不同网络与硬件会略有差异，趋势基本一致。

7) 常见坑与排障手册

“我没看到 USO 开关”

正常。Windows 上 USO 多为驱动内建能力，用 ETW/WPA 验证是否走了驱动分段路径；或者看 PPS 下降是否明显。

驱动太老/厂商属性名对不上

解决：升级到 近两年内发布的驱动与固件。Intel X710/XL710 一定要跟上新版 PROSet。

Get-NetAdapterAdvancedProperty 全部列出来，搜 UDP/Offload/Checksum/Receive/Buffer 关键词逐项核对。

VM 里效果不明显

打开 SR-IOV 或用对的 vNIC；宿主也要开启 RSS/RSC。某些云/虚拟化栈会屏蔽硬件卸载。

Jumbo 一开就“黑洞”

只在私网用 Jumbo，公网坚持 1500。逐跳 ping -f -l 验证。

Interrupt Moderation 设太激进

极端聚合会抖动增大。实时音视频偏好 Low/Medium，以稳定优先。

NAT 设备 UDP 超时太短

Windows NAT：Set-NetNat -Name "<YourNat>" -UdpTimeout 120（按需）。外部硬件防火墙也要同步调宽。

QoS 没生效

中间设备可能“清洗”DSCP；至少在本机调度和内网拥塞时仍有益。可用抓包验证 DSCP 位。

应用侧仍用 1400+ 的 RTP 包

公网分片会把你所有优化打回原形。把 mtu/maxPacketSize 限到 1200–1300。

凌晨 3 点半，机房的空调像海浪一样稳。我们把最后一条规则应用到备用节点，Grafana 上的抖动曲线终于压成了一条“无聊的直线”。客户发来一句“好了”，我把工单状态改成 Resolved，在门口自助咖啡机前多按了一次“加浓”。

这套调优没什么神秘魔法：让该干活的人（网卡/驱动）去干活，让 CPU 专心做编解码与调度；把包做“大→小”的过程移到更靠近硬件的一端，再用 RSS、队列、中断和 QoS 把剩下的路径铺平。你也可以照着做，把直播间从“卡顿吐槽”拉回“弹幕刷屏”。

如果你想，我还能把这套脚本整理成一键校验/配置的 PowerShell 工具包——涵盖网卡属性枚举、驱动版本检查、RSS/队列/中断一键设置、压测与日志采集。说一声就发你。