你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

排查公用网络的 RDP 短路径问题

项目
11/02/2024

如果在对公共网络使用 RDP 短路径时遇到问题，请使用本文中的信息来帮助进行故障排除。

正在验证 STUN/TURN 服务器连接和 NAT 类型

可以运行可执行文件 avdnettest.exe 以验证与 STUN/TURN 终结点的连接，并验证基本 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 次，因此这种情况不太可能发生，但在以下情况下可能发生:

连接在突然停止工作之前非常快速、稳定。在声明数据包丢失之前所需的超时时间取决于客户端和会话主机之间的 RTT (往返时间)。如果 RTT 非常低，则一方可以非常频繁地尝试重新发送数据包，因此达到 50 次尝试所需的时间可能少于通常的 17 秒超时值。
数据包非常大。可以传输的最大数据包大小是有限的。会探测数据包的大小，但它可能会波动，有时会收缩。如果发生这种情况，则意味着发送的数据包可能太大，且会一直失败。

ConnectionBrokenMissedHeartbeatThresholdExceeded

这是 RDP 级别超时。由于配置错误，RDP 级别超时有时会在 UDP 级别超时之前触发。

通过