我们在美国华盛顿特区有一台服务器，可以从美国、印度、南亚和东南亚访问。它有 128GB RAM、CPU 和 Cent OS 7 + GNOME 桌面，并且运行 VNC 服务器 - 服务器可以通过 VNC 查看器或 Guacamole-on-vnc 访问。我们还尝试了 Nomachine 服务器-客户端对。
我们在桌面上遇到了一些迟缓问题，例如将窗口从一个地方移动到另一个地方、在 GVIM 中滚动等等。这会降低生产力。Gucamole 比 VNC 更好（可能也是 nomachine），但问题仍然很明显。
下面是一次访问的延迟图。
在跨国公司中，我们发现从印度访问美国服务器或反之亦然，没有延迟。这可能不如在同一个国家/地区使用服务器那么顺畅，但您几乎可以在其中工作。但在我们的案例中并非如此。
**有人可以帮忙在这里找到解决方案吗，例如-
- GRE 隧道或 VPN 等用于创建专用路径/删除从美国到南亚/东南亚的跳跃，并在印度登陆等。
- 任何升级版本的桌面/远程访问机制。
- 或者最好在印度租一台服务器（我们也这么想）。
任何建议都将不胜感激。**
答案1
你无法改变底层延迟。租用离用户更近的服务器似乎是唯一且最好的解决方案。
答案2
您需要的答案由@joeqwerty 给出：
你无法改变底层延迟。租用离用户更近的服务器似乎是唯一且最好的解决方案。
此外，正如@Michael Hampton 所评论的那样，您不能超越光速，否则您将有资格获得明年的诺贝尔物理学奖。您必须假设光纤通道中的光速为 2×10 8 m/s 或更低，因为它不是真空，所以实际的下限将是 150ms（RTT）。
可能存在可以减少跳数（中间路由器）的技术，例如隧道（GRE 或某些 VPN）。隧道不会影响延迟因为它仍然基于底层网络，或者承运人。物理上它们仍然或多或少地经过相同的路径，并且会经历相同的延迟以及数据包丢失率。
租用 IPLC 和 IEPL 等专线能减少延迟，但我怀疑它们能否让您的远程桌面成功。IPLC 在某种程度上类似于隧道，但具有可靠的带宽和延迟，并避免了公共互联网中的大部分拥塞。IPLC 仍然是共享的，并且基于 TDM。IEPL 更好，更昂贵，但您可以完全控制链接。IEPL 线路中较少的中间路由器（与 IPLC 相比）也进一步降低了延迟，接近光速。
获得更多地理位置靠近用户的服务器是唯一的解决方案。
答案3
我们在印度有员工，他们与美国的延迟时间在一分钟/小时/天之间变化。所以我很了解你的问题。
另一种选择是向站点提供具有专用 CIR（承诺信息速率）的更高质量的链路，如果未达到这些 CIR，则提供惩罚条款。
缺点是，此类链接通常比普通互联网链接贵得多。而且，如果您的员工在家办公，则必须基于互联网，因此这只是一种链接。
您租用的是哪种主机？如果是 AWS 等云提供商的虚拟机，请考虑将实例迁移到更近的站点，以缩短距离。这样做的缺点是，现在美国使用相同服务的人距离更远。
因此，您可以使用他们的客户端 VPN 和附近的端点（孟买、新加坡、日本等）以及 AWS 传输来将这些数据进行国际传输。这不再是互联网流量。
我相信其他云提供商也有类似的产品，比如谷歌云、Azure 等。
缺点是每件小事都要花几美分，但是小事太多了，账单很快就会增加。
最后，如果您正在托管一个物理主机，那么请考虑询问您的 DC 他们可以提供什么帮助。
答案4
为了支持尝试 RDP 的建议，众所周知，RDP 在低质量连接上表现良好，xrdp 是 Linux 的一个实现：http://xrdp.org/.Guacamole 可能也支持它：https://guacamole.apache.org/doc/gug/configuring-guacamole.html#rdp