比赛前一晚 22:40，我拎着扳手站在香港荃湾机房 7 楼的过道里。ToR 交换机风扇像直升机一样呼呼作响，机柜 23U 的 Windows 游戏服刚刚从一轮压力回放里醒过来，Grafana 告诉我：20:00–21:00 的模拟直播窗口里，UDP 报文偶发丢包 0.6%～0.8%，玩家端的实时对战回放出现了两次短暂“橡皮筋”。

问题并不致命，但明天是真比赛，容错率等于零。我的判断很直接：不是带宽不够，是队列和优先级没摆对。于是那一夜，我把 QoS、队列、NIC 中断合并、RSS、以及上联交换机的 DSCP 映射一口气梳了一遍。凌晨 1:30，我们又跑了一轮满载回放，丢包降到 0.03%，延迟抖动从 12–18ms 收敛到 2–4ms。第二天下午的直播，你们看的就是这套配置在顶着跑。

这篇文章，我把那晚从问题识别→方案设计→Windows 实施→交换机联动→验证与回滚的全过程拆开写清楚，该贴代码贴代码，该摆表格摆表格。新手照做能跑，老手也能对着参数微调。

基础环境与硬件参数（真实现场）

诊断与目标

症状：直播及赛中高并发时，服务器出口偶发拥塞，UDP 游戏流量在 NIC 出口队列与 ToR 入队列发生竞争，短时丢包/抖动。

目标：在 Windows 层标记并优先转发关键实时流（游戏、语音/房间信令），在交换机队列中给出更高权重；同时将后台更新、日志归档等降级，必要时限速。

原则：

• 端到端很难保证公网遵循 DSCP，但机房出口到运营商边界我们能做到。只要在拥塞边界我们这边不丢，玩家掉线概率就会显著下降。
• UDP 不是 RoCE，不追求 PFC（无损暂停），用 ETS（加权队列）+ DSCP→队列映射即可。

分级与标记策略（实战可用）

说明：EF=46 用于低延迟实时流，AF41=34 给直播流足够优先；CS1=8 明确告诉网络“这玩意儿不着急”。

步骤 1：Windows 侧 NIC 与内核调优

1.1 电源与定时器

# 性能电源计划
powercfg /setactive SCHEME_MIN

# 确认高精度事件计时器（通常默认即可）
bcdedit /set useplatformclock yes

1.2 RSS、多队列与中断调优（X710）
# 查看 NIC
Get-NetAdapter | ft Name, Status, LinkSpeed

# 启用 RSS 并限制核数，减少抖动（按你 CPU 拓扑调整）
Enable-NetAdapterRss -Name "Ethernet"
Set-NetAdapterRss -Name "Ethernet" -MaxProcessors 8

# 增大接收/发送缓冲（避免瞬时丢包）
Get-NetAdapterAdvancedProperty -Name "Ethernet" `
  | ? {$_.DisplayName -match "Receive Buffers|Transmit Buffers"}

# 常见做法：把 Recv/Tx Buffers 调到 1024/1024 或驱动允许的上限
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue "1024"
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Transmit Buffers" -DisplayValue "1024"

# 合理的中断调制（Interrupt Moderation）：游戏流量更看重抖动
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Interrupt Moderation" -DisplayValue "Off"

注：LSO/RSC/Checksum Offload 是否关闭需结合你 CPU% 与 PPS 测试，默认先保留。如遇高抖动再逐项评估关闭 LSO/RSC。

步骤 2：Windows QoS 策略（DSCP 与 802.1p）

Windows 有两条路：本地组策略（GUI） 和 PowerShell。比赛现场我用 PowerShell 一把梭，配合 GPO 作持久化。

2.1 安装 DCB 功能并启用 NetAdapter QoS

# 仅用于启用 802.1p/ETS 分类能力（不会强制 PFC）
Install-WindowsFeature Data-Center-Bridging -IncludeManagementTools

# 启用适配器 QoS（为 802.1p 标记与队列调度启路）
Enable-NetAdapterQos -Name "Ethernet"

2.2 定义流量类（ETS）与带宽下限（可选）

# 为优先级 5（实时）预留 20% 带宽（权重），避免被挤占
New-NetQosTrafficClass -Name "Realtime" -Priority 5 -BandwidthPercentage 20 -Algorithm ETS

# 为优先级 4（直播）预留 15%
New-NetQosTrafficClass -Name "Live" -Priority 4 -BandwidthPercentage 15 -Algorithm ETS

2.3 创建 QoS 策略：按进程匹配并打 DSCP/802.1p

按进程匹配最稳：游戏服、推流工具路径固定；不用纠结端口是否临时变化。

# 游戏 UDP：EF(46) + 802.1p 5
New-NetQosPolicy -Name "Game-UDP" `
  -AppPathNameMatchCondition "C:\GameSrv\bin\gameserver.exe" `
  -IPProtocolMatchCondition UDP `
  -DSCPAction 46 `
  -PriorityValue8021Action 5 `
  -PolicyStore PersistentStore  # 持久化

