TigerVNC

定义

TigerVNC是虚拟网络计算(Virtual Network Computing, VNC)的一种高性能、跨平台实现, 由服务端与客户端两部分构成。用户借助它可以在本地设备上启动并操作远端机器上的图形程序, 本地仅负责显示画面与转发键盘鼠标输入。其代码以 GPL-2.0-or-later 许可发布, 主要使用 C、C++ 与 Java 编写^[2]。

它与 VNC 早期实现的关键差别在于传输性能: 它加入了经 SIMD 指令加速的 JPEG 压缩解压路径, 在服务端、客户端与网络条件合适时, 能够以全屏方式远程播放动态画面, 且客户端无需视频解码软件或对视频做特殊处理^[3]。此外它还提供多种强认证方式与 TLS 加密的扩展。

原理

TigerVNC 遵循 VNC 使用的远程帧缓冲协议(RFB), 采客户端/服务端模型: 服务端维护一块虚拟帧缓冲, 客户端通过协议消息告知自己期望的像素格式与可接受的编码方式, 并请求画面更新, 服务端再按矩形区域把画面变化送出^[4]。键盘按下抬起、指针移动点击以及剪贴板文本也通过对应的协议消息在两端传递。

编码环节的核心是 Tight 编码。编码器把画面切分为矩形, 先识别纯色区域并单独以 fill 方式发送, 其余子矩形再依据颜色数量, 分别选择单色、索引色、JPEG 或原始像素方式传输。Tight 编码中还包含调色板与渐变两类滤波器, 用于在压缩前减少数据冗余^[4]。

TigerVNC 使用 libjpeg-turbo 作为 JPEG 编解码后端, 该库在现代 x86 或 ARM 处理器上相对普通 libjpeg 可取得数倍加速, 因而编码器可以更频繁地选用 JPEG 子编码而不至于显著增加处理器负担。1.2 版本起加入的 RFB 流控扩展让服务端可以监测 TCP 缓冲与网络状况, 据此自主决定可维持的最大更新速率并主动推送更新, 而不必等客户端逐次请求, 从而减轻高延迟网络下更新率被往返时延限制的问题。

发展历程

TigerVNC 于 2009 年 2 月 27 日公开宣布成立。发起者包括 TurboVNC 的开发者、Fedora 的 VNC 维护者以及 Cendio AB, 起因是 TightVNC 项目已难以支撑他们期望的开发节奏, 且 RealVNC 的重心已转向非开放的企业版^[1][2]。项目以 TightVNC 主干源码树为基础, 目标是提供高性能、稳定且通用的 VNC 实现, 并继续支持 Windows、Linux 与 Java 多个平台, 同时把 VirtualGL 项目衍生出的 TurboVNC 的改进合并进来, 由 Cendio AB 提供资助^[1]。

Cendio 方面回顾, 2002 年至 2009 年间该公司参与 TightVNC 项目, 2004 年起把 Tight 协议移植到第四代 VNC, 成果即从未正式发布的 TightVNC 1.5 系列; 2009 年该公司与 Red Hat 及 VirtualGL 项目合作, 以该系列为基础形成了 TigerVNC^[3]。项目早期的贡献之一是集成 SIMD 加速的 JPEG 压缩与解压, 后续还发展了 ExtendedDesktopSize 扩展(使服务端得以实现 RandR 扩展)、基于 CMake 的构建系统, 以及支持类 Unix、Windows 与 macOS 的 FLTK 图形客户端^[3]。

TigerVNC 成立后不久即被 Fedora 采用为默认的 VNC 实现^[2]。1.2 版本是一次重要更新, 除引入流控扩展外, 还重构了 Tight 编码器, 采用与 TurboVNC 编码器相近的方法, 对含大量纯色的画面处理更好, 并更倾向于使用 JPEG, 在某些情况下显著降低了网络流量。Debian 13 收录的版本号为 1.15.0。

应用

TigerVNC 被多个 Linux 与类 Unix 发行版收录, 包括 Fedora、OpenSUSE、FreeBSD、Arch Linux、Red Hat Enterprise Linux 与 SUSE Linux Enterprise。在 Oracle Linux 8 中, tigervnc-server 与其 X 服务端模块可作为软件包直接安装, 管理员借此为指定用户配置图形远程会话; 该组件在 Oracle Linux 9 中已被标记为废弃^[5]。

在需要三维与视频处理的场景里, TigerVNC 常与 VirtualGL 配合: 由 VirtualGL 在服务端提供硬件加速的 OpenGL 渲染, TigerVNC 负责把渲染结果以可接受的帧率送到客户端, 使三维可视化与工程类应用能够在远端流畅运行^[3]。它同时也是 ThinLinc 远程桌面产品所使用的 VNC 组件^[3]。

局限

TigerVNC 在平台支持上并不对等。服务端主要面向 Linux, 客户端可运行于 Windows、Linux 与 macOS, 而 macOS 没有对应的服务端实现^[2]。此外, 1.11.0 版本起 Windows 服务端不再继续维护, 该项目自认其 Windows 服务端获得的开发投入有限^[2][6]。

由于沿用 RealVNC 的谱系, TigerVNC 设计上依赖发行版提供的 X 服务器源码来构建, 好处是 X 服务器的问题可交由操作系统发行方处理, 也降低了 Xvnc 与发行版自带窗口管理器不兼容的机会; 代价是从源码构建服务端需要一套因发行版而异、通常缺乏文档的流程, 对开发者并不友好^[6]。当遇到的限制来自其依赖项时, 项目组需要先推动上游修补, 再推动各发行版纳入该修补, 解决周期因此较长^[6]。

功能取舍方面, TigerVNC 不支持文件传输, 这一点与 TightVNC 不同; 两者的功能集合在其分家之后已经发生分化^[2]。在编码兼容性上也存在一处边界情况: 当 TightVNC 或 TigerVNC 客户端向 TurboVNC 服务端请求压缩等级 0 且不使用 JPEG 时, 该服务端会绕过 Zlib 直接发送图像, 并在压缩控制字节中置入与 PNG 相同的取值, 旧客户端可能误判数据流, 进而出现异常。

参见

• 虚拟网络计算 —— TigerVNC 所实现的远程显示技术体系及其通信协议基础。

• TightVNC —— TigerVNC 的直接前身, 其源码树构成了 TigerVNC 的起点。

• TurboVNC —— 与 TigerVNC 同源、面向三维与视频负载的 VNC 实现, 双方有编码与流控方面的相互借鉴。

• VirtualGL —— 在服务端提供硬件加速 OpenGL 渲染, 常与 TigerVNC 搭配用于远程三维应用。

• 远程帧缓冲协议 —— VNC 家族通用的通信协议, 规定了像素格式、编码与输入事件的传递方式。

• Fedora —— 较早把 TigerVNC 采纳为默认 VNC 实现的 Linux 发行版。