我见过： 高延迟链路上的terminal服务器性能
但是我有一位客户，他们有兴趣将他们的系统基础架构迁移到总部大约有62毫秒延迟的数据中心。
该环境由三台Windows Server 2008 R2 RDS服务器，文件和打印服务以及Microsoft Exchange 2010组成。目前，这些服务均在vSphere 5.5群集上进行虚拟化。 当前有80个用户使用HP瘦客户机在本地连接到RDS系统。
由于设施问题以及异地和远程用户的增加，推动系统迁移到数据中心设施。 新网站将采用更高端的vSphere主机和全闪存存储。
连接到同位置设施将build立通过与多个ISP的站点到站点VPN和故障转移到位。
这是一个坏主意，但？ 我经常连接到这个站点进行RDP和SSH的维护工作，性能对我的使用情况来说是完全可以接受的。 用户正在使用基本的MS Office套件和几个轻量级的基于SSHterminal的ERP应用程序。
对于这种types的用户负载和Microsoft RDS，62ms是合理的吗？
我在全球有数千人每天连接和使用会计/办公软件。 只要他们的响应时间低于300毫秒，我们不会收到投诉，但ymmv。
作为概念certificate，我使用linux / netem盒子设置了我们的用户交换机之一，并且一直在推迟延迟/丢包，直到我开始投诉。 在本地复制networking条件，然后移动我的应用程序两次更容易。
我觉得这是主观的，因为有些用户不会感到满意，除非延迟就像本地桌面体验一样，其他用户也会很高兴，即使延迟为300ms也不会抱怨。
确实，延迟是一个用户体验杀手，但是，确切地说，个人感知是多less。
这是一个相当不错的video从TechEd 2014用户体验类似的场景（这个video是关于VDI，但它是一个类似的经验，远程桌面服务。）
https://www.youtube.com/watch?v=CcKAwzebHoc&feature=youtu.be
所以你可能会说，不要超过300毫秒。 62ms可能是“OK”。
这个问题不能得到普遍和客观的回答。 结果真的取决于工作量types和用户需求。 没有比UXtesting更好的了。
我经常从不同地点通过RDP远程工作，大部分时间通过LTE（4G）networking连接，提供类似于62毫秒的等待时间。 在这个时候，我在一个酒店，连接速度很慢〜1 Mbit / s，延迟时间约为27-28毫秒，不到你的情况的一半。 即使使用后者的价值，我也很难浏览网页或查看大图片（特别是没有AdBlock，graphics丰富的网站可以在Firefox中渲染几秒钟！）。 另外，使用Microsoft Word编写一个简单文档的尝试也因为低于平均的接口责任而产生了一些挫折（反过来，LibreOffice Writer感觉好多了）。 甚至不提及任何与video工作…我可以很舒适地工作的事情是MMC，Outlook邮件（在某种程度上），文件浏览和一般系统pipe理任务。
这个值对于远程系统pipe理和你经常做类似的任务并且有经验的人来说应该是可以的。 但是，如果是完全取代本地屏幕，我会期待挫折和抱怨。
有一件事要补充 – 我在Ubuntu下工作， rdesktop 1.7.1是我select的RDP客户端。 微软原有的客户端（或其他客户端）可能会进行一些优化，从而提高高延迟链接的性能。
除非您的客户通过此networking游戏，否则100-ms以下的延迟可能不会成为问题。 但是，某些graphics密集型应用程序（特别是video播放）可能会耗尽带宽，这会对延迟产生不利影响，并将其推向100 ms以上，令用户烦恼不已。
RDP 8（Server 2012和更高版本）确实为这些情况提供了优化（读取：有损压缩algorithm）。 此外，UDP传输支持将改善用户体验，并且延迟时间显着变化或者丢包率明显（> 0.1％）。 所以，如果你有任何这些，你可能想升级你的RD会话主机。