爱意满满的作品展示区。

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

给大家截几个图吧： airhand 截图

许可证

MIT License

Supplement 1 · 6h 1m ago

为什么不用 WebRTC，而是基于 QUIC 自己实现？

1. 核心原因：服务端只开一个 UDP 端口，部署很简单

本项目：服务端只需开放一个 UDP 端口（默认 4433）。信令、控制码登记、会话配对和字节转发都在同一条 QUIC 连接上完成。
典型的自建 WebRTC：需要部署信令服务和 coturn（STUN/TURN），还要开放一段中继端口范围，部署和维护都更麻烦。

2. 很多环节可以按需自定义

在 AI 时代，让 AI 针对具体场景重写，可能比直接套用现有技术效果更好。例如：

选路：ICE 选好候选对之后，应用基本无法控制。这里中转和直连可以同时使用，控制数据两条路各发一份，画面和声音由被控端按探测到的延迟选路。
码率和在途控制：按远程桌面的需求定制，按字节限制在途数据，网络跟不上时跳到最新帧，而不是让延迟越积越多。
媒体管线：硬编 AV1 / HEVC 加 GPU 零拷贝，在 WebRTC 上实现困难，集成成本高。

服务端能不能单独拿出来，无需使用 Docker？

可以。

直接下载

Releases 里有打包好的 airhand-server.exe，方便在内网使用。

自行编译（其他系统）

cargo build --release --locked -p airhand-server

产物在 target/release/ 下。

运行

./airhand-server

默认监听 0.0.0.0:4433（UDP）。证书、私钥和数据库放在程序旁边的 data/ 目录里，不存在时会自动创建并生成证书。也可以显式指定路径：

# Linux / macOS
AIRHAND_CERT=data/cert.pem AIRHAND_KEY=data/key.pem ./airhand-server

# Windows PowerShell
$env:AIRHAND_CERT = "data/cert.pem"
$env:AIRHAND_KEY = "data/key.pem"
.\airhand-server.exe

远程控制

QUIC

udp

31 replies • 2026-11-15 16:55:33 +08:00

humbass

23h 28m ago

服务器是不是要一个云服务器可以部署的东西？没看明白。

sqlpxc

23h 24m ago

@humbass clone 项目，然后 docker compose up -d 就行，如果在国内的话，服务器的话用国内的轻量云就行，80 一年很便宜的。。。。

litanid

23h 21m ago

大神啊

default996

22h 27m ago

目前使用的是 UU 远程和 RDM ，一个出门用，一个局域网用。你这个还要一个服务器，估计只能圈子内玩了

loveqianool

22h 23m ago via Android

有 web 控制端吗？在网页上控制其他设备。

sqlpxc

22h 20m ago

@loveqianool 有，在 web 目录下 docker compose up ，目前没有部署 web 端。。。。

loveshuyuan

22h 17m ago via iPhone

对比 uu 远程怎么样呢

sqlpxc

22h 16m ago

@default996 如果你两个设备在局域网下，其实不会走服务端中转，效果比 UU 应该好得多，还能在电视上串流电脑屏幕

default996

21h 43m ago

@sqlpxc #8 在内网中，能够不装 Docker 就直接连接另一台设备吗？

lanthora

21h 35m ago

能否把打洞和依赖服务端的这部分逻辑拆分出来，单独做一个服务端监听特定端口，客户端直接连接这个端口就能使用的版本，整体类似 vnc ，这样网络部分就可以交给其他产品了。现有的 vnc 在有高分辨率屏幕的 mac 上，非局域网几乎不可用。

sqlpxc

20h 44m ago

@default996
@lanthora 服务端是可以单独编译一个二进制的，这个暂时我没有编译，后面我编译一份放 github 上吧，使用 cargo build --release --locked -p airhand-server 可以单独把服务端编译出来，就一个二进制文件，使用 AIRHAND_CERT=data/cert.pem AIRHAND_KEY=data/key.pem ./airhand-server 就可以运行，把服务端放在两个客户端都可以访问的地方就行了