airhand

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

FAQ

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

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

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

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

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

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

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

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

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

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

只需暴露 1 个 UDP 端口：服务端只有一个 UDP 端口需要对外开放。
中转也走 QUIC/UDP + BBR：据我所知，不少远控软件打洞失败后会退到 TCP 中转，比如 RustDesk 的中转就是 TCP 。TCP 上丢一个包，后面所有数据都得等它重传。
各通道互不阻塞：控制、画面、剪贴板各走一条流，声音和 Ping 走数据报，鼠标操作不会排在大帧后面。
延迟不堆积：中转把连接拆成两段，在两端之间又做了一层码率控制。发送端限制在途字节，网络慢时跳到最新一帧，不会越用越卡。
多平台兼容：甚至支持电视端。安卓包直接装到电视上就行，会自动检测是不是电视。
支持安卓控制安卓
自动 UDP 打洞：如果两台设备能打洞成功，画面会按实测时延选更快的那条线路。显示「直连」时网络延迟极低，基本和串流效果差不多。
音频冗余设计：保证音频不断。

给大家截几个图吧：