为什么 VNC（作为一种协议，而不是我的特定连接）这么慢，尤其是在 2021 年？尤其是与 nvidia gamestream 之类的相比？

Question

这个问题一直萦绕在我的脑海里 -- 而我却无法完全理解？除非 VNC 自创建以来就没有进行过任何开发，并且没有跟上多年来开发的不同编码/解码/传输技术。

我的情况是这样的：

• 2 台 Linux 机器连接到路由器
• Linux 计算机 A (LMA) 通过 VNC 连接到 Linux 计算机 B (LMB)
• 从 LMA 上的 LMB 观察到的 VNC 会话似乎每秒大约有 4-6 帧，无论质量或色彩深度和质量如何。

这很令人沮丧，因为我使用 nvidia Gamestream 以 60fps 的速度在客厅的电视上播放流媒体游戏和以 75fps 的速度无线连接到我的 VR 耳机。当我有笔记本电脑时，我也更喜欢使用 nvidia gamestream 进行远程桌面。笔记本电脑 -> Nvidia gamestream 到 Windows PC -> Linux VM -> 远程编程时间（它可能看起来很复杂，但它比 VNC/RDP 性能更高、响应更快）

所以，我的问题的根源是：

• 为什么 VNC 这么糟糕？
• 为什么 RDP 也不好（但在刷新率方面略好一些，在 Linux 上它与 VNC 的工作方式不同，所以对我来说不是一个选择）
• 是否可以使用其他远程控制协议？
• 当我远程控制我的 Windows 机器时，我使用月光，它使用 nvidia gamestream，这是迄今为止我拥有的最佳远程桌面体验——我只是怀疑 nvidia 是否会支持 gamestream 的 linux 主机

---

证明两台机器之间有“足够带宽”，使用iperf3

使用 ssh 端口转发（与我使用的 VNC 相同）

# on the client
❯ ssh -XY -l me -L 5201:localhost:5201 192.168.1.17
# welcome message on the server, etc
❯ iperf3 -s -B 0.0.0.0 -V
Linux Calypso 5.11.0-17-generic #18-Ubuntu SMP Thu May 6 20:10:11 UTC 2021 x86_64
-----------------------------------------------------------
Server listening on 5201

在客户端上：

❯ iperf3 -c localhost -R -p 5201 -V -t 5
iperf 3.7
Linux Athena 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:39:42 UTC 2021 x86_64
Control connection MSS 32768
Time: Mon, 31 May 2021 16:10:25 GMT
Connecting to host localhost, port 5201
Reverse mode, remote host localhost is sending
      Cookie: wzbvh5iistp5fq3bzz7iaenrr46ptro3md7y
      TCP MSS: 32768 (default)
[  5] local 127.0.0.1 port 44766 connected to 127.0.0.1 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 5 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   108 MBytes   904 Mbits/sec                  
[  5]   1.00-2.00   sec   107 MBytes   897 Mbits/sec                  
[  5]   2.00-3.00   sec   109 MBytes   911 Mbits/sec                  
[  5]   3.00-4.00   sec   112 MBytes   938 Mbits/sec                  
[  5]   4.00-5.00   sec   111 MBytes   933 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-5.00   sec   558 MBytes   935 Mbits/sec    0             sender
[  5]   0.00-5.00   sec   546 MBytes   916 Mbits/sec                  receiver
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

iperf Done.

Answer 1

两个原因：

1. 因为 VNC 诞生的时代，硬件视频压缩还不存在
2. 由于“快速”视频压缩和传输依赖于有损压缩技术。

VNC 预计忠实通过网络连接逐像素重建远程桌面。它可能使用基于 CPU 的无损压缩技术来减少带宽量，但理论上它是像素完美的。以无损格式以每秒 60 帧的速度传输 1920 x 1080 x 32 位，速度略低于 500MB/s（兆字节，而不是兆比特），即使对于“优秀”的现代互联网连接来说，这也是不现实的。VNC 使用的技术包括仅发送因此而发生变化的数据块，在大多数静态桌面上，如果有大量相似颜色的块，您可以每隔几秒钟全屏刷新一次，只传输变化部分。

另一方面，Gamestream 非常清楚，您本质上是在播放与电影类似的视频（游戏），其中有很多视觉噪音，但您确实需要尽可能接近原始画面来观看几乎每个完整帧。因此，他们认为，为了减少带宽，某种程度的有损编码是可以接受的。所使用的编解码器是显卡已经知道如何使用解码器在硬件中处理的编解码器。创建硬件编码器并将其放在解码器旁边并不是一件难事。

Gamestream 的工作原理是利用硬件编码器和解码器，但结果是带宽相对恒定，并且会随时间推移产生完整的数据流。由于所有操作都在硬件中完成，并且大多数阶段都是“发射后不管”的，因此它可以实现一致（低）的延迟。

Gamestream 所进行的编码类型在应用于 VNC 时，由于编码器类型，会导致（很可能）需要更高的带宽，并且由于有损压缩，质量会更差。权衡是技术上VNC 和类似的解决方案（例如 RDP）“较慢”，但实际上在合理的链接上延迟是完全可以接受的。

游戏串流和远程桌面有着完全不同的意图和理念，尽管从我的经验来看有使用游戏流媒体为了过去的远程桌面确实运行得很好，但有一些视觉保真度的损失。

Answer 2

说所有的 VNC 都很慢是一种过于简单的说法，没有考虑到 TightVNC 和 RealVNC 等一些公司所取得的改进。

而传统的VNC比较慢，虽然还是比Linux X要好，但是现在已经没有以前那么慢了。

各种 VNC 版本都采用了 Microsoft 的 RDP 等更快实现的功能和优化，并提高了速度。它们还改进了网络连接的使用。

例如，请参阅 2019 年 1 月的文章
RealVNC 为 VNC Connect 发布了新的高速流媒体。