前面三篇把"为什么做"“做什么”“选什么"讲完了。这篇讲"怎么搭”——也就是架构。一个好的架构，往往不是加了什么，而是勇敢地没加什么。ALSPD-DESK 的架构核心就一句话：两端都主动往外连，中继只做配对和转发。下面把这句话拆开，看看它解决了什么、又避开了什么。
一、最大的现实约束：公司的电脑从外面连不进来
要连回公司电脑，第一道坎不是技术，是网络拓扑。公司网络几乎都做了 NAT（网络地址转换）：内网里的机器用私有地址（比如 192.168.x.x 这类），对外只通过一个公网出口。换句话说，公司电脑在公司内网里"没有对外可被直接寻址的地址"。
打比方：公司网络像一栋写字楼，外面的人只知道大楼地址（公司公网出口 IP），不知道你具体在哪层哪间（内网私有地址）。快递员（外部连接）到了前台，前台不知道该送给哪个房间，出于安全也不会挨个敲门问——于是"从外面直接连进你工位上的电脑"这条路人就走不通。要收快递，只能是你自己下楼、主动去前台取。这个"自己下楼取"的动作，就是后面"主动外连"的雏形。
为什么公司要这么"折腾"你？因为公网 IPv4 地址早不够用了，不可能给每台内网机器都发一个公网地址；更重要的是，NAT 本身是一道天然防火墙——外面进不来的流量，天然被挡在外面。所以 NAT 不是"讨厌的限制"，而是"有用的安全机制"。本项目只是顺着它、而不是硬撞它：既然外面进不来，那就让里面主动出去，所有麻烦一次性化解。
后果很直接：你从家里想"主动连进"公司电脑，根本找不到它。外面的连接请求到了公司网关就被挡住或丢弃，因为网关不知道该把这个请求转给内网哪台机器（而且出于安全，它也绝不会随便转）。这就是"外部无法主动连入公司电脑"的铁律。
所以任何"我在家里直接拨号连公司电脑"的设想，在绝大多数公司网络下从一开始就走不通。必须换个拓扑思路。
这里顺带提醒：把 Agent 这类常驻程序放到公司电脑上之前，请先确认公司的 IT 与安全政策是否允许；并且只在本人拥有、或已获得明确授权的设备上部署。架构上再省事，也绕不开合规这道关。
这也解释了为什么这个项目对"个人自用"最友好：你不需要公司的 IT 帮你开端口、不需要网管给你权限、甚至不需要公司采购任何东西——一台你自己的 VPS、两台你自己的 Windows，就齐了。它刻意不依赖公司任何基础设施，所以"合规"的重心其实只在"你有没有权限在那台设备上装软件"，而不是"要不要惊动整个 IT 部门"。把依赖降到最低，合规的沟通成本也降到最低。
二、一个反直觉的决定：两端都主动往外连
既然"外面连不进公司电脑"，那就把方向反过来——让公司电脑自己连出去。
项目里，公司电脑上的 Agent 启动时主动去连你的 VPS（中继），并保持一条长连接；你家里的 Viewer 也主动去连同一个 VPS。中继居中，它不需要主动连任何一端，而是被动接收这两条从内往外建立的连接，再把它们牵到一起。
这和第1篇那张拓扑图对上了：两条连线都是从"家/公司"指向"VPS"的，没有一条是从 VPS 指向公司电脑的。这个"方向"是整个架构的基石，后面所有的好处都从它长出来。
把"主动外连"落成时序看更清楚：两端各自连上 VPS 后，先发一个 HELLO（明文，含角色、房间号、令牌、随机 nonce）；中继校验令牌、发现同房间两条连接到位，回 HELLO_ACK，把对端的 nonce 交过来；两端拿到彼此的 nonce，各自用 password 派生出会话密钥；从此之后的画面和键鼠，全用这把会话密钥加密后再发。注意握手这一步是"明文配对"，因为它必须让中继知道谁和谁一对；握手之后立刻切到"密文"，中继就再也看不懂了。先明文认亲、再密文传话，顺序很重要。
有人会问：那能不能让两端直接 P2P 互连，连 VPS 都不要？理论上能，但公司 NAT 往往打不通（UDP 打洞在对称型 NAT 下经常失败），一旦打不通还得回落中继。项目选择"先中继跑通"，把 P2P 留作后续可选，正是因为这个权衡——中继多一跳的代价，远小于"为了绕开中继把复杂度拉爆"的风险。
三、主动外连带来的三个好处
"两端主动外连"看起来只是换个连接方向，实际换来三个非常实在的好处，每一条都直接关系到部署难度和安全性：
把连接方向反过来这一招，表面看只是"谁连谁"的区别，实际换来的是部署体验和安全性上的三重解放。下面三点，每一点都对应着"如果照老办法（被动入站）会多出来的麻烦"——对比着看，才知道这一招值在哪。
- 被控机零入站端口：因为 Agent 只往外连、从不监听外来的连接，公司电脑上没有任何"从外面能敲的门"。没有入站端口，就意味着没有可被外部主动攻击的入口——攻击者连"门把手"都摸不到。
如果反过来要开入站端口，你就得在公司防火墙上开洞、把某端口映射给公司电脑，这不仅要网管权限，还等于在公司边界上开了一扇长期敞着的门，扫描器一摸就到。零入站端口把这门直接取消了。
- 不需要改防火墙规则：既然不开任何入站端口，自然也就不用去公司防火墙上开洞、加放行规则。很多公司防火墙你也没权限改，这条直接把"部署卡在 IT 审批"的风险降到了最低。
如果不这样，你就得去申请防火墙放行、写端口映射规则，流程长不说，规则忘了回收还会留下长期暴露面。现在不用改，等于少了一处要人审批、要人维护的东西。
- 不需要管理员权限：不开入站端口、不绑特权端口、不改系统防火墙，意味着 Agent 以普通用户身份就能跑。它不走服务、不写注册表、不装驱动，开机自启也只走当前用户的启动文件夹。免管理员权限，既是便利，也是安全——对系统层面的改动越少，出事的面越小。
如果为了开端口或装服务去要管理员权限，不仅部署门槛变高，Agent 一旦以高权限运行，它本身出错或被攻破的代价也更大。免权限，是把"爆炸半径"压到最小的一招。
这三点串起来看，“零入站端口"和"免管理员权限"是强相关的：正是因为不开端口、不搞系统级改动，才不需要提权。架构上的一次取舍，同时把"攻击面”“部署阻力”"权限要求"三座大山都削平了。
这三点合起来，翻译成人话就是：你部署 Agent 时，双击运行、配好房间号和密码、放进启动文件夹，完事。没有"请联系网管"“请申请权限”"请开放端口"任何一条——对一个只想连回自己电脑的普通人，这种"零阻力"本身就是安全的一部分，因为它意味着你更可能正确地、低调地把事情做对，而不是为了绕过阻力去走歪路。部署越简单，出错的面越小，这是架构送给使用者的隐形福利。
四、中继只做两件事：配对与盲转
中继（VPS 上那部分）的职责被刻意压到最小，就两件事：
- 按房间号配对：两条连接进来后，中继看它们是不是同一个房间号、令牌对不对，对上了就把这对连接对接起来。
- 原样转发字节流：对接之后，A 发来的字节原样交给 B，B 发来的原样交给 A。中继不解析、不理解、不修改里面的内容。
“盲转"两个字是重点：中继看不到画面、看不到键鼠，因为它手里没有端到端密钥，收到的永远是密文。它充其量知道"哪两个连接配成了一对”“这会儿传了多少字节”——而这些元数据，正是配对所必需的、不得不让中继知道的最小信息。项目源码里中继的日志也只记消息类型和字节数，从不记录载荷内容。
把中继的能力压到这么小，是刻意的：中继越"傻"，它出问题的后果越轻，你花在"守护中继"上的精力也越少。
把中继做得"无状态"，还有个附带好处：它不依赖任何本地存储，重启即干净，不会被"上次会话残留的数据"反咬一口。一个不记仇、不攒货、只搬当前字节的中继，恰恰是最难被"养出后门"的那类程序——它根本没地方藏东西。
五、为什么不搞复杂：没有设备 ID、发现、信令协商、多会话
很多远程方案会引入一整套"怎么找到对方"的机制：设备 ID、自动发现、信令协商、多会话排队……ALSPD-DESK 一个都没做。为什么？
极简配对的背后，是一串"主动放弃"。每放弃一个机制，就少一块要写、要测、要防的代码。下面逐一说清楚，放弃它们到底省掉了什么。
因为对这个项目的唯一目标（在家里看到并操作公司电脑）来说，这些全是过度设计：
- 不需要设备 ID：你只有一台被控机，配个房间号就够了，没必要造一套标识设备的账号体系。
- 不需要设备发现：两端都连同一个中继、同一个房间，自然就碰头了，不需要在局域网里广播"谁在？"
- 不需要信令协商：配对的握手只交换两端随机生成的 nonce（用于派生密钥），没有复杂的 SDP、ICE 那套协商。
- 不做多会话：一个房间同一时刻就是一对连接。同角色再来一个，旧的会被新的顶替（项目里叫"replaced"），而不是开第二个会话。
每少一样机制，就少一块要测试、要防错、要防攻击的代码。对一个自用工具，“够用且简单"远胜于"功能齐全但处处是坑”。极简配对能成立，底气来自上一节说的——安全不靠配对机制兜底，而靠端到端加密；所以配对可以做得这么轻。
补充一个常被问的细节：中继其实支持配置一个期望房间号（expected_room），若两端填的房间号不符就拒绝。但这依然不是安全边界——它只用来"防止你手滑填错房间、连到别人那儿"，和端到端加密是两层不同性质的东西。房间名永远只是个方便的标签，不是锁。
六、对端不在就丢：不缓存才不拖延
中继转发时还有一个重要决定：对端不在线，收到的数据直接丢弃，不缓存。
这听起来有点"浪费"——明明可以存一下，等对端连上来再补发嘛？但项目源码里那句注释说得很直白：“不缓存。远程桌面缓存只会造成延迟。”
原因在远程桌面的性质：画面是连续不断的实时流，你此刻看到的应该是"此刻的画面"，而不是"三秒前缓存的一堆旧帧"。如果中继把对端不在时的帧都攒着，等对端一回来哗啦全灌过去，结果是远端卡在旧画面里慢慢追，反而更糟。而且画面用的是"相对上一帧的变化块"，攒一堆旧帧对还原也没意义。
所以中继是"无状态、不落盘"的：它不记住任何历史帧，谁此刻在就转给谁，谁不在就丢。这既省内存，又保证延迟可控——远程桌面的第一优先级永远是"新鲜"，不是"不丢"。真正怕丢的内容（比如丢了某个变化块导致画面残缺），由被控端的"补发集合"和定期关键帧在应用层自愈，而不是靠中继缓存。
为什么不落盘缓存，还有一层考虑：一旦中继把帧写进磁盘或内存池，它就从"路过密文"变成了"暂存密文"，暂存区本身就成了新的攻击目标，还得操心清理、加密存储、内存回收。直接丢弃，连这个烦恼都省了——密文在内存里多停一秒都是浪费，更别说落地。
七、房间名不是安全边界
最后澄清一个容易误会的点。
这一节其实是在给前面所有"极简"做个注脚：你可能会不安，"这么简单的房间号，安全吗？"答案是——安全感从来不来自房间号复杂，而来自端到端加密。房间号再长，只要它没参与密钥派生，就只是个名字；端到端加密再简单一句，只要密钥只在两端，内容就只在对端可见。把这件事想透，你就不会被"看起来不够复杂"吓到，也不会被"看起来很复杂"骗到。中继在握手时会校验房间号（如果配置了期望房间），但这绝不意味着房间名是安全边界。
项目源码里写得很清楚：房间号匹配只是"防止你误连进别人的房间"，真正保护内容的是端到端加密。就算有人猜到了你的房间号、甚至混了进来，他拿不到password、派生不出会话密钥，看到的依然只有密文，操作不了你的机器。
把"防误连"和"防破解"两件事分开，好处是房间号可以设计得很简单（甚至就是个好记的词），而不必为了安全把它搞成一长串密钥——因为安全本来就不靠它。理解这一点，你就不会把房间号当成秘密来小心翼翼藏，也不会因为它"太简单"而误以为项目不安全。
再强调一次：房间号简单，是因为安全不靠它；配对轻，是因为加密在别处兜底。新手最容易犯的错，是把"房间号设得复杂"当成"更安全"。正确的做法是：房间号随意、password 死守。把力气花在真正的锁上，别花在标签上。
整篇看下来，架构的聪明之处不在某处精巧，而在于处处克制：连接方向反一下，省掉入站端口和权限；中继做傻一点，省掉信任和攻击面；配对做轻一点，省掉一堆复杂机制；转发狠一点（不缓存），省掉延迟。把不该做的都划掉，剩下的那条链路，反而最稳。
