RustDesk 完全指南：从实现原理到版本选择
RustDesk 是一款开源的远程桌面软件，凭借其高性能、可自建、数据自主的特性，在开发者社区中获得了广泛关注。它使用 Rust 语言编写，在 GitHub Rust 语言排行榜上长期位居前列。本文将深入介绍 RustDesk 的技术原理、核心架构，并详细对比开源版与专业版的差异，帮助你做出最适合自己的选择。
一、RustDesk 是什么？
RustDesk 是一款功能完整的开源远程控制解决方案，支持 Windows、macOS、Linux、iOS、Android 以及 Web 全平台。与 TeamViewer、向日葵等商业软件不同，RustDesk 的核心卖点是你可以完全掌控自己的数据——所有的连接都可以通过你自己部署的服务器来完成，无需依赖任何第三方服务。
RustDesk 的客户端和服务端均采用开源协议发布，你可以自由地审计代码、甚至基于它进行二次开发。其中，客户端采用 AGPL-3.0 协议，这是一个严格的互惠型开源协议，要求任何基于它修改并分发的衍生作品也必须开源；服务端（hbbs/hbbr）同样开源，提供了一个基础但完整的自托管方案。
二、核心技术原理
2.1 整体架构
RustDesk 的架构遵循清晰的分层设计，主要包含三个核心组件：
| 组件 | 名称 | 角色定位 | 核心职责 |
|---|---|---|---|
| 客户端（主控端/受控端） | Client / Server | 端点设备 | 屏幕捕获与编码、输入注入、音视频流处理 |
| hbbs | ID/信令服务器 | 调度中心 | 设备注册、在线状态维护、P2P 连接协调 |
| hbbr | 中继服务器 | 备用通道 | P2P 失败时转发所有流量 |
hbbs 和 hbbr 通常部署在同一台服务器上，分别监听 21116 端口（TCP+UDP）和 21117 端口（TCP）。
可以这样形象地理解这两个组件的分工：
- hbbs 像是“电话号码簿 + 接线员”：它帮你找到对方设备，并尝试帮你们直接接通电话。
- hbbr 则像是“邮局/快递中转站”：当你们无法直接通话时，所有信息都通过这个中转站来传递，确保在任何网络环境下都能连通。
2.2 工作流程
第一步：设备注册
每台 RustDesk 客户端启动后，会做两件事：
- 生成本地密钥对
(sk, pk)，并将公钥pk注册到hbbs信令服务器上。 - 每隔 1 秒向信令服务器发送心跳包，告知服务器“我还在线”。
第二步：连接协商
当设备 A 想连接设备 B 时，连接协商过程如下：
- 获取对端信息：A 向
hbbs请求 B 的公钥和网络地址。 - 身份验证：
hbbs通知 B 对 ID 进行签名（用 B 的私钥），A 收到后用 B 的公钥验证签名，确认身份无误。 - 尝试 P2P 直连（打洞）：A 向 B 的网络地址发起打洞请求，尝试建立直接连接。这个过程依赖于 UDP 协议（21116 端口）来实现 NAT 穿透。
- 对称密钥协商：如果 P2P 成功，双方会通过 X25519 椭圆曲线算法交换密钥，生成一个临时会话对称密钥，后续所有数据都用这个密钥进行端到端加密。
第三步：加密传输
RustDesk 的加密基于 NaCl 加密库，使用 AES-256-GCM 或 XSalsa20-Poly1305 算法对数据流进行加密。连接建立后的所有通信——屏幕画面、键盘输入、文件传输——都经过端到端加密，理论上只有通信双方能够解密，中间的网络设备和服务器无法窥探内容。
关于加密的安全性，需要补充一个细节：所有加密机制在代码中都是公开、可审计的。所谓”私有协议”并不意味着”黑盒”，恰恰相反，因为代码完全开源，任何人（包括安全研究人员）都可以完整审查其加密实现，确保没有后门或弱加密算法。
第四步：中继模式（备选）
如果 P2P 打洞失败（例如双方都在严格的防火墙后），hbbs 会通知 A 和 B 切换到 hbbr 中继服务器。此后所有数据都通过中继服务器转发。这是保证连通性的”备用方案”。
2.3 远程桌面协议解析
一个重要的问题是：RustDesk 用的是通用协议还是自定义协议？
答案是：它使用的是自研的自定义协议，而不是像 RDP 或 VNC 那样的通用标准协议。
这个选择背后的原因有三点：
- 追求高性能与低延迟：私有协议可以根据 RustDesk 自己的数据传输特点（如屏幕画面编码、输入指令等）进行深度优化。有资料显示，其协议参考了 WebRTC 的一些设计思想，但整体实现是独立的。
- 保障端到端安全：采用私有协议配合 TLS 1.3 等强加密手段，可以更好地构建从一端到另一端的加密通道，确保在”P2P直连”或”服务器中转”两种模式下，传输的数据都无法被中间节点解析。
- 架构灵活性：私有协议能够原生支持其独特的”P2P优先 + 中继备选”通信模式，这是标准协议难以直接实现的。
由于代码完全开源，这套私有协议的完整实现细节都在源码中公开。你可以在以下核心目录中看到它的具体实现：
src/rendezvous_mediator.rs：协议的”总调度室”，负责与信令服务器通信，协调 NAT 穿透过程。src/client.rs/src/server/：协议的”执行者”，实现主控端和被控端的通信逻辑。libs/hbb_common/：协议的”工具箱”，提供视频编解码、TCP/UDP 封装、以及 Protobuf 消息序列化格式。
简单来说，RustDesk 用的是一套开源的私有协议——它不是通用标准，但因为代码公开，协议是透明、可审计的。
2.4 技术栈亮点
RustDesk 的技术选型体现了对性能和安全性的极致追求：
| 技术领域 | 采用技术 | 优势 |
|---|---|---|
| 编程语言 | Rust | 内存安全、并发性强、零成本抽象，杜绝缓冲区溢出等经典漏洞 |
| UI 框架 | Flutter（现代版）/ Sciter（旧版） | 跨平台 UI 与 Rust FFI 桥接 |
| 异步运行时 | Tokio | 高性能异步 I/O 和网络事件循环 |
| 视频编解码 | VP8/VP9/AV1（软件），H264/H265（硬件） | 自适应编码，充分利用 GPU 加速 |
| 网络传输 | KCP（可靠 UDP），安全 TCP | NAT 穿透 + 低延迟加密通道 |
| 协议序列化 | Protocol Buffers | 高效的消息序列化格式 |
三、开源版 vs 专业版：详细对比
RustDesk 采用 “开源核心 + 付费增值” 的模式。开源版（社区版）提供了完整的核心功能，而专业版（Server Pro）面向需要集中管理和企业级控制的团队。
重要说明：这里所说的”开源版”和”专业版”并非闭源 vs 开源的对立关系。客户端代码（采用 AGPL-3.0 协议）和服务端代码（hbbs/hbbr）均保持开源。专业版的核心价值在于官方提供的 Web 控制台、用户管理体系、自定义品牌客户端生成器、企业级集成（LDAP/SSO）、审计日志等增强功能——这些是官方提供的付费增值服务，其源码不对公众开放。
3.1 功能对比一览
| 对比维度 | 开源版（OSS） | 专业版（Pro） |
|---|---|---|
| 核心远程功能 | ✅ 完整支持（远程控制、文件传输、剪贴板同步、TCP 隧道等） | ✅ 包含开源版全部功能 |
| 自建服务器 | ✅ 可自建 hbbs + hbbr | ✅ 可自建，并提供 Web 控制台 |
| 数据自主权 | ✅ 数据完全私有 | ✅ 数据完全私有 |
| 服务端是否有界面 | ❌ 无（仅命令行） | ✅ 有 Web 管理控制台（端口 21114） |
| 用户登录与账号体系 | ❌ 无（仅设备 ID 认证） | ✅ 有（可创建多个登录用户） |
| 双因素认证（2FA） | ❌ 无 | ✅ 支持 TOTP 验证 |
| 单点登录（SSO/OIDC） | ❌ 无 | ✅ 从基础版起支持 OIDC |
| LDAP/AD 集成 | ❌ 无 | ✅ 从基础版起支持 LDAP 集成 |
| 自定义品牌客户端 | ❌ 需自行修改源码编译 | ✅ 官方提供客户端生成器，可自定义名称、图标、Logo |
| 设备分组管理 | ❌ 仅本地地址簿 | ✅ 云端地址簿与分组管理 |
| 审计日志 | ❌ 无 | ✅ 有完整的操作审计记录 |
| 技术支持 | 社区支持（GitHub、论坛） | 官方技术支持 |
| 是否开源 | ✅ 完全开源 | ⚠️ 核心功能开源，增强功能为闭源付费增值 |
3.2 定价模式
RustDesk 按登录用户数 + 托管设备数计费，而非按连接数或并发数收费（大多数套餐支持无限并发连接）。
| 套餐 | 价格（月付） | 登录用户 | 托管设备 | 核心特色 |
|---|---|---|---|---|
| 开源版（免费） | $0 | 无用户体系 | 无限制 | 基础信令 + 中继，社区支持 |
| 个人专业版 | $9.90 | 1 个 | 20 台 | Web 控制台、2FA、审计日志 |
| 基础专业版 | $19.90 | 10 个 | 100 台 | OIDC/LDAP、自定义客户端生成器 |
| 定制版 | $19.90 起 | 10+ 个（$1/用户） | 100+ 台（$0.1/设备） | 灵活扩容，可按需定制 |
价格说明：以上价格为年度订阅，按月折算。人民币价格约为 869 元/年起，具体以官网为准。国内代理商（如宝塔面板）价格与官方基本一致。
3.3 如何选择？
✅ 适合开源版的场景：
- 个人开发者、家庭用户、技术爱好者
- 只需要在几台电脑之间互相远程控制
- 不需要集中的用户管理和权限控制
- 愿意自己动手部署和维护服务器
✅ 适合专业版的场景：
- 团队协作，需要为多个成员分配不同权限
- 企业合规要求，需要审计日志和操作追溯
- 需要与公司现有的 AD/LDAP 或 SSO 系统集成
- 希望将分发给客户的客户端打上自己的品牌标识
- 需要 Web 界面集中管理所有设备和用户
3.4 关于”服务端界面”的说明
一个常见的疑问是：”部署好服务端后，有管理界面吗？”
答案是：开源版的服务端（hbbs/hbbr）本身没有图形界面。它们像默默工作的信使和中转站，部署好后通过命令行管理即可。可以用 docker compose ps 查看进程状态，或用 docker compose logs -f 查看实时日志。
如果确实需要 Web 管理界面，有两种方式：
- 付费升级专业版：官方提供的专业版自带 Web 控制台。
- 使用第三方增强版：如
lejianwen/rustdesk-server-s6这类社区集成镜像，在 Docker 中集成了标准服务端和自定义 API，可以实现后台和登录功能。但这属于社区方案，需要自己承担维护成本。
四、部署要点速览
如果你决定自建 RustDesk 服务器，以下要点需要留意：
4.1 端口开放
RustDesk 服务端需要开放以下端口（云服务器需在控制台安全组和系统防火墙中同时放行）：
| 端口 | 协议 | 用途 |
|---|---|---|
| 21115 | TCP | NAT 类型测试 |
| 21116 | TCP | ID 注册 |
| 21116 | UDP | 心跳与 P2P 打洞（必须开放，否则无法直连） |
| 21117 | TCP | 中继转发 |
| 21118 | TCP | Web 客户端支持 |
| 21119 | TCP | Web 客户端支持 |
特别注意：21116 端口必须同时开放 TCP 和 UDP，否则 P2P 直连将完全无法工作，所有流量都会走中继，导致延迟变高。
4.2 加密与密钥
服务端启动后会自动生成密钥文件（id_ed25519.pub），客户端配置时需正确填写该 Key。ENCRYPTED_ONLY=1 环境变量可强制只允许配置了正确 Key 的客户端连接，防止未授权访问。
4.3 如何判断当前连接模式
连接成功后，将鼠标悬停在客户端窗口左上角的绿色（或蓝色）盾牌图标上：
- 显示 “加密直连” → P2P 模式，速度最快，数据不经过服务器
- 显示 “加密中继” → 中继模式，数据通过你的服务器转发
直连不需要额外设置，RustDesk 会自动尝试 P2P 打洞，打洞失败才走中继。如果总是走中继，检查 21116 UDP 端口是否开放，或优化客户端网络环境。
五、总结
RustDesk 是一个设计精良、安全可靠的远程桌面方案。它的核心优势在于数据主权和技术透明度——你可以审计代码、自建服务器、完全掌控自己的数据流。
从技术角度看，它采用 Rust 语言构建，通过自研的私有协议实现了”P2P优先 + 中继备选”的通信模式，端到端加密贯穿始终保证了数据安全。整套协议虽然不遵循 RDP 或 VNC 等通用标准，但因为代码完全开源，其全部实现细节都是公开、可审计的。
从版本选择角度看，开源版提供的功能已经足以满足大多数个人和小团队的需求，核心远程功能完整、免费、不限速、不限时长。专业版则在规模化管理和企业级集成方面提供了官方支持的扩展方案，适合需要统一权限管理、品牌定制和合规审计的团队。
对于”多台电脑互相远程”这类典型个人使用场景，开源版完全够用，无需额外付费。