![当主机处于 CPU 负载下时 RDP 连接超时](https://linux22.com/image/745490/%E5%BD%93%E4%B8%BB%E6%9C%BA%E5%A4%84%E4%BA%8E%20CPU%20%E8%B4%9F%E8%BD%BD%E4%B8%8B%E6%97%B6%20RDP%20%E8%BF%9E%E6%8E%A5%E8%B6%85%E6%97%B6.png)
3 年来,我经常观察到以下情况:当我们的服务器忙于压缩备份(7z、所有核心、空闲优先级)时,第一次尝试通过 RDP 连接到本地网络上的任何其他计算机都会导致超时。第二次尝试连接并立即打开。取消并快速重试连接无济于事,我不得不等待 60 秒。
当我使用 Wireshark 记录连接两端的交换时,我发现在前 400 毫秒内交换了大约 6kB 的数据,然后通信停止。60 秒后,远程端点发送 RST、ACK,RDP 对话继续旋转 30 秒,然后声明超时。两次捕获都没有什么明显错误,而且在发生这种情况时,它们似乎没有进行任何相关的网络通信。
奇怪的是,如果我取消连接并在等待一段时间后重试,它最终会连接。我仍然看到第一个连接的 RST 数据包出现在 60 秒标记处。超时似乎是全局问题。
那么...知道我在这里处理什么吗?
答案1
多年来,我注意到各种服务器上都存在类似的行为......我发现在远程服务器上添加以下注册表修改,可以让我延长默认的 60 秒 RDP 超时时间,然后帐户将登录:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
LogonTimeout
REG_DWORD
十进制:240
(秒)
您可以使用以下方式轻松添加此新的注册表值REG.EXE
在提升的命令提示符上执行命令(以管理员身份运行):
REG.EXE ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v LogonTimeout /t REG_DWORD /d 240
(将该240
值调整为 以上的任何值60
。该值以秒为单位。)
请让我知道这是否解决了您的问题!
答案2
经过很长时间的观察,我发现问题会随机出现,即使服务器没有负载,现在我相当确信原因是 RDP 远程音频。尽管用于连接网络上其他主机的管理服务器上的配置文件已禁用远程音频,但我的 PC 上用于连接管理服务器的配置文件已启用它。
远程音频功能一直不稳定。有时它工作正常。有时它会延迟 3 秒播放音频。有时它会开始卡顿。而且经常会在一段时间没有播放后掉线 - 音频设备仍然存在,但没有声音传来。大概是 UDP 会话超时。重新连接可以暂时修复它,但它也会删除并重新添加音频设备,这会使一堆假设该设备是持久的软件出错。
本周,我发现问题持续了好几个小时。然后我的 RDP 会话由于网络问题短暂断开。重新连接后,问题突然消失。但一小时后,我发现它又出现了。我终于进入我的 PC 配置文件并禁用了远程音频,然后重新连接。现在已经过了一天多,RDP 连接立即打开。缺点是我现在没有远程音频了。
因此,我假设发生的情况是,在建立连接时,服务器上的 RDP 客户端尝试对丢失的音频会话执行某些操作,需要 60/90 秒才能超时,然后我猜会暂时将其标记为不可用。这可以解释为什么在等待此超时时我没有看到服务器和其他主机之间有任何流量。
编辑:进一步测试发现了以下行为:
- 如果音频设备闲置几分钟,它就会出现故障。
- 故障发生在 TCP 和 UDP 上,因此不是 NAT 超时问题。
- 在发生故障期间,扬声器声音测试将显示音量级别但不发出任何声音,将停滞 10-20 秒然后播放,或者将停滞 1-2 分钟然后显示故障弹出窗口。
我尝试搜索“rdp audio ceases working”,发现serverfault.com/q/1076031(audiodg 在空闲 5 分钟后停止,并且启动延迟较长),指向https://superuser.com/q/994536(audiodg 重型 catroot 扫描),指向https://superuser.com/q/584746。一个答案暗示,l3codeca.acm 上缺少嵌入签名,导致每次访问音频设备时都会重新抓取 System32\catroot(2012R2 上的 20000 个文件中的 350 MB)。如果此操作以低优先级运行,则可以解释 CPU 繁忙时超时和播放延迟的情况。
我已经应用了 DisableProtectedAudioDG 解决方法,现在我发现即使在长时间空闲后音频仍能继续工作,并且即使启用了音频,远程连接也会立即打开。