企业官网建设流程全解析

Beamer 是一款开源的跨平台共享键鼠工具，让一套键盘鼠标在局域网内同时驱动 Mac 与 Windows / Linux 电脑。自 1.5.0 起，机器间通信升级为线协议 v6（Wire Protocol v6）：两端在一条 TCP 连接上先完成 62 字节的握手，用 X25519 + HKDF 派生一次性会话密钥，再把键盘、鼠标、剪贴板等每条消息封装成ChaCha20-Poly1305 加密帧，并用只增不减的防重放计数器拒绝一切重放的旧帧。下面带你完整看懂这套握手、加密与防重放机制。

Beamer 的线协议是什么？两台机器之间的一条 link

Beamer 术语里，**link（链路）**就是两台已配对机器间的一条 TCP 连接：主动发起连接的一方是initiator（发起方），接受连接的一方是responder（响应方），输入永远只从 initiator 流向 responder。两台桌面电脑若要互相驱动，会各开一条方向相反的 link。

完整规格写在仓库根目录的 WIRE.md 中（精确到可以据此写出第二个实现），关键代码在：

• core/protocol.py：握手、密钥派生、帧加解密、消息校验
• core/link.py：initiator 侧的连接逻辑
• core/receiver.py：responder 侧的监听逻辑
• PAIRING.md 与 SECURITY.md：配对 token 如何产生、link 保护什么

v6 直接替换了 v5（Beamer 1.4.1–1.4.3 使用），没有回退：v6 机器会拒绝 v5 对端，并在界面上点名告诉你该升级哪台机器。

握手过程：从 62 字节 preamble 到会话密钥

握手时，每一侧最先发出的是一段明文 preamble（前导段），固定 62 字节（见 WIRE.md）：

• key id是对配对 token 做 HKDF-SHA-256 的前 16 字节（core/protocol.py 的key_id函数）。它让 responder 在解密前就能找到"该用哪一个配对 token"，而不暴露任何机器身份——真正的 machine id 放在第一个加密帧里校验。
• X25519 公钥是每条连接重新生成的，密钥算完就丢弃。

hello / welcome：第一对加密帧

preamble 交换完成后，双方各自算出 X25519 共享密钥，再用 HKDF 派生出两个方向各一把的帧密钥（core/protocol.py）：

key = HKDF-SHA-256( ikm = token 文本 || X25519 共享密钥, info = "beamer-frames" || 版本 || key_id || 双方 nonce 前缀与一次性公钥 || 方向字节 )

密钥被"绑定"了双方的临时前缀、临时公钥和方向字节，这是 v6 最重要的安全升级——前向保密（forward secrecy）：

• 录下的旧连接无法重放到新连接上（每次前缀和公钥都变了，密钥完全不同）；
• token 日后泄露也推不出旧会话的密钥；
• 帧无法被反射回发送方（方向字节不同）。

随后 initiator 发出第一帧hello（版本号、machine id、机器名、平台、能力列表、监听端口），responder 校验后回welcome。机器 id 对不上就回wrong_id，hello非法就回invalid_hello，然后立即断开（握手完整步骤见 WIRE.md）。

整个握手有严格时限：preamble 须在 1 秒内到达，整体 5 秒内完成；responder 同时最多 4 个握手、每个来源地址 1 个，防止握手资源被滥用（相关常量见 core/protocol.py）。

加密帧结构：每条消息都长什么样

握手完成后，线上传输的只有帧（frame）：

frame = length(4字节, 大端) || counter(4字节, 大端) || 密文 || tag(16字节)

• 加解密使用ChaCha20-Poly1305AEAD（RFC 8439），自带 16 字节完整性标签，任何篡改都会解密失败；
• nonce = 本侧 8 字节前缀 + 本帧 4 字节计数器（core/protocol.py 的seal_raw）；
• 明文是一条 UTF-8 JSON 消息，形如{"type": "mousemove", "data": {"dx": 12, "dy": -3}}；
• 单帧最大 16 MiB；第一帧（hello / welcome）在认证前最多 4096 字节；
• 一帧从第一个字节起 30 秒内必须完整到达，否则断开连接（WIRE.md）。

常用消息类型包括keydown/keyup、mousemove、mousedown/mouseup、scroll、clipboard、focus（输入所有权申请）、ack（确认）等，构建与校验函数都集中在 core/protocol.py。

防重放计数器：counter 只能往前走

防重放是 v6 中最不起眼、却最关键的一环，规则简单到可以背下来：

1. 每一侧的发送计数器从 1 开始，每条新 link（含重连）都重新计；
2. 接收方只接受 counter = 上次接受值 + 1，重复的 counter 会立即断开连接；
3. 计数器到达2^32 - 1后，发送方必须断开并重建连接。

校验就在源码里（core/protocol.py）：

if counter != self._recv_counter + 1: raise ProtocolError("frame counter did not advance; replay rejected")

计数器一举两得：既保证ChaCha20 nonce 永不重复（对 ChaCha20 来说 nonce 复用是致命的），又让任何被截获、重放的旧帧必然失败。它和业务层的seq序列号分工协作：seq供 responder 发ack确认并统计往返延迟，counter 则是加密层的最后防线。

版本兼容与旧版本处理

• responder 收到非BEAMY开头（Beamer 4.0 之前的纯明文连接）时，会回一条旧式welcome告知版本不符后关闭；收到低于 6 的版本，发 14 字节"短回复"，让旧版 v5 用它能看懂的话术显示"对端是更新版本"；
• 从 1.4.x 迁移来的 token、用户手输的 token一律不能建立 v6 link（key id 可被用来离线爆破弱 token），界面会提示重新配对；
• 1.4.x 的配置文件只迁移一次且永不回写，两边都降回 1.4.x 仍可用，但 1.4.x 说的是 v5，会被 1.5.0 拒绝。

源码与文档索引

• 协议规格：WIRE.md（握手、密钥、帧、zone、配对全在此）
• 核心实现：core/protocol.py、core/link.py、core/receiver.py
• 测试向量：core/tests/v6_vectors.json，由 core/tests/test_v6_vectors.py 与 core/tests/test_protocol_v6.py 逐条回放验证

🔐 一句话总结：v6 用"一次性 X25519 + HKDF 绑定"换来前向保密，用"ChaCha20-Poly1305 + 严格递增计数器"保证每一帧的真实与不可重放——两台机器隔着局域网，也能放心共享键盘、鼠标和剪贴板。