%20%E7%9A%84%E5%BB%B6%E8%BF%9F%E9%98%88%E5%80%BC%E6%98%AF%E5%A4%9A%E5%B0%91%EF%BC%9F.png)
我见过：高延迟链路上的终端服务器性能
但是我的一个客户有兴趣将他们的系统基础设施迁移到距离其总部约 62 毫秒延迟的数据中心。
该环境由三台 Windows Server 2008 R2 RDS 服务器、文件和打印服务以及 Microsoft Exchange 2010 组成。目前，它们全部在 vSphere 5.5 集群上虚拟化。目前共有 80 位用户使用 HP 瘦客户端本地连接到 RDS 系统。
由于设施问题以及异地和远程用户的增加，人们迫切希望将系统迁移到数据中心设施。新站点将配备更高端的 vSphere 主机和全闪存存储。
将通过具有多个 ISP 和故障转移功能的站点到站点 VPN 建立与共置设施的连接。
但这是个坏主意吗？我经常通过 RDP 和 SSH 连接到此站点进行维护工作，对于我的用例来说，性能是相当可以接受的。用户正在使用基本的 MS Office 套件和一些轻的基于SSH终端的ERP应用。
对于这种类型的用户负载和 Microsoft RDS 来说 62ms 是否合理？
答案1
我在全球有几千名员工每天连接并使用会计/办公软件。只要他们的响应时间低于 300 毫秒，我们就不会收到投诉，但 ymmv。
作为概念验证，我使用 Linux / netem 盒设置了我们的一个用户交换机，并不断增加延迟 / 数据包丢失，直到我开始抱怨。在本地复制网络条件比两次移动我的应用程序要容易得多。
答案2
我觉得这有点主观，因为有些用户除非延迟就像本地桌面体验一样，否则不会高兴，而其他用户即使延迟为 300 毫秒也会很高兴并且不会抱怨。
确实，延迟会影响用户体验，但具体影响有多大则取决于个人的认知。
这是来自 TechEd 2014 的一段非常精彩的视频，介绍了类似这种情况场景中的用户体验（该视频是关于 VDI 的，但它的体验与远程桌面服务类似。）
https://www.youtube.com/watch?v=CcKAwzebHoc&feature=youtu.be
因此您可能会说，永远不要超过 300 毫秒。62 毫秒可能“可以接受”。
答案3
这个问题无法真正得到普遍和客观的回答。结果确实取决于工作负载类型和用户需求。没有什么比 UX 测试更好了。
我经常通过 RDP 从不同位置进行远程工作，大多数时候通过 LTE（4G）网络连接，其延迟类似于 62 毫秒。此时此刻，我在酒店里，连接速度较慢，约为 1 Mbit/s，延迟约为 27-28 毫秒 - 还不到您案例中的一半。即使是后一个值，我在浏览网页或查看大型图形时也遇到了困难（尤其是没有 AdBlock，图形丰富的网站在 Firefox 中需要几秒钟才能渲染完成！）。此外，尝试使用 Microsoft Word 编写简单文档时也产生了一些挫败感，因为界面责任低于平均水平（反过来，LibreOffice Writer 感觉好多了）。更不用说视频工作了……我可以相当舒服地使用 MMC、Outlook 邮件（某种程度上）、文件浏览和一般的系统管理任务。
对于远程系统管理和您经常执行并有经验的类似任务，此值应该没问题。但如果要完全取代本地屏幕，我预计会感到沮丧和抱怨。
补充一点 - 我在 Ubuntu 下工作桌面1.7.1 是我选择的 RDP 客户端。Microsoft 的原始客户端（或其他客户端）可能进行了一些优化，可以提高高延迟链接的性能。
答案4
低于 100 毫秒的延迟可能不会成为问题，除非你的客户通过此网络进行游戏。但您可能会在某些图形密集型应用程序（尤其是视频播放）中耗尽带宽，这将对延迟产生不利影响并将其推至 100 毫秒以上，从而让您的用户感到烦恼。
RDP 8（Server 2012 及更高版本）确实针对这些场景进行了优化（阅读：有损压缩算法）。此外，UDP 传输支持将改善延迟差异很大或数据包丢失明显（>0.1%）的链接上的用户体验。因此，如果您有其中任何一种情况，您可能需要升级您的 RD 会话主机。