對公用網路的 RDP Shortpath 進行疑難排解

如果您在使用公用網路的 RDP Shortpath 時遇到問題，請使用本文中的資訊來協助疑難排解。

驗證 STUN/TURN 伺服器連線能力和 NAT 類型

您可以驗證 STUN/TURN 端點的連線能力，並執行 avdnettest.exe 可執行檔來驗證基本 UDP 功能是否正常運作。 下列是最新版 avdnettest.exe 的下載連結。

您可以按兩下檔案，或從命令列執行 avdnettest.exe。 如果連線成功，輸出看起來如下列所示:

Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server 20.202.68.109:3478 ... OK
Checking ACS server 20.202.21.66:3478 ... OK

You have access to TURN servers and your NAT type appears to be 'cone shaped'.
Shortpath for public networks is very likely to work on this host.

Log Analytics 中記錄的錯誤資訊

下列是您可能會在 Log Analytics 中看到的一些錯誤標題及其意義。

ShortpathTransportNetworkDrop

針對 TCP，我們會區分兩個不同的路徑: 工作階段主機至閘道，以及用戶端的閘道。但這對 UDP 沒有意義，因為閘道並不存在。 TCP 的另一個區別在於，在許多情況下，其中一個端點或中間的一些基礎結構會產生 TCP 重設封包 (RST 控制位元)，這會導致 TCP 連線硬關機。 其中的運作原理是因為作業系統和部分路由器也會處理 TCP RST (以及用於正常關機的 TCP FIN)，但應用程式並不會進行處理。 這表示如果應用程式當機，Windows 會向同儕節點通知 TCP 連線已中斷，但 UDP 不存在這類機制。

大部分連線錯誤 (例如 ConnectionFailedClientDisconnect 和 ConnectionFailedServerDisconnect)，都是由 TCP 重設封包所造成，而並非由逾時所導致。 因為作業系統或路由器無法向 UDP 發出任何訊號，所以得知同儕節點中斷的唯一方法是透過逾時訊息。

ShortpathTransportReliabilityThresholdFailure

如果特定封包未通過，那麼即使連線未失效，也會觸發此錯誤。 因為封包最多會重新傳送 50 次，所以此情況不太可能發生，但也許會發生在下列情節中:

1. 連線在突然停止運作之前非常快速且穩定。 在封包宣告遺失之前所需的逾時，取決於用戶端和工作階段主機之間的來回時間 (RTT)。 如果 RTT 非常低，其中一端可能會嘗試極度頻繁地重新傳送封包，因此達到 50 次嘗試所需的時間，可能小於通常的逾時值 17 秒。

2. 封包非常大。 可以傳輸的封包大小上限會受到限制。 系統會探查封包的大小，但大小可能會有所變動，而且有時會縮小。 如果發生這種情況，則傳送的封包可能太大，而且會持續失敗。

ConnectionBrokenMissedHeartbeatThresholdExceeded

這是 RDP 層級逾時。 由於設定錯誤，系統有時會在 UDP 層級逾時之前觸發 RDP 層級逾時。