周五晚上 9 点多，公司总部临时拉了场跨区视频会：旧金山、伦敦、新加坡和我们香港节点同时在线。刚开场五分钟，CEO 的画面就开始定格，字幕像弹幕一样跳。监控里，香港服务器的上行带宽几次打满——仓库同步、日志回传、以及临时的数据导出全撞在一起。

我当场决定：不换会、不断流，直接在这台香港 Windows Server（2022 Datacenter）上给“实时媒体”开路——用 Policy-based QoS 给 Teams/Zoom/Google Meet 的流量打上 DSCP，顺带对“非关键的大流量”做限速，确保拥塞时会议优先。十五分钟后，抖动从 60–120ms 掉到 15–30ms，丢包从 2–4% 降到 <0.3%。会后，大家只问了一个问题：你刚才到底动了什么？

下面就是完整过程。

现场环境与目标

硬件与网络拓扑

服务器：Dell R650，Windows Server 2022 Datacenter（Build 20348）

CPU / 内存：Xeon Silver 4314 ×2 / 256GB

网卡：Intel X710 双口（10GbE），单口接入 ISP-A（PCCW/和记系），单口空闲作备份

上联：1Gbps 计费口（95th），BGP 到运营商边缘

业务：Teams/Zoom/Google Meet 会议端点（录制/转码/转发），同时承担对象存储网关、日志上送、仓库镜像同步

目标：在拥塞时确保视频会议（音频>视频>共享）得到优先队列，并对“非关键”背景任务做软限速，实现“会议不受影响、后台慢就慢点”。

QoS 策略设计思路（为什么这样分）

识别与标记（Classification & Marking）

在服务器端对会议流量进行 DSCP 标记，常用实践：

• Teams：音频 EF(46)、视频 AF41(34)、屏幕共享 AF21(18)，并配合源端口区间做匹配（官方推荐端口段）。
• Zoom：媒体常走 UDP 3478/3479（STUN/TURN）与 8801–8810（会议媒体），对这些端口的 UDP 做 AF41 标记即可（Zoom 不区分音视频端口时就统一按“视频优先”处理）。
• Google Meet：UDP 3478 及 19302–19309，统一给 AF41。

资源调度（Shaping & Throttling）

Windows 的 Policy-based QoS 既能打 DSCP，也能限制指定流量的出站速度（Throttle）。我对“仓库同步、对象存储拉取、批量下载”等执行文件（如 rclone/robocopy/自研同步器）做 20–50 Mbps 的软限，给会议让路。GPO 与 PowerShell 都支持。

端到端一致性提醒

DSCP 需要端到端被认可才有意义——起码网卡出站、TOR 交换、上联路由要信任并队列化。跨公网有时会被中间段清零；因此我在服务器侧两条腿走路：

有就用：尽量打 DSCP，让能识别的段真排队；

没就限：对后台流量做发送端限速，避开拥塞。

参数与端口“白名单”依据（可直接复用）

Teams 初始端口与 DSCP（客户端源端口，Windows/Mac/移动端均适用；浏览器除外）：

• 音频：50,000–50,019 → DSCP 46 (EF)
• 视频：50,020–50,039 → DSCP 34 (AF41)
• 屏幕共享：50,040–50,059 → DSCP 18 (AF21)
• （信令 50,070–50,089 UDP，CS5，当前不可自定义）
• 新版 Teams 可执行名从 teams.exe 变为 ms-teams.exe（若按进程名匹配，需注意变更）。

Zoom 会议与房间常用端口：

• UDP：3478/3479、8801–8810（媒体）
• TCP：443、8801/8802（补充）

房间/直连共享还会用到 5590–5600、8888/8889 等。

Google Meet：

UDP：3478、19302–19309（媒体），以及 web 流量 443。

Windows QoS 能力：

Policy-based QoS 支持按应用名、URL、IP/端口、协议匹配，并能设置 DSCP 和 出站限速；GPO 下计算机级与用户级策略有优先级与“匹配条件更具体优先”的规则。

PowerShell New-NetQosPolicy/Set-NetQosPolicy 提供 -DSCPAction 与 -ThrottleRateActionBitsPerSecond，并支持源/目的端口区间匹配。

实施 A 案：图形化（GPO/本地策略）

适合一次性在多台域内服务器/工作站推广；单机也可用本地策略（gpedit.msc）。

打开 本地组策略：gpedit.msc → 计算机配置 → Windows 设置 → QoS 策略。

右键“QoS 策略” → 创建新策略：