# 直播 RTMP：AF41(34) + 802.1p 4
New-NetQosPolicy -Name "Live-RTMP" `
  -AppPathNameMatchCondition "C:\Stream\rtmppush.exe" `
  -IPProtocolMatchCondition TCP `
  -DSCPAction 34 `
  -PriorityValue8021Action 4 `
  -PolicyStore PersistentStore

# 后台更新：CS1(8) 并限速（例如单进程 50 Mbps）
New-NetQosPolicy -Name "Background-Low" `
  -AppPathNameMatchCondition "C:\Ops\backup.exe" `
  -DSCPAction 8 `
  -ThrottleRateActionBitsPerSecond 50000000 `
  -PolicyStore PersistentStore

验证策略生效：

Get-NetQosPolicy
Get-NetQosEffectivePolicy | ft Name, AppPathName, DSCPAction, PriorityValue8021Action

2.4 GUI 路线（本地组策略，备选）

• gpedit.msc → 计算机配置 → Windows 设置 → 基于策略的 QoS
• 新建策略 → 指定 DSCP 值（比如 46）→ 仅对 应用程序路径 生效 → 指定协议/端口（可选）
• 同步/刷新：gpupdate /force

步骤 3：ToR 交换机队列映射（必做，否则 DSCP 白打）

把 DSCP → 队列 显式映射，确保 EF/AF41 进高优队列。以下给两套思路示例（按你设备语法替换）：

3.1 Arista（示例）

# class-map
class-map match-any QM-REALTIME
  match ip dscp ef
class-map match-any QM-LIVE
  match ip dscp af41
class-map match-any QM-LOW
  match ip dscp cs1

# policy-map：把 EF 放 Q7，AF41 放 Q6，CS1 放 Q1
policy-map QOS-POLICY
  class QM-REALTIME
    priority level 1            # 严格优先
    set dscp ef
  class QM-LIVE
    bandwidth percent 20
    set dscp af41
  class QM-LOW
    bandwidth percent 5
    set dscp cs1
  class class-default
    bandwidth percent 74

# 应用到上行接口
interface Ethernet1
  service-policy input QOS-POLICY
  service-policy output QOS-POLICY

3.2 Cisco NX-OS（示例）

mls qos
class-map match-any QM-REALTIME
  match dscp ef
class-map match-any QM-LIVE
  match dscp af41
class-map match-any QM-LOW
  match dscp cs1

policy-map QOS-POLICY
  class QM-REALTIME
    priority level 1
  class QM-LIVE
    bandwidth percent 20
  class QM-LOW
    bandwidth percent 5
  class class-default
    bandwidth percent 74

interface Eth1/1
  service-policy input QOS-POLICY
  service-policy output QOS-POLICY

运营商侧是否保留 DSCP：PCCW/HGC 在跨网段时多数会重标或忽略，但你机房出口到汇聚这一段的优先队列依然能救命（拥塞主要就发生在你自己这端与汇聚口）。

步骤 4：验证方法（一定要做）

4.1 抓包看 DSCP（服务器本机）

# Windows 10/Server 2022 自带 pktmon（也可 Wireshark）
pktmon filter remove
pktmon filter add -t udp
pktmon start --etw -p 0

# 观察 DSCP 字段（或用 Wireshark：ip.dsfield.dscp）
# 完成后停止
pktmon stop

4.2 压测并带 ToS/DSCP（对端用 iperf3）

# EF(46) 的 ToS 为 0xB8（十进制 184 = 46 << 2）
iperf3 -c <server_ip> -u -b 100M -l 1200 -S 0xB8 -t 60
# AF41(34) 的 ToS 为 0x88（十进制 136 = 34 << 2）
iperf3 -c <server_ip> -u -b 50M  -l 1200 -S 0x88 -t 60

4.3 性能计数器与指标（PerfMon/Grafana）

监控以下指标，比赛日开三屏盯着看：

• Network Interface / Output Queue Length（< 1 为佳）
• UDPv4 / Datagrams Received Errors、UDPv4 / Datagrams No Ports
• Processor Information / Interrupts/sec（观测中断洪泛）
• NIC 驱动自带 Tx Queue Drops、Rx Missed（用厂商工具或 Get-NetAdapterStatistics）

实测数据（模拟直播 60 分钟）

注：优化后主要得益于队列分级与中断/缓存的综合调整。

赛时联动控制（应急脚本）

5.1 一键降级后台流量（现场常用）

# 把后台进程临时再降 50% 限速
Set-NetQosPolicy -Name "Background-Low" -ThrottleRateActionBitsPerSecond 25000000

5.2 赛后回到常态

Set-NetQosPolicy -Name "Background-Low" -ThrottleRateActionBitsPerSecond 50000000

5.3 快速回滚（有风险时直接撤）

Remove-NetQosPolicy -Name "Game-UDP" -PolicyStore PersistentStore -Confirm:$false
Remove-NetQosPolicy -Name "Live-RTMP" -PolicyStore PersistentStore -Confirm:$false
Remove-NetQosTrafficClass -Name "Realtime" -Confirm:$false
Remove-NetQosTrafficClass -Name "Live" -Confirm:$false

常见坑与现场解法

DSCP 被虚拟交换机吃掉

场景：装了 Hyper-V 或第三方 vSwitch 后，DSCP 不透传。

解法：比赛机建议裸金属直连；若必须虚拟化，启用 vSwitch 的 QoS 透传或在宿主侧打标。

运营商出口重标/清洗 DSCP

场景：跨运营商时，DSCP 被清零。

解法：我们只需求本地出口与 ToR/汇聚保优先，公网部分不可控；同时把后台流量限速，保留瞬时带宽给实时流。

PFC（优先级流控）滥用

场景：有人想把 UDP 实时流搞成“无损”。

解法：不要给 UDP 开 PFC（Pause），会放大尾延迟；我们只用 ETS + 优先队列。

驱动升级后缓冲参数被重置

解法：把 NIC 高级属性和 QoS 脚本写成配置基线，升级后一键重放。

策略匹配错杀

场景：按端口匹配，但服务临时换了端口，导致没打到 EF。

解法：改用 AppPathNameMatchCondition（按进程路径），并在发布流程中固化路径。

LSO/RSC 关闭导致 CPU 打满

解法：关闭前先压测CPU 余量；游戏场景通常 PPS 高、包小，先保持默认开启，有抖动再逐项验证。

运维自查清单（赛前 30 分钟）

1.  Get-NetQosEffectivePolicy 显示 EF/AF41 策略已生效
2.  pktmon/Wireshark 抓包可见 DSCP=46/34
3.  ToR 接口 service-policy 已应用，队列统计有计数
4.  Grafana Jitter/Queue 面板 10 分钟稳定
5.  后台归档/更新限速已启用
6.  备份回滚脚本就绪（已本地测试）

完整部署脚本（可直接落地，按路径修改）

<#  QoS-Deploy.ps1  #>

# 1) 性能基线
powercfg /setactive SCHEME_MIN
Enable-NetAdapterRss -Name "Ethernet"
Set-NetAdapterRss -Name "Ethernet" -MaxProcessors 8
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue "1024"
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Transmit Buffers" -DisplayValue "1024"
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Interrupt Moderation" -DisplayValue "Off"

# 2) DCB/Adapter QoS
Install-WindowsFeature Data-Center-Bridging -IncludeManagementTools
Enable-NetAdapterQos -Name "Ethernet"
New-NetQosTrafficClass -Name "Realtime" -Priority 5 -BandwidthPercentage 20 -Algorithm ETS
New-NetQosTrafficClass -Name "Live" -Priority 4 -BandwidthPercentage 15 -Algorithm ETS

# 3) QoS 策略
New-NetQosPolicy -Name "Game-UDP" `
  -AppPathNameMatchCondition "C:\GameSrv\bin\gameserver.exe" `
  -IPProtocolMatchCondition UDP `
  -DSCPAction 46 -PriorityValue8021Action 5 `
  -PolicyStore PersistentStore

New-NetQosPolicy -Name "Live-RTMP" `
  -AppPathNameMatchCondition "C:\Stream\rtmppush.exe" `
  -IPProtocolMatchCondition TCP `
  -DSCPAction 34 -PriorityValue8021Action 4 `
  -PolicyStore PersistentStore

New-NetQosPolicy -Name "Background-Low" `
  -AppPathNameMatchCondition "C:\Ops\backup.exe" `
  -DSCPAction 8 -ThrottleRateActionBitsPerSecond 50000000 `
  -PolicyStore PersistentStore

