公众号旧文
远程控制不求人 之 RustDesk 低延迟高画质
不会搭建 RustDesk 远程控制自托管服务器的，可以参考上方文章。
以下为正文：
我最开始产生远程控制需求的时候，目标很简单： 能连上、够清晰、延迟低、最好还免费。
于是最先尝试的是 TeamViewer。
一、TeamViewer：体验好，但限制多
TeamViewer 给我的第一印象非常好： 画质高延迟低，在同城、同运营商的环境下，几乎就像在本地操作一样。
但问题也很快暴露出来了：
- 设备数量有限制
- 新设备不太容易加
- 旧设备的授权取消起来也不直观
如果只是偶尔用一两台设备，TeamViewer 很舒服； 但一旦设备多了，就会明显感觉到被卡脖子。
二、ToDesk：免费，但按时长收费
后来我转向了 ToDesk。
它的思路很直接：
免费可以用，但每个月有时长限制
这在前半个月还好，一到后半个月，时长用完，体验直接腰斩。
我甚至尝试过多个账号轮换来规避限制，但很快发现：
- 麻烦
- 不优雅
- 不可持续
于是我继续找替代方案。
三、RustDesk：免费开源，却卡得离谱
最终，我把目光放到了 RustDesk 上。
它最大的吸引力只有四个字： 免费 + 开源
但真正用起来之后，我却非常困惑：
- 同城
- 同运营商
画质却很糊，延迟也明显偏高。
在同样的网络环境下，TeamViewer 却能做到又清晰又流畅。
这时候我第一次意识到一个问题：
低延迟、高画质，在这种网络条件下，是完全可以实现的。
那问题就不在网络，而在连接方式。
四、我终于搞明白了：直连 vs 中继
继续深挖之后，我得出了一个非常关键的结论：
远程控制软件，本质上只有两种连接方式：
- 直连
- 中继
一开始，我其实是被 RustDesk 官方的一些描述误导了。
RustDesk 官网上写的是：
享受安全可靠的远程桌面体验，使用您自己的自建服务器。
它给人的感觉是：
使用 RustDesk 搭建自托管服务器，就像在微信上发消息一样，必须经过腾讯的服务器转发
但事实是：
远程控制完全可以不经过服务器，直接设备对设备通信。
而这，正是 TeamViewer 体验好的核心原因。
五、TeamViewer 为什么这么顺？
在 TeamViewer 里，有一个很直观但容易被忽略的细节：
👉 它会明确显示当前是直连状态
当我看到这一点的时候，很多疑问一下子就通了。
- 延迟低
- 画质高
- 操作跟手
因为数据根本没绕路。
六、RustDesk 的问题：它一直在中继
反观 RustDesk：
- 默认不显示当前连接方式
- 实际使用中，大多数情况下走的是中继
- 数据需要经过服务器转发
这也是为什么在同样网络环境下，它表现明显不如 TeamViewer。
七、转机：Tailscale 出现了
为了验证直连这个判断，我引入了 Tailscale。
当两台设备同时运行 Tailscale 后：
- 会组成一个虚拟局域网
- 每台设备都会分配一个 100.x.x.x 开头的局域网 IP
我直接在命令行里做了一件非常简单的事：
ping 被控端的 100.x.x.x IP结果非常惊人：
- 延迟只有 2～3 毫秒
- 和 TeamViewer 显示的延迟几乎一模一样
这一步，基本可以确认：
TeamViewer 在这种环境下，确实是直连。
八、关键一步：RustDesk 默认关闭了 IP 直连
但新的问题来了。
即使在 RustDesk 里：
- 两端已经通过 Tailscale 成功打洞
- 都拿到了 100 开头的局域网 IP
RustDesk 依然在走中继。
直到我继续探寻，才发现一个隐藏得很深的真相：
RustDesk 默认是关闭「允许 IP 直连」的。
当我在配置里把这个开关打开之后，RustDesk 终于实现了直连。
- 延迟瞬间下降
- 画质明显提升
- 使用体验直接换了一档
折腾到最后，我对远程控制这件事有了一个非常清晰的认知：
远程控制卡不卡，和软件关系没你想的大，
真正决定体验的是：你到底走的是直连，还是中继。
RustDesk 并不差， 只是它默认选择了更保险的方式，而不是最优体验。
一旦你知道该打开哪个开关，完全可以和 TeamViewer 一样低延迟高画质