网络原理

本文对应 0.5.4：信令协议 v3，网络辅助服务协议 v2。

房间与场景

frp-sh create、create game、create dev 均创建 LAN 房间。这个命令顺序下的 Game/Dev 是参数预设，不会自动发现或发布服务；旧入口 game create --tcp ...、dev create --tcp ... 用于显式发布服务。

LAN 通过虚拟网卡为设备分配独立地址，物理局域网暴露需要显式开启。受限的特权辅助服务负责网卡和路由，普通客户端负责连接。服务端在内存中保存房间注册信息，重启后房间丢失。

连接路径

客户端发现地址，通过信令交换候选地址并尝试 UDP 打洞。可用 TURN 提供 UDP 中继，TCP 是回退路径。--relay 跳过打洞和 TURN，强制 TCP；达到直连重试上限本身不等于禁用 TURN。

服务房间通过有并发上限的 TCP 中继多路复用显式发布的 TCP/UDP 服务。UDP 保留报文边界，但仍受 TCP 队头阻塞影响。最多 16 个服务、32 位访客，每位访客 64 条并发流，房间总计 256 条。

认证与加密

公网信令和中继监听要求服务器密码。邀请携带房间级凭据，不分发服务器管理密码；房主操作还需要 owner token。HTTP 信令必须通过 HTTPS 部署才能保护传输中的凭据。

房间凭据提供的中继传输加密不代表对运营者保密。可选的共同 --key 增加负载加密，服务房间会在 TCP 中继之上应用它；包含该口令的邀请需要保密。内置 TURN 仅允许向本实例有效中继端点转发。

资源限制

0.5.4 增加服务端容量限制，见服务器部署。计数对象是登记成员，不是真实在线人数；不包含带宽限速和流量配额。

当前房主 mesh 循环每 100 ms 轮询信令，终端房间视图每 2 秒轮询。这是实现细节，不是时延承诺。房间快照共用注册表锁，应通过压测确定规模，不能只根据内存估计承载人数。

认证和中继帧入口见协议说明。