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