我自己开发了一个远程控制软件 Airhand 欢迎 star~ 支持 120fps

airhand

我是 airhand 的开发者，项目地址：https://github.com/sqlpxc/airhand，欢迎 Star ⭐

FAQ

为什么还要再做远程控制？为什么不用 RustDesk ？

最开始的原因很简单：RustDesk 需要部署 hbbs 和 hbbr，开的端口太多了，我总觉得在服务端开很多端口不是什么好事……

而且它不支持 AV1 硬件编码。（为什么一定要支持这个？自己使用过我的项目就能体会，效果非常不错。）

为什么之前一直没有编译二进制文件？

因为早期版本里，如果服务端不可信，是很危险的：服务器管理员甚至可以直接连接任何客户端。

后来加了配对码功能，我才自己部署了服务端。

对了，最终 windows 安装包只有不到 4M ，也就一个高清图片大小。。。

为什么用 QUIC 可靠流，而不是 UDP 或者数据报？

BBR 就不说了，为什么用可靠流传输画面呢？

有现成的 TLS 1.3 可以用。

编码用的是超长 GOP，关键帧只在控制端请求或分辨率变化时才编码，所以每一帧都依赖前一帧。一个包丢了没补上，这一帧就坏了，而且花屏会一直持续到
下一个关键帧。

关键帧是这里流量消耗最大的地方。重传丢的包至少要等一个 RTT ；即使换成不可靠传输，也躲不开这一个 RTT 的等待，只是多了一个"先显示花屏"的选项。

远程桌面上满屏都是文字，花屏比晚一个 RTT 在使用体验上更加难受……

服务器会一直维护吗？

大概率不会。公共服务端只是给大家体验一下的，而且服务器配置一般，人多了还是会很卡，建议自己部署。

特性

只需暴露 1 个 UDP 端口：服务端只有一个 UDP 端口需要对外开放。

中转也走 QUIC/UDP + BBR：据我所知，不少远控软件打洞失败后会退到 TCP 中转，比如 RustDesk 的中转就是 TCP 。TCP 上丢一个包，后面所有数据都得等它
重传。

各通道互不阻塞：控制、画面、剪贴板各走一条流，声音和 Ping 走数据报，鼠标操作不会排在大帧后面。

延迟不堆积：中转把连接拆成两段，在两端之间又做了一层码率控制。发送端限制在途字节，网络慢时跳到最新一帧，不会越用越卡。

多平台兼容：甚至支持电视端。安卓包直接装到电视上就行，会自动检测是不是电视。

支持安卓控制安卓

自动 UDP 打洞：如果两台设备能打洞成功，画面会按实测时延选更快的那条线路。显示「直连」时网络延迟极低，基本和串流效果差不多。

音频冗余设计：保证音频不断。

给大家截几个图吧：

许可证

主楼