在 Microsoft Teams 中實作服務品質 (QoS)
本文適用於在 Microsoft Teams 中實作服務品質 (QoS) 的系統管理員和 IT 專業人員。
Microsoft Teams 中的服務品質 (QoS) 可讓您優先處理對網路延遲敏感的即時網路流量，而非較不敏感的流量。 例如，您會將語音和視訊串流優先於下載新的應用程式， (要多下載一秒並不會明顯) 。
QoS 會使用差異化服務代碼點 (DSCP) 標記搭配埠型 存取控制 清單 (ACL) 來識別、標記及分類即時串流中的所有封包。 這可確保語音、視訊和螢幕共用串流會受到以犧牲其他類型的流量為損失的接收處理方式。
如果沒有某種形式的 QoS，您可能會在語音和視訊中看到下列質量問題：
抖動 – 媒體封包的送達頻率不同，可能會導致通話中的字詞或音節遺失。
封包遺失 – 封包掉落，也可能會導致語音品質較低且語音難以理解。
延遲的往返時間 (RTT) – 媒體封包需要很長的時間才能到達目的地，這會導致交談中的兩方之間明顯延遲，並導致其他人互相交談。
如果您支援大量遇到本文所述問題之使用者，則應實作 QoS。 少數使用者的小型企業可能不需要 QoS，但如果發生網路延遲，應該考慮一下。
解決這些問題最不複雜的方法是增加內部和因特網的數據連線大小，但這種方法通常都是高成本禁止的。 QoS 可讓您管理您擁有的資源，而非新增頻寬。 若要解決質量問題，建議您先使用 QoS，然後在必要時新增頻寬。
若要讓 QoS 生效，您必須在整個組織中套用一致的 QoS 設定。 路徑中任何無法支援 QoS 優先順序的部分，都可能會降低通話、視訊和螢幕共用的品質。 您必須將設定套用至所有用戶電腦或裝置、網路交換器、路由器至因特網，以及 Teams 服務。
圖 1. 組織網路與 Microsoft 365 或 Office 365 服務之間的關係
QoS 實作檢查清單
下列檢查清單提供實作 QoS 所需步驟的概觀。 本文將詳細說明這些步驟。
請記住下列指導方針：
- Microsoft 365 的最短路徑是最佳的。
- 關閉埠會導致品質降低。
- 不建議在兩者之間使用任何障礙，例如 Proxy。
- 限制躍點數目：
- 用戶端到網路邊緣 – 3 到 5 個躍點
- MICROSOFT網路邊緣的 ISP – 3 個躍點
- Microsoft網路邊緣到最終目的地 – 不適用
如需設定防火牆埠的相關信息，請參閱 Office 365 URL 和 IP 範圍。
QoS 隊列簡介
若要提供 QoS，網路裝置必須具備將流量分類的方式，而且必須能夠區分語音或視訊與其他網路流量。
當網路流量進入路由器時，流量會進入佇列。 如果未設定 QoS 原則，則只會有一個佇列，且所有數據會被視為優先順序相同的初次入帳。 這表示語音流量 (對於延遲非常敏感，) 可能會卡在流量後面，而延遲幾毫秒則不成問題。
當您實作 QoS 時，您會使用數種壅塞式管理功能之一來定義多個佇列，例如 Cisco 的優先順序排程和 以類別為基礎的加權評定會佇列 (CBWFQ) 和避免壅塞功能，例如 加權隨機提早偵測 (WRED) 。
圖 2. QoS 隊列範例
簡單的類似是，QoS 會在您的數據網路中建立虛擬的「共車模式」，因此某些類型的數據永遠不會或很少發生延遲。 當您建立那些鏈接之後，您可以調整他們的相對大小，並更有效率地管理您擁有的連線頻寬，同時仍可為貴組織的使用者提供商務級體驗。
步驟 1. 確定您的網路已準備就緒
如果您考慮的是 QoS 實作，您應該已經決定您的 頻寬和其他網路需求。
網路上的流量囯塞會大幅影響媒體品質。 缺少頻寬會導致效能降低和用戶體驗不佳。 當您組織中的 Teams 採用和使用量增加時，您將需要監控和管理您的網路效能。 若要找出問題，然後使用QoS和選擇性頻寬新增來進行調整，請使用下列工具： 報告、 個別使用者通話分析，以及 呼叫品質儀錶板 (CQD) 。
VPN 考慮
只有在來電者之間的所有鏈接上實作 QoS 時，QoS 才能如預期般運作。 如果您在內部網路上使用QoS，且使用者從遠端位置登入，則只能在內部受管理的網路內排列優先順序。
雖然遠端位置可以透過實作虛擬專用網 (VPN) 來接收受管理的連線，但 VPN 固有的會增加封包的負荷，並在即時流量中造成延遲。 建議您避免透過 VPN 執行實時通訊流量。
在具有跨洲受管理連結的全域組織中，我們建議使用QoS，因為與LAN比較時，這些鏈接的頻寬有限。
步驟 2. 選取 QoS 實作方法
您可以使用下列方法來實作 QoS：
- 埠型 DSCP (差異化服務代碼點) 路由器標記
- 用戶端在IP封包標題中插入 DSCP 標記
這兩種方法都是以 DSCP 標記為基礎。 DSCP 標記可以貼上郵資戳，表示郵遞工作十分緊急，以及如何排序包裹以加快遞送速度。 將網路設定為優先於即時媒體串流之後，遺失的封包和延遲封包應該會大幅減少。
路由器上的埠標記
使用埠式標記時，您網路的路由器會檢查內送封包以判斷要使用哪些埠。 如果封包是使用特定埠或埠範圍送達，路由器會將封包識別為特定媒體類型。 路由器接著將封包放在該類型的佇列中，將預先確定的 DSCP 標記新增至 IP 封包標頭，讓其他裝置可以辨識其流量類型，並在其佇列中提供優先順序。
您可以使用網路路由器上的 存取控制 清單 (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. 針對每種媒體類型選擇初始埠範圍
不同即時串流工作負載的埠範圍相對大小會設定專屬於該工作負載之可用頻寬總計的比例。 使用郵政服務類比：含「Air Mail」戳記的信件可能會在一小時內送達最近的機場，而標示為「大量郵件」的小型包裹則可等候一天，然後再前往一系列的裝載品。
無論 DSCP 標記是由用戶端指派，還是由網路本身根據 ACL 設定指派，DSCP 值都會告訴對應設定的網路提供封包或串流的優先順序。 每一種媒體工作負載都會得到自己的唯一 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 原則的影響。 唯一會繼續使用動態埠的用戶端是瀏覽器型用戶端 (可讓參與者使用其瀏覽器) 加入會議的用戶端。
雖然 iOS 和 Android (Mac 和行動裝置) 用戶端使用這些來源埠範圍，但這些用戶端會針對音訊 (EF) 和視訊及應用程式/螢幕共用使用硬編碼的值， (AF41) 。 這些值無法設定。
如果您之後需要調整埠範圍以改善用戶體驗，埠範圍無法重疊且應彼此相鄰。
目前無法自定義用於通話和會議訊號的埠範圍。
步驟 4. 實作 QoS 設定
實作客戶端和網路裝置的 QoS 設定，並決定您要如何處理會議的媒體流量。
如有先決條件，請在Teams 管理員中心全域啟用QoS。 請參閱 在 Teams 系統管理中心中設定 QoS ，以取得啟用即時 媒體流量設定的插入服務品質 (QoS) 標記的 詳細數據。
如需設定 Windows 端點 DSCP 標記的相關信息，請參閱 在 Teams 用戶端中實作 QoS。
注意事項
在從傳統Teams轉換到新Teams的過程中，可執行名稱已從 teams.exe (傳統版Teams) 變更為 ms-teams.exe (新的Teams) 。
Mac 和行動 (iOS 和 Android) 用戶端針對音訊 (EF) 和視訊及應用程式/螢幕共用 (AF41) 使用硬編碼的值。 Teams 電話 裝置也會使用音訊 (EF) 的預設值。 不過，您必須在Teams 管理員中心全域啟用QoS，此功能才能正常運作。 請參閱 在 Teams 系統管理中心中設定 QoS ，以取得啟用 [ 插入服務品質] (QoS) 即時 媒體流量標記] 設定的詳細數據。
如需設定 Windows 和 Android) Microsoft Teams 會議室 (DSCP 標記的相關信息，請參閱 Teams 會議室 裝置上的服務品質 (QoS) 設定。
如需有關為執行 Windows 10 團隊版 OS 的 Surface Hub 裝置設定 DSCP 標記的相關信息，請參閱使用 MDM 提供者管理 Surface Hub。
如需實作路由器 QoS 的相關信息，請參閱製造商的檔。
在網路裝置上設定 QoS 可能包括使用埠型 存取控制 清單 (ACLs) 、定義 QoS 佇列和 DSCP 標記，或所有這些標記。
重要
我們建議使用用戶端來源埠以及「任何」的來源和目的地 IP 位址來實作這些 QoS 原則。 這會同時掌握內部網路上的內送和外寄媒體流量。
步驟 5. 驗證 QoS 實作
若要讓 QoS 生效，DSCP 值集必須在通話的兩端顯示。 藉由分析 Teams 用戶端產生的流量，您可以確認當 Teams 工作負載流量透過網路移動時，DSCP 值沒有變更或去除。
最好是在網路出口點擷取流量。 您可以在開關或路由器上使用埠鏡像來協助解決此問題。
步驟 6. 管理來源埠
針對 Teams，在您選擇每個媒體類型的初始埠範圍之後 (參閱步驟 3) ，您需要視需要監控及調整不同工作負載所使用的 QoS 來源埠。 特定媒體類型可能需要較多或較少的埠。
如需如何監視和管理埠的相關信息，請參閱下列內容：
請注意，您可以調整埠範圍，但無法設定 DSCP 標記。