• 策略名：Teams_Audio_EF
• 指定 DSCP 值：46（勾选）
• 限速：不勾或留空
• 应用程序：可留空（全应用）或指定 ms-teams.exe；（新版可执行名注意）
• 协议与端口：Protocol 选 TCP and UDP；源端口填入区间 50000:50019；目标端口留 Any。
• 完成。

同法创建：

• Teams_Video_AF41（DSCP 34，源端口 50020:50039）
• Teams_Share_AF21（DSCP 18，源端口 50040:50059）
• Zoom_Media_AF41（DSCP 34，Protocol UDP，目标端口 8801:8810 + 3478/3479）
• Meet_Media_AF41（DSCP 34，Protocol UDP，目标端口 3478 + 19302:19309）

为“非关键后台”建限速策略（示例）：

• Rclone_Limit_30M：指定应用 rclone.exe，限速 30 MBps（约 240 Mbps）或更低；
• Robocopy_Limit_10M：指定 robocopy.exe，限速 10 MBps。

进阶：高级 QoS 设置里可启用 TCP 接收窗口/DSCP Override 等（一般默认即可）。

GPO 的每一步在微软文档里都有截图与字段解释，具体向导页面（策略档案、应用名、IP 地址、协议与端口）的含义与注意事项也在同一文档里写得很细。

实施 B 案：PowerShell（更快、可脚本化）

下面脚本在 Windows Server 2019/2022 测试通过，可直接落库为配置基线。

# 1) 清理旧策略（可选）
Get-NetQosPolicy | Where-Object { $_.Name -like "Teams_*" -or $_.Name -like "Zoom_*" -or $_.Name -like "Meet_*" -or $_.Name -like "*_Limit_*" } | Remove-NetQosPolicy -Confirm:$false

# 2) Teams：音频 / 视频 / 共享（基于源端口）
New-NetQosPolicy -Name "Teams_Audio_EF"  -IPProtocolMatchCondition Both -IPSrcPortStartMatchCondition 50000 -IPSrcPortEndMatchCondition 50019 -DSCPAction 46
New-NetQosPolicy -Name "Teams_Video_AF41" -IPProtocolMatchCondition Both -IPSrcPortStartMatchCondition 50020 -IPSrcPortEndMatchCondition 50039 -DSCPAction 34
New-NetQosPolicy -Name "Teams_Share_AF21" -IPProtocolMatchCondition Both -IPSrcPortStartMatchCondition 50040 -IPSrcPortEndMatchCondition 50059 -DSCPAction 18

# 3) Zoom：媒体端口（基于目的端口）
New-NetQosPolicy -Name "Zoom_Media_8801_8810" -IPProtocolMatchCondition UDP -IPDstPortStartMatchCondition 8801 -IPDstPortEndMatchCondition 8810 -DSCPAction 34
New-NetQosPolicy -Name "Zoom_STUN_3478"      -IPProtocolMatchCondition UDP -IPDstPortMatchCondition 3478 -DSCPAction 34
New-NetQosPolicy -Name "Zoom_STUN_3479"      -IPProtocolMatchCondition UDP -IPDstPortMatchCondition 3479 -DSCPAction 34

# 4) Google Meet：媒体端口（基于目的端口）
New-NetQosPolicy -Name "Meet_UDP_3478"        -IPProtocolMatchCondition UDP -IPDstPortMatchCondition 3478 -DSCPAction 34
New-NetQosPolicy -Name "Meet_UDP_19302_19309" -IPProtocolMatchCondition UDP -IPDstPortStartMatchCondition 19302 -IPDstPortEndMatchCondition 19309 -DSCPAction 34

# 5) 非关键后台：对特定可执行文件限速（示例值按你带宽改）
New-NetQosPolicy -Name "Rclone_Limit_30MBps"  -AppPathNameMatchCondition "rclone.exe"  -ThrottleRateActionBitsPerSecond (30MB)  # 30MB/s ≈ 240Mbps
New-NetQosPolicy -Name "Robocopy_Limit_10MBps" -AppPathNameMatchCondition "robocopy.exe" -ThrottleRateActionBitsPerSecond (10MB)

# 查看与核对
Get-NetQosPolicy | Format-Table Name, DSCPAction, ThrottleRateActionBitsPerSecond, IPProtocol, IPSrcPortStart, IPSrcPortEnd, IPDstPortStart, IPDstPortEnd

以上参数与能力（端口区间、DSCP、限速）来自 Windows 的 NetQos 模块官方文档。

Teams 端口与 DSCP 的分配来自官方推荐。

Zoom/Meet 端口来自其官方网络/防火墙说明。

我如何验证它真的生效

抓包看 DSCP

在服务器或交换机镜像口用 Wireshark：

