与 FLOSS 替代品相比，TeamViewer 在两个方面更快：
- 实际会话之前的整个配置过程：确定 IP、穿过 NAT 和防火墙等，而在 TeamViewer 中只需输入 ID/PW，它就会通过 TeamViewer 的集中系统（这当然是一个信任问题！）。
- 远程查看/控制会话本身：VNC 解决方案的流畅度和响应速度远不如前者，通常会滞后几十秒，而在 Teamviewer 中，它几乎感觉是“实时的”，当然，除非大量屏幕内容以高频率发生变化（动画内容等）。
我很感激关于 #2 的技术解释。我无法弄清楚优化潜力在哪里，这使得 TeamViewer 速度更快。
答案1
VNC 效率低下 - 它使用射频滤波器. 它会不时地拍摄系统的快照，并告诉客户端系统不时地绘制 X 大小的框（RFB 协议就在这里。更高效的协议在帧缓冲区级别不起作用 -远程桌面协议例如，在 Windows 中使用内核级驱动程序nx缓存并压缩数据。
更有效的协议很可能如此
- 缓存数据并仅发送差异
- 接入主机操作系统的原生子系统
- 使用缓存和压缩来加速数据传输。
对于teamviewer来说，它很可能巧妙地利用了第一点和第三点——因为它似乎使用相同的客户端适用于 Windows 和 Linux，并使用其服务器来处理流量的连接和路由
答案2
我想强调的事实是，VNC 只是一个糟糕的比较点。
在 Linux 系统之间，正确配置的 xpra 可提供更好的性能 - 主要归功于支持基于 H.264 的有损压缩。
TeamViewer 支持的唯一有损压缩似乎是降低颜色深度和某种隔行更新，正如您所说，这对动画内容帮助不大。一个好的系统应该能够平稳地牺牲质量以保持合理的更新率。提到的 xpra 有点接近它，但老实说，它仍然做得很糟糕。
另一个问题是 TCP 与 UDP 协议。基于 TCP 的协议很容易受到高数据包丢失等影响，而且一旦您发送了一些数据，就必须传输这些数据 - 因此，单个大型更新意味着您的屏幕将挂起，直到它到达。特别是在连接速度较慢的情况下，这会使 VNC 无法使用，因为屏幕上的任何重大更改都意味着您要几分钟后才能看到任何更改。还可以比较 ssh 与 mosh 的纯文本。
不过，似乎还没有人能够发明出一种真正好的协议，这种协议要结合先进视频编解码器的高压缩比、UDP 的使用以及处理丢失数据包的良好方法、感知编码，可以检测文本的可读性，而不是“无用”的细节，自动平衡更新/传输速度与质量和编码速度，随着时间的推移，对未更新区域进行逐步平稳的质量改进，客户端缓存和差异化（虽然视频编码可以引用过去的帧，但它们与普通桌面内容并不完全匹配，而且您可以轻松地在客户端存储数百 MB 的参考数据）。换句话说：TeamViewer 所做的一切似乎都是不做完全愚蠢的事情（尽管 VNC 的借口主要是显示其年龄），我知道没有任何解决方案可以实现即使在今天也可能发生的任何巧妙技巧，更不用说人们可以想象到的所有技巧了。