通过

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

  • 项目

本文有助于排查使用远程桌面协议 （RDP） 短路径进行公用网络时出现的问题。

验证 STUN、TURN 服务器连接和 NAT 类型

可以验证与 STUN 和 TURN 终结点的连接，并通过运行可执行文件 avdnettest.exe来验证基本用户数据报协议（UDP）功能是否正常工作。 下面是 指向 avdnettest.exe 最新版本的下载链接 。

可以通过双击文件或从命令行运行该文件来运行 avdnettest.exe 。 如果连接成功，输出将如下所示：

Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server <IP Address:Port Number> ... OK
Checking ACS server <IP Address:Port Number> ... 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 级别超时之前触发。