管理網際網路和內部部署網路的連線能力

5 分鐘

受控網路的 RDP Shortpath 可在遠端桌面用戶端與工作階段主機之間，提供直接 UDP 傳輸。受控網路的 RDP Shortpath 可設定 RDP 資料的服務品質 (QoS) 原則。

Azure 虛擬桌面中的 QoS 允許對網路延遲較為敏感的即時 RDP 流量，「插隊」排在較不敏感的流量前面。下載新應用程式即為較不敏感流量的範例，因為下載時間多出幾秒並非大事。 QoS 會用 Windows 群組原則物件識別並標記即時串流中的所有封包，並協助網路為 RDP 流量提供專用部分的頻寬。

如果您所支援的大量使用者發生本單元所述的任何問題，則可能需要實作 QoS。僅有少數使用者的小型企業可能不需要 QoS，但此原則仍可能使其受惠。

如果沒有某種形式的 QoS，則可能出現下列問題：

抖動 – RDP 封包以不同速率送達，導致視覺效果和音訊問題。
封包遺失 – 封包遭卸除，導致重新傳輸並耗費額外時間。
延遲來回時間 (RTT) – RDP 封包花很長時間才觸達目的地，導致遠端應用程式的輸入和反應之間明顯延遲。

解決這些問題最簡單的方法，是同時增加內部與外流到網際網路的資料連線大小。由於此方法通常成本過高，您可透過 QoS 管理所擁有的資源，無需增加頻寬來提升效率。若要解決品質問題，建議您先使用 QoS，並僅在必要時增加頻寬。

要使 QoS 生效，請在整個組織中套用一致的 QoS 設定。路徑中任一部份無法支援 QoS 優先順序，都可能導致品質 RDP 工作階段降級。

服務佇列品質

要提供 QoS，網路裝置必須能夠分類流量，且能區分 RDP 與其他網路流量的差異。

網路流量一進入路由器，該流量就會放入佇列。如未設定 QoS 原則，則只會有一個佇列，所有資料會以相同的先進先出優先順序處理。也就是說，RDP 流量可能會卡在即使延遲幾毫秒也不會有問題的流量後方。

QoS 在資料網路建立虛擬「共乘通道」就是簡單的範例。這樣可讓某些型別的資料永遠不會或極少延遲。建立通道之後，您可以調整相對大小並更有效率地管理所擁有的連線頻寬，同時仍為組織使用者提供商務級體驗。

服務品質實作檢查清單

概括而言，請執行所列步驟來實作 QoS：

確定網路準備就緒。
確定已啟用受控網路的 RDP Shortpath - 反向連線傳輸不支援 QoS 原則。
在工作階段主機上實作 DSCP 標記插入。

當您準備實作 QoS 時，請記住下列指導方針:

到工作階段主機的路徑最短最理想。
不建議在兩者之間設有障礙，例如 Proxy 或封包檢查裝置。

確定網路準備就緒

如果您考慮實作 QoS，則應已決定頻寬需求及其他網路需求。

網路上的流量壅塞會大幅影響媒體品質。缺乏頻寬會導致效能降低，以及使用者體驗不佳。

VPN 考量

QoS 只有在用戶端與工作階段主機之間的所有連結上實作時，才可如預期運作。如果您在內部網路上使用 QoS，且使用者從遠端位置登入，則只能在內部的受控網路內設定優先權。雖然遠端位置可透過實作虛擬私人網路 (VPN) 接收受控連線，但因 VPN 會增加封包額外負荷，因此會在即時流量中產生延遲。

若您是使用受控連結的跨大陸全域組織，我們強烈建議使用 QoS，因為跟 LAN 比起來，這些連結的頻寬更為受限。

插入 DSCP 標記

您可以使用群組原則物件 (GPO) 實作 QoS，指示工作階段主機在 IP 封包標頭中插入 DSCP 標記，將其識別為特定型別的流量。路由器和其他網路裝置可在設定後辨識這些標記，將流量放在個別且優先順序較高的佇列之中。

您不妨將 DSCP 標記想成郵戳，藉此郵差可分辨傳遞的緊急程度與最佳排序方式，以便快速送達郵件。將網路設定為以 RDP 串流為優先之後，應能大幅降低遺失和延遲的封包。

所有網路裝置皆使用相同的分類、標記和優先順序後，應能減少或消除延遲/卸除的封包和抖動。就 RDP 而言，基本設定步驟為封包分類和標記。不過，若要成功實作端對端 QoS，則也需仔細讓 RDP 設定與基礎網路設定保持一致。 DSCP 值代表相應的已設定網路向封包或串流提供的優先順序。