在 Microsoft Teams 中实现服务质量 (QoS)
Microsoft Teams 中的服务质量 (QoS) 允许对网络延迟敏感的实时网络流量 (例如，语音或视频流) 在不太敏感 (（例如下载新应用）之前“排队”，其中多下载一秒) 。 QoS 使用 Windows 组策略 对象和基于端口的访问控制列表来标识和标记实时流中的所有数据包。 这有助于网络为语音、视频和屏幕共享流提供网络带宽的专用部分。
如果支持一大群遇到本文所述的任何问题的用户，则可能需要实现 QoS。 用户很少的小型企业可能不需要 QoS，但即使存在 QoS，也应有所帮助。
如果没有某种形式的 QoS，你可能会在语音和视频中看到以下质量问题：
- 抖动 - 以不同速率到达的媒体数据包，这可能导致通话中缺少单词或音节
- 数据包丢失 - 数据包丢弃，这还可能导致语音质量降低和难以理解语音
- RTT) (往返时间延迟 - 媒体数据包需要很长时间才能到达目的地，这会导致双方在对话中明显延迟，并导致人们相互交谈
解决这些问题最不复杂的方法是在内部和外部到 Internet 增加数据连接的大小。 由于这通常是成本高昂的，因此 QoS 提供了一种方法来更有效地管理你拥有的资源，而不是增加带宽。 若要解决质量问题，建议首先使用 QoS，然后仅在必要时添加带宽。
若要使 QoS 生效，必须在整个组织中应用一致的 QoS 设置。 无法支持 QoS 优先级的路径的任何部分都可能会降低通话、视频和屏幕共享的质量。 这包括将设置应用于所有用户电脑或设备、网络交换机、路由器到 Internet 以及 Teams 服务。
图 1. 组织网络与 Microsoft 365 或Office 365服务之间的关系
QoS 实现清单
概括而言，执行以下操作以实现 QoS：
实现 QoS 设置：
在使用 组策略 对象 (GPO 的客户端上，) 设置客户端设备端口范围和标记。
在路由器上 (查看制造商文档) 或其他网络设备。 这可能包括基于端口访问控制列表 (ACL) ，或者仅定义 QoS 队列和 DSCP 标记，或所有这些标记。
重要
建议使用客户端源端口以及源和目标 IP 地址“any”实现这些 QoS 策略。 这将捕获内部网络上的传入和传出媒体流量。
通过分析网络上的 Teams 流量来验证 QoS 实现。
在准备实现 QoS 时，请记住以下准则：
- Microsoft 365 的最短路径是最佳选择。
- 关闭端口只会降低质量。
- 不建议在两者之间使用任何障碍，例如代理。
- 限制跃点数：
- 客户端到网络边缘 - 3 到 5 个跃点
- ISP 到 Microsoft 网络边缘 - 3 个跃点
- Microsoft 网络边缘到最终目标 - 不相关
有关配置防火墙端口的信息，请转到Office 365 URL 和 IP 范围。
确保网络已准备就绪
如果正在考虑 QoS 实现，则应已确定带宽要求和其他 网络要求。
网络之间的流量拥塞将极大地影响媒体质量。 带宽不足会导致性能下降和用户体验不佳。 随着 Teams 采用和使用的增长，使用报告、每用户呼叫分析和通话质量仪表板 (CQD) 来识别问题，然后使用 QoS 和选择性带宽添加进行调整。
VPN 注意事项
QoS 仅在调用方之间的所有链接上实现时按预期工作。 如果在内部网络上使用 QoS，并且用户从远程位置登录，则只能在内部托管网络中设置优先级。 尽管远程位置可以通过实现虚拟专用网络 (VPN) 来接收托管连接，但 VPN 本身会增加数据包开销，并在实时流量中造成延迟。 建议避免通过 VPN 运行实时通信流量。
在具有跨大洲的托管链接的全球组织中，我们强烈建议使用 QoS，因为与 LAN 相比，这些链接的带宽有限。
QoS 队列简介
若要提供 QoS，网络设备必须能够对流量进行分类，并且必须能够区分语音或视频与其他网络流量。
当网络流量进入路由器时，流量将放入队列中。 如果未配置 QoS 策略，则只有一个队列，并且所有数据都被视为具有相同优先级的先入先出。 这意味着语音流量 (对延迟非常敏感，) 可能会卡在流量后面，其中延迟几毫秒不会成为问题。
实现 QoS 时，可使用多个拥塞管理功能之一定义多个队列，例如 Cisco 的优先级队列和 基于类的加权公平队列 (CBWFQ) 和拥塞避免功能，例如 加权随机早期检测 (WRED) 。
图 2. QoS 队列示例
一个简单的类比是，QoS 在数据网络中创建虚拟“拼车通道”，因此某些类型的数据永远不会或很少遇到延迟。 创建这些通道后，可以调整其相对大小并更有效地管理拥有的连接带宽，同时仍为组织的用户提供企业级体验。
选择 QoS 实现方法
可以通过基于端口的标记实现 QoS，在网络路由器上使用访问控制列表 (ACL) 。 基于端口的标记是最可靠的方法，因为它适用于混合 Windows、Mac 和 Linux 环境，并且最容易实现。 移动客户端不提供使用 DSCP 值标记流量的机制，因此它们需要此方法。
使用基于端口的标记，网络路由器会检查传入数据包，如果数据包是使用特定端口或端口范围到达的，它会将其标识为特定媒体类型，并将其放入该类型的队列中，向 IP 数据包标头添加预先确定的 DSCP 标记，以便其他设备可以识别其流量类型，并在其队列中为其指定优先级。
尽管基于端口的标记跨平台工作，但它仅标记 WAN 边缘的流量 (不会一直) 客户端计算机，并产生管理开销。 有关实现此方法的说明，请参阅路由器制造商提供的文档。
插入 DSCP 标记
还可以通过使用 组策略 对象 (GPO) 来实现 QoS，以指示客户端设备在 IP 数据包标头中插入 DSCP 标记，将其标识为特定类型的流量 (例如语音) 。 路由器和其他网络设备可以配置为识别这一点，并将流量置于单独的较高优先级队列中。
尽管此方案完全有效，但它仅适用于已加入域的 Windows 客户端。 不会为未加入域的 Windows 客户端的任何设备启用 DSCP 标记。 其他客户端（例如运行 macOS 的客户端）具有硬编码标记，并且将始终标记流量。
在加号方面，通过 GPO 控制 DSCP 标记可确保所有已加入域的计算机都接收相同的设置，并且只有管理员才能管理这些设置。 可以使用 GPO 的客户端将在原始设备上标记，然后配置的网络设备可以通过 DSCP 代码识别实时流，并为其指定适当的优先级。
最佳做法
如果可能，我们建议将终结点上的 DSCP 标记和路由器上基于端口的 ACL 组合在一起。 使用 GPO 捕获大多数客户端，以及使用基于端口的 DSCP 标记可确保移动、Mac 和其他客户端仍能获得 QoS 处理， (至少部分) 。
DSCP 标记可以比做邮票，这些邮票向邮政工作者指示交货有多紧急，以及如何最好地对邮票进行排序以便快速交付。 将网络配置为优先处理实时媒体流后，丢失的数据包和延迟的数据包应会大大减少。
网络中的所有设备使用相同的分类、标记和优先级后，可以通过更改分配给每种流量类型的队列的端口范围大小来减少或消除延迟、丢弃的数据包和抖动。 从 Teams 的角度来看，最重要的配置步骤是数据包的分类和标记。 但是，若要使端到端 QoS 成功，还需要仔细将应用程序的配置与基础网络配置保持一致。 完全实现 QoS 后，持续管理就是根据组织的需求和实际使用情况调整分配给每种流量类型的端口范围的问题。
为每个媒体类型选择初始端口范围
DSCP 值指示相应配置的网络为数据包或流提供什么优先级，无论 DSCP 标记是由客户端分配的，还是基于 ACL 设置的网络本身。 每个媒体工作负载都会获得自己唯一的 DSCP 值， (其他服务可能允许工作负载共享 DSCP 标记，Teams 不) ，以及用于每种媒体类型的已定义且单独的端口范围。 其他环境可能已有现有的 QoS 策略，这有助于确定网络工作负载的优先级。
不同实时流式处理工作负载的端口范围的相对大小设置专用于该工作负载的总可用带宽的比例。 回到我们早期的邮政类比：带有“航空邮件”邮票的信件可能会在一小时内被带到最近的机场，而标有“批量邮件”标记的小包裹可以等待一天，然后乘坐一系列卡车在陆地上行驶。
建议的初始端口范围
| 媒体流量类型 | 客户端源端口范围 | 协议 | DSCP 值 | DSCP 类 |
|---|---|---|---|---|
| 音频 | 50,000–50,019 | TCP/UDP | 46 | 加速转发 (EF) |
| 视频 | 50,020–50,039 | TCP/UDP | 34 | 保证转发 (AF41) |
| 应用程序/屏幕共享 | 50,040–50,059 | TCP/UDP | 18 | 保证转发 (AF21) |
使用这些设置时，请注意以下事项：
如果计划在将来实现 ExpressRoute，但尚未实现 QoS，我们建议遵循指南，以便发送方与接收方的 DSCP 值相同。
所有客户端（包括移动客户端和 Teams 设备）都将使用这些端口范围，并且将受到你实施的任何使用这些源端口范围的 DSCP 策略的影响。 将继续使用动态端口的唯一客户端是基于浏览器的客户端 (客户端，这些客户端允许参与者使用其浏览器) 加入会议。
尽管 Mac 客户端使用相同的端口范围，但它也对音频 (EF) 和视频和应用程序/屏幕共享使用硬编码值， (AF41) 。 这些值不可配置。
如果以后需要调整端口范围以改进用户体验，则端口范围不能重叠，应彼此相邻。
将 QoS 迁移到 Teams
如果以前已部署Skype for Business Online，包括 QoS 标记和端口范围，现在正在部署。 Teams 将遵循现有配置，并将使用与 Skype for Business 客户端相同的端口范围和标记。 在大多数情况下，不需要其他配置。
注意
如果通过 组策略 使用应用程序名称 QoS 标记，则必须添加 Teams.exe 作为应用程序名称。
使用 PowerShell 在 Windows 上的 Teams 中实现 QoS
设置音频的 QoS
new-NetQosPolicy -Name "Teams Audio" -AppPathNameMatchCondition "ms-teams.exe" -IPProtocolMatchCondition Both -IPSrcPortStartMatchCondition 50000 -IPSrcPortEndMatchCondition 50019 -DSCPAction 46 -NetworkProfile All
设置视频的 QoS
new-NetQosPolicy -Name "Teams Video" -AppPathNameMatchCondition "ms-teams.exe" -IPProtocolMatchCondition Both -IPSrcPortStartMatchCondition 50020 -IPSrcPortEndMatchCondition 50039 -DSCPAction 34 -NetworkProfile All
设置用于共享的 QoS
new-NetQosPolicy -Name "Teams Sharing" -AppPathNameMatchCondition "ms-teams.exe" -IPProtocolMatchCondition Both -IPSrcPortStartMatchCondition 50040 -IPSrcPortEndMatchCondition 50059 -DSCPAction 18 -NetworkProfile All
在 Teams 管理中心管理源端口
在 Teams 中，应主动管理不同工作负载使用的 QoS 源端口，并根据需要进行调整。 参考 为每个媒体类型选择初始端口范围中的表，端口范围是可调整的，但 DSCP 标记不可配置。 实现这些设置后，你可能会发现给定媒体类型需要更多或更少的端口。 在实施 Teams 后，应使用每用户呼叫分析和通话质量仪表板 (CQD) 来决定调整端口范围，并根据需要定期更改。
注意
如果已根据 Skype for Business Online 的源端口范围和 DSCP 标记配置 QoS，则相同的配置将应用于 Teams，并且不需要对映射进行进一步的客户端或网络更改，不过你可能必须设置 Teams 中使用的范围，以匹配为 Skype for Business Online 配置的范围。
如果以前已在本地部署Skype for Business Server，则可能需要重新检查 QoS 策略。 调整策略以匹配已验证的端口范围设置，为 Teams 提供高质量的用户体验。
验证 QoS 实现
若要使 QoS 有效，GPO 设置的 DSCP 值需要在调用的两端存在。 通过分析 Teams 客户端生成的流量，可以验证当 Teams 工作负载流量通过网络时，DSCP 值是否未更改或剥离。
最好是在网络出口点捕获流量。 可以在交换机或路由器上使用端口镜像来帮助执行此操作。
为其他设备实现 QoS
阅读这些主题，了解如何为 Intune、Surface、iOS、Android 和 Mac 实现 QoS
相关主题
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