Excalidraw WebSockets连接稳定性优化技巧

Excalidraw WebSockets连接稳定性优化技巧

在现代远程协作场景中，一个看似简单的白板操作——比如画一条线——背后可能涉及数十次网络通信。当团队成员分布在不同时区、使用不同网络环境时，如何确保每个人看到的画面始终一致？这正是 Excalidraw 这类实时协同工具面临的核心挑战。

以一次典型的多人头脑风暴为例：北京的工程师刚拖动一个架构模块，上海的产品经理正准备标注需求，而旧金山的设计师突然进入隧道导致 Wi-Fi 断开。如果没有稳健的连接机制，这场协作很可能演变为“谁最后保存谁赢”的混乱局面。Excalidraw 的解决方案依赖于 WebSocket 协议，但仅仅建立连接远远不够。真正的难点在于维持连接的持久性和保障消息的可靠性。

WebSocket 是起点，而非终点

WebSocket 被广泛认为是实现实时交互的“银弹”，它通过单个 TCP 连接实现全双工通信，避免了传统轮询带来的高延迟与资源浪费。在 Excalidraw 中，每个用户的绘图动作都会被序列化为 JSON 消息，经由 WebSocket 实时广播给房间内其他成员，从而达成视觉同步。

但这套机制在真实世界中极易受挫。浏览器标签页休眠、手机切换蜂窝网络、Nginx 代理超时……任何一环都可能导致连接中断。更糟糕的是，WebSocket 并不像 TCP 那样自带保活机制。根据 MDN 文档，大多数中间设备（如负载均衡器、防火墙）会在连接空闲 60~300 秒后主动关闭它。这意味着，哪怕用户只是思考了两分钟，再下笔时可能已经脱离了协作状态。

因此，构建稳定体验的第一步不是选择协议，而是承认连接必然失败，并围绕这一前提设计容错策略。

心跳不止是“心跳”

很多人将心跳机制理解为定期发送ping消息，但实际上它的作用远不止于此。在 Excalidraw 的实践中，心跳是一种双向健康检查：

• 客户端每 30 秒向服务端发送ping；
• 服务端立即回应pong；
• 客户端监控是否在 45 秒内收到响应，否则判定为失联。

这个看似简单的流程解决了三个关键问题：

1. 对抗 NAT 超时：AWS ALB 默认空闲超时为 60 秒，Nginx 通常设为 60~180 秒。将心跳间隔控制在 30~40 秒，可有效防止连接被静默回收。
2. 检测不可达状态：某些网络环境下，WebSocket 的onclose事件并不会立即触发（例如 abrupt disconnection）。通过主动探测，客户端能更快感知异常，提前进入重连逻辑。
3. 服务端会话清理：服务端也可基于未响应的心跳来判断客户端离线，及时释放内存中的房间状态和游标信息。

