架构概览
Weblink 将交互、媒体处理和本地数据放在参与连接的设备上。信令服务帮助设备发现彼此并协商连接，WebRTC 负责直接传输内容，或在需要时通过 TURN 中继。理解这些分工，就能知道功能由谁提供，以及需要部署哪些服务。
组件与职责
图中区分了连接协商与内容传输。直连和 TURN 中继是连接可选择的路径，不要求同一份流量同时经过两条路径。
| 组件 | 负责什么 | 对使用者的影响 |
|---|---|---|
| Web 客户端 | 在浏览器中加载界面，运行聊天、传输、采集、播放和权限处理 | 功能取决于浏览器 API、权限和编解码能力 |
| Tauri 桌面客户端 | 复用前端，通过平台适配层接入 Windows 原生能力 | 提供原生采集、接收远程输入、系统文件访问及 HTTP MCP 端点 |
| 信令 Server 或 Worker | 维护房间在线状态，转发连接协商信息 | 同一房间使用同一端点；信令不负责中继聊天、文件或媒体 |
| STUN | 帮助设备发现对外网络地址 | 辅助建立直连，不承载共享内容 |
| TURN | 无法直连或选择仅中继模式时，转发 WebRTC 流量 | 中继可达性和带宽会影响传输与通话 |
| 客户端存储 | 分别保存本地历史、身份、权限、文件和录制 | 更换后端不会搬移或同步这些数据 |
Bun Server 与 Cloudflare Worker 配合 Durable Objects，是两种可选的信令实现。选择其中一种，只是改变信令运行的位置，现有客户端仍通过 WebSocket 地址接入。
从加入房间到交换内容
- 加载客户端。 浏览器下载网页界面，桌面端已内置前端。页面能打开，不代表已经连接到房间。
- 接入信令。 客户端连接配置的 WS/WSS 端点并加入房间。房间 ID 属于所选信令服务，不同服务上的相同 ID 不能让设备互通。
- 协商设备连接。 双方通过信令交换连接描述和候选网络地址。WebRTC 检查可用通路，包括 STUN 帮助发现的地址，以及已配置的 TURN 中继。
- 验证身份与权限。 设备建立配对，并在受保护操作前检查已保存的访问策略。加入房间本身不授权远程控制或自动化。
- 交换内容。 消息与文件数据使用 WebRTC 数据通道，麦克风、摄像头和屏幕视频使用媒体连接。不同内容可以使用独立通道或连接，因此聊天正常也不能证明视频采集、解码正常。
房间内的设备分别与其他参与者建立点对点连接。房间聊天把内容发给当前在线成员；向多个接收方共享内容，会占用发送设备的资源和上行带宽。信令后端不负责会议视频混流，也不充当集中分发文件的服务器。
信令与内容走不同通路
WSS 承载房间在线状态和连接协商。设备连接建立后，应用内容通过 WebRTC 传输：可以直连时走直连，需要时走 TURN 中继。TURN 转发流量，不会因此变成聊天历史服务或文件库。
信令服务仍可观察房间成员、客户端 ID 和协商时间等连接元数据。内容与信令分离，不代表运行后端就看不到任何元数据。
这也解释了连接常见问题中的排查顺序：HTTP 健康检查、WebSocket 连接和真实设备传输，分别验证不同阶段。加入房间或协商连接依赖信令可达性，内容吞吐还取决于直连或中继通路及两端设备。
复用前端，按平台提供能力
Web 与 Tauri 客户端复用 SolidJS 界面和应用流程，由平台适配层提供浏览器或桌面的具体能力，因此可以共享房间、会话、传输和权限模型。
浏览器中的采集、目录访问、解码等功能，受该浏览器提供的 API 限制。Windows 桌面适配层进一步接入原生采集、编解码、输入、文件操作和系统自动化。因此，被控制的电脑需要桌面端，而浏览器可以作为远程控制端。
客户端之间会交换能力，而不是假设所有设备支持相同操作或编码。媒体自动编码会综合发送端编码器和已连接接收端的解码能力。桌面原生媒体有自己的能力范围；浏览器能播放某种文件，也不代表其 WebRTC 通路支持同一种编码。参见音视频设置与编码兼容性问题。
本地数据与权限边界
| 数据或访问决定 | 由谁保存或执行 | 意味着什么 |
|---|---|---|
| 聊天历史、设备身份、配对及权限记录 | 当前浏览器或桌面端配置 | 不会自动跟随到另一个浏览器或电脑 |
| 接收的文件与录制 | 浏览器存储或选定的本地目录 | 选择目录不会把身份和设置搬进去，修改默认位置影响新文件 |
| 房间成员状态 | 所选信令服务 | 用于协调在线设备，不提供离线聊天投递或历史恢复 |
| 远程控制与自动化批准 | 目标设备 | 房间密码、邀请或相同设备名称都不等于控制授权 |
本地目录中的文件仍是真实文件。浏览器存储的文件依赖当前站点的数据，清除站点数据还可能移除历史和身份记录。保存与清理见文件存储管理，配对与授权见设备权限。
MCP 场景中，桌面 HTTP 端点通过 Token 认证接入的 MCP 客户端；远端操作再通过已有设备连接转发，并由目标设备检查自己的权限。目标设备不需要单独对外开放 HTTP MCP 监听。浏览器 WebMCP 属于另一种本地接入方式，不提供原生系统操作。参见 MCP 与自动化。
这些分工如何影响部署
网页托管、信令与中继可以分别选择和管理：
- 只想使用自己的信令服务：部署 Server 或 Worker，在现有网页或桌面端修改 WS 地址即可，无需构建前端。
- 也想管理浏览器访问入口：将 Web 前端托管到自己的域名，并选择默认连接配置。
- 需要支持无法直连的网络：接入可达的 TURN，可以使用托管服务或自行部署；单独部署信令不会增加中继能力。
- 需要预设桌面端默认值：按需构建 Tauri 安装包；现有安装包已能在设置中修改信令地址。
自部署导读提供了这些选择对应的部署路径。无论托管哪些组件，采集、编码、解码和文件保存仍在参与连接的设备上完成，增加信令服务器性能不会消除这些设备限制。
协议与底层实现
下面的专题沿着实际报文和实现边界展开，可以根据想深入了解的环节选择：
| 想了解的内容 | 继续阅读 |
|---|---|
| 加入房间、协商冲突与重连如何维持正确的连接 | 信令与会话恢复 |
| 消息、ACK、重试与能力声明分别意味着什么 | P2P 控制协议 |
| 文件字节如何拆块、请求缺失范围并完成校验 | 文件传输与断点续传 |
| 采集、编码、原生渲染与录制如何衔接 | 媒体传输与录制 |
| 浏览器与原生编解码、GPU 显示和画质参数如何配合 | 编码、解码与 GPU 显示 |
| 麦克风和系统声音如何经过编码、PCM 桥接与播放 | 音频采集、编解码与播放 |
| 当前连接的身份验证、配对恢复与权限如何配合 | 设备身份与授权 |
| 未完成文件、检查点、内容引用与删除如何工作 | 存储与文件生命周期 |
每篇都附有实现入口，方便继续追踪代码；功能操作与配置步骤仍在对应使用指南中。