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 打洞：如果两台设备能打洞成功，画面会按实测时延选更快的那条线路。显示「直连」时网络延迟极低，基本和串流效果差不多。
- 音频冗余设计：保证音频不断。
给大家截几个图吧：
Select Language