class ExcalidrawCollaborationClient { startHeartbeat() { this.heartbeatInterval = setInterval(() => { if (this.socket.readyState === WebSocket.OPEN) { this.socket.send(JSON.stringify({ type: 'ping', timestamp: Date.now() })); } }, 30_000); // 监控最后一次 pong 的时间 this.pongTimeout = setTimeout(() => { if (!this.lastPongReceived || Date.now() - this.lastPongReceived > 45_000) { console.warn('❌ No pong received, forcing reconnect'); this.socket.close(); } }, 45_000); } handleIncomingMessage(message) { if (message.type === 'pong') { this.lastPongReceived = Date.now(); return; } // ... 处理其他消息 } onCloseHandler() { clearInterval(this.heartbeatInterval); clearTimeout(this.pongTimeout); // 触发重连 } }

这里有个工程细节容易被忽视：心跳频率不应固定不变。在移动端或弱网环境下，频繁心跳反而会加速电池消耗并加剧网络拥塞。更优的做法是动态调整，例如在检测到网络不稳定时缩短间隔（如 20 秒），而在稳定状态下适当延长（如 45 秒）。

重连策略：从“暴力重试”到智能恢复

最朴素的重连方式是断开后立即尝试重建连接。但这种方式在短暂网络抖动时会造成大量无效请求，甚至引发雪崩效应。Excalidraw 的生产实践表明，采用指数退避 + 随机抖动的重连策略，能在恢复成功率与系统压力之间取得最佳平衡。

具体做法如下：

• 初始重试间隔为 1 秒；
• 每次失败后乘以 1.5 倍（即 1s → 1.5s → 2.25s → 3.375s…）；
• 上限设为 30 秒，避免无限等待；
• 加入 ±10% 的随机抖动，防止多个客户端同时发起重连洪峰。

此外，重连不仅仅是重新建立 WebSocket 连接，还包括一系列上下文恢复操作：

1. 身份认证续签：携带原始 JWT Token 或刷新凭证；
2. 拉取最新快照：避免仅靠增量消息补全状态，防止因消息丢失导致画面错乱；
3. 恢复本地未同步操作：将断网期间的修改重新提交。

connect() { const url = this.buildWsUrl(); this.socket = new WebSocket(url); this.socket.onopen = () => { this.resetReconnectState(); this.sendAuth(); // 发送认证 this.requestSnapshot(); // 请求当前画布状态 this.flushLocalOperations(); // 补发本地缓存的操作 }; this.socket.onclose = () => { if (this.reconnectAttempts < this.maxRetries) { const delay = Math.min( INITIAL_RETRY_DELAY * Math.pow(1.5, this.reconnectAttempts), MAX_RETRY_DELAY ) * (0.9 + Math.random() * 0.2); // 添加抖动 setTimeout(() => { this.reconnectAttempts++; this.connect(); }, delay); } else { showNetworkError(); } }; }

值得注意的是，最大重试次数不宜设得太低。我们曾观察到，在地铁进站过程中，用户平均经历 8~12 秒的完全失联期。若限制为 3 次重试（总耗时约 5 秒），会导致频繁掉线。实际部署中建议设置为 8~10 次，并配合 UI 提示让用户知道系统仍在努力恢复。

消息不丢：ACK、幂等与本地缓冲的三位一体

即使有了稳定的连接，也不能保证每条消息都能抵达终点。TCP 只负责传输层可靠，而应用层仍需应对消息乱序、重复、丢失等问题。Excalidraw 的做法是引入一套轻量级的端到端确认机制。

其核心思想很简单：每一个关键操作都必须得到服务端的明确回应。如果 5 秒内未收到 ACK，则视为失败，进入重发队列。

class ReliableMessageSender { constructor(socket) { this.socket = socket; this.pendingAcks = new Map(); // opId → { msg, retryCount, timer } this.retryLimit = 3; this.ackTimeout = 5000; } sendMessage(operation) { const opId = generateId(); const envelope = { id: opId, ...operation }; this.pendingAcks.set(opId, { message: envelope, retryCount: 0, timer: setTimeout(() => this.handleAckTimeout(opId), this.ackTimeout) }); this.socket.send(JSON.stringify(envelope)); } handleAckTimeout(opId) { const pending = this.pendingAcks.get(opId); if (!pending) return; if (pending.retryCount < this.retryLimit) { this.socket.send(JSON.stringify(pending.message)); pending.retryCount++; pending.timer = setTimeout(() => this.handleAckTimeout(opId), this.ackTimeout); } else { this.pendingAcks.delete(opId); notifyUserOfSyncFailure(opId); } } receiveAck(ackId) { const pending = this.pendingAcks.get(ackId); if (pending) { clearTimeout(pending.timer); this.pendingAcks.delete(ackId); } } }

这套机制的关键在于选择性启用。并非所有消息都需要 ACK：

• ✅需要确认：元素增删改、文本编辑、图层调整等结构性变更；
• ❌无需确认：光标移动、鼠标悬停提示等临时状态更新。

否则，高频游标消息会迅速压垮 ACK 队列。实践中通常对游标数据进行采样降频（如每 200ms 最多发送一次），并通过 TTL 自动过期处理。

另一个重要设计是幂等性保障。由于重传的存在，同一操作可能多次到达服务端。为此，Excalidraw 在服务端使用操作 ID 做去重处理：

function applyOperation(op: Operation) { const existing = operationCache.get(op.id); if (existing) { return; // 已处理，直接忽略 } executeOperation(op); operationCache.set(op.id, true); setTimeout(() => operationCache.delete(op.id), 10_000); // 缓存窗口 }

结合客户端本地的操作日志，这套机制实现了“断网可编辑、恢复自动同步”的理想体验。用户即便在飞行模式下工作半小时，一旦联网，所有更改仍能完整还原。

架构权衡：规模、性能与一致性的三角关系

尽管上述机制显著提升了稳定性，但在大规模协作场景下仍需进一步考量系统边界。

房间容量限制

Excalidraw 推荐单个房间人数不超过 20 人，主要原因在于广播放大效应。若有 20 人同时在线，每人发送一条消息，服务端需广播 19 次，总计产生近 400 条接收事件。这不仅增加 CPU 开销，也提高了消息堆积风险。

解决方案包括：

• 使用 Redis Pub/Sub 解耦消息分发；
• 引入 WebSocket 网关集群，按房间 ID 分片；
• 对非活跃用户降级同步频率（如暂停游标更新）。

数据一致性模型的选择

目前 Excalidraw 采用的是“最终一致性”模型，即允许短暂不一致，但保证最终收敛。这种模型简单高效，适合多数协作场景。但对于更高要求的应用（如代码协同编辑），可考虑引入CRDT（无冲突复制数据类型）模型。

CRDT 的优势在于：
- 支持完全离线编辑；
- 自动解决并发冲突；
- 无需中心协调节点。

但代价是复杂度陡增，且对数据结构有严格要求。对于 Excalidraw 这类以图形为主的工具，CRDT 尚未成为必要选项，但值得作为未来演进方向。

这些年来，我见过太多实时协作产品倒在了“最后一公里”——功能齐全，界面精美，却输在一次不经意的网络切换上。而 Excalidraw 的可贵之处，在于它把稳定性当作基础能力而非附加特性来打磨。从心跳间隔的毫秒级调优，到重试策略中的随机抖动设计，每一处细节都在回答同一个问题：当用户最需要你的时候，系统能否依然可靠？

这种高度集成的设计思路，正引领着协同工具向更鲁棒、更人性化的方向演进。