# 4) 验证
Get-NetQosEffectivePolicy | ft Name,AppPathName,DSCPAction,PriorityValue8021Action

FAQ（老手常问）

只在 Windows 打 DSCP，不改交换机会怎样？
多数情况下没用。至少要在 ToR/汇聚把 DSCP 映射到高优队列。

公网 ISPs 不认 DSCP，是否白做？
不白。拥塞边界通常就在你出口，在这里优先队列可显著降低抖动与丢包；公网段即便不认，也已经把最关键的一跳“救”了。

是否建议 Jumbo Frames？
实时 UDP 小包为主，不强求。除非端到端都支持，且直播流量占比高，可单独走 MTU 9000 的接口/子网，但要测。

比赛开始前的 30 秒

比赛开始倒计时 30 秒，我在机柜前把手电筒插回磁吸座，看着 Grafana 上实时 UDP 抖动曲线像贴地飞行一样平。导播在对讲里说“开始”。那一刻我知道，昨晚那杯冻柠茶没白喝：队列分了级、优先搞清了、后台让了路，玩家的子弹不会再被队列堵在门口。
等赛后散场的风从机房过道吹过来，我把回滚脚本和本次参数留在了运维基线仓库；下次再遇到类似场景，我只需要换掉三条路径和两个百分比数——其余的，已经被那一夜写进了我们的 SOP。