• 过滤 ip.dsfield.dscp == 46（音频），或 == 34/18；
• 随手点开包看 RTP/UDP 的 DSCP 字段是否被改写。
• 对于 Teams，微软也强调要在链路出口验证 DSCP 是否被清除或保留。

Windows 原生工具

• Get-NetQosPolicy：查看策略生效与匹配条件。
• pktmon start --etw -p 0 + 过滤器（高级用法）观察内核层分类。
• netsh trace start capture=yes 短时抓取配合解析。

压测/对比法

我边开会边让 rclone 往对象存储拉大文件（被限速 30MB/s），观察：会议端 jitter/packet loss 下降，rclone 稳在限速值；放开限速，会议立即抖动，重加限速后恢复。

一次真实的跨区会议数据（前/后对比）

注：RTT 是跨公网物理现实，QoS 不是“变魔术降低 RTT”，它的价值在拥塞时优先排队与平滑抖动，让实时媒体少掉包、少乱序。跨公网段如不识别 DSCP，发送端限速+端口分流仍然有效。

常见坑与我当场怎么处理

teams.exe → ms-teams.exe
新版 Teams 可执行名变化导致“按进程名匹配”的策略失效——优先使用端口区间匹配（更稳），若必须按进程名，记得更新名字并验证。

DSCP 被中间段清零
很多公网段/运营商会把 DSCP 清零。对这种链路，我保留 DSCP 以利于本端出站与机房内部排队，同时对“背景流量”做出站限速，实现“绕开抢占”。

策略优先级与匹配冲突
QoS 只有一条策略对某个出站包生效。尽量让“具体匹配”（如端口段）数量多于“宽泛匹配”（如全应用），并避免多个策略覆盖同一五元组。GPO/用户/计算机级之间也有优先规则。

IPv6 遗漏
流量走 IPv6 时若策略只管 IPv4，就会漏标。用 -IPProtocolMatchCondition Both 并避免只写 IPv4 前缀。

限速单位与带宽误判
PowerShell 的 -ThrottleRateActionBitsPerSecond 是位/秒；MB 是 MiB/s 语义，注意换算（30MB/s≈240Mbps）。先保守，再提升。

Wi-Fi 与 WMM 对齐（如有）
若你的香港节点还经由企业 Wi-Fi，WMM 的四类与 DSCP 的对应最好也一致（VO/VI/BE/BK）。微软文档中有映射表可参考。

GPO 生效范围
服务器适合用计算机级策略；如果你对特定用户会话做策略，记得用户级优先级规则，避免“以为生效但其实被另一侧覆盖”。

NLA/网络识别导致应用内置 QoS 不生效
个别场景（主要是客户端）要确保系统允许应用设置 DSCP 或由策略覆盖；思路是策略端强制，不要依赖应用自己标（Cisco 也有文档讨论 DSCP 标记开关）。

我给出的“模板化”策略清单（可直接作为基线）

如果你的会议平台只用其一（比如全部用 Teams），可以只保留对应三条 + 若干后台限速策略，维护成本更低。

跨地区网络的“现实主义”处理

路径选择：香港往美西 140–160ms、往新加坡 30–45ms、往伦敦 170–190ms 属于常态。QoS 解决的是拥塞时的排序与丢包控制，而不是缩短地理 RTT。

出口带宽预算：建议按“同时峰值会议数 × 每路码率 × 1.5 安全系数 + 背景限速和”估算。比如 5 路双向 1080p（1.5–2.5 Mbps/路，平台不同略差），预留 20–30 Mbps 给会议，再给后台固定 200–300 Mbps，上行 1Gbps 基本从容。

与上游协同：若你能控制上游网关/边界路由，建议信任 DSCP 并在出口做 CBWFQ/LLQ 类队列，Teams 的分级（EF/AF41/AF21）非常好落地。
Microsoft Learn

那晚我在机房都做了什么

• 三条 Teams（EF/AF41/AF21）+ Zoom、Meet 的 DSCP 策略落地；
• 两条后台限速策略，先把“仓库同步/对象拉取”压到 30MB/s；
• 用 Wireshark 现场看 DSCP 标记；
• 看交换机出口队列与拥塞监控；
• 会议质量恢复后，再把后台恢复到 50MB/s（不影响会）。
• 半小时搞定，没改动任何会议平台配置，也没有要求大家重进会议。

雨停了，空调的冷风把机房里的纸杯吹得微微打颤。那晚会后我把脚本和 GPO 模板归档成“香港节点基线”。后来每到有人抱怨“开会又卡了”，我就会问一句：先看 QoS 打没打上，后台是不是在抢路。运维很多时候不是“搞个大升级”，而是在拥塞发生的一瞬间，能不能把关键流量从杂乱里拎出来，给它一条好走的路。