WebSocket仅用于传输指令，画面需通过WebRTC或MSE等独立通道传输；因其无编解码、帧同步和带宽自适应能力，直接传完整画面会导致延迟飙升、卡顿丢帧。
WebSocket 本身不传画面，只传指令；画面靠单独通道（如 WebRTC、MSE 或轮询）传输。想用 WebSocket 实现远程桌面控制，必须拆开处理：指令走 WebSocket，画面走另一路。
为什么不能只用 WebSocket 传完整桌面画面
WebSocket 是文本/二进制帧协议，没有内置视频编解码、帧同步或带宽自适应能力。直接 send() 一帧 PNG/JPEG（哪怕压缩过）会迅速打满连接、触发浏览器内存警告，且无法流式渲染。实测在 1080p 下，单帧 >150KB 时，ws.send() 调用延迟飙升，onmessage 接收出现明显卡顿和丢帧。
- WebSocket 设计目标是低延迟信令，不是媒体流载体
- 主流远程桌面方案（如 noVNC、Apache Guacamole）都把画面和指令分离：VNC/RFB over WebSocket 仅传像素差分，原始画面仍由服务端做编码
- 若强行用
ArrayBuffer发送原始帧，需手动实现帧序号、丢包重传、缓冲区管理——这已超出 WebSocket 职责范围
指令传输必须带 type 字段和白名单校验
前端捕获的 mousemove、keydown 等事件，不能原样发给后端。服务端必须对 type 字段做硬性校验，否则任意 JS 都能调用 robot.moveMouse()。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 合法
type值仅限："mouseMove"、"mouseClick"、"keyDown"、"clipboardSet"等预定义字符串 - 禁止透传原始 DOM 事件对象，例如不要发
{type: "keydown", event: {...}}——event属性不可序列化且含敏感信息 - 服务端收到指令后，应先检查
command.x/command.y是否在屏幕分辨率范围内，超界值直接丢弃 - 键盘指令需映射为 OS 可识别的键码（如
keyDown: {code: "KeyA", location: 0}），而非event.key === "a"
画面刷新必须配合独立通道 + 时间戳对齐
画面更新和指令执行必须有时间锚点，否则鼠标位置和画面帧严重不同步。推荐方案：服务端在推送画面帧时，附带一个单调递增的 frameId 或 timestampMs；指令中也携带最近一次收到的 frameId。
- 前端用
requestAnimationFrame渲染画面，同时用performance.now()记录每帧接收时间 - 当收到新指令时，计算它相对于当前画面帧的偏移量，决定是否延迟执行（例如：指令发生在 frameId=102，但当前只渲染到 100，则暂存队列）
- 画面通道建议用 WebRTC 的
RTCRtpReceiver或 MSE（Media Source Extensions），二者均支持video.currentTime精确控制 - 避免用
fetch()轮询截图：HTTP 开销大，无法保证帧率，且服务端需频繁生成 JPEG 导致 CPU 暴涨
心跳与空闲断连必须双向强制
远程桌面场景下，用户可能长时间无操作但未关闭页面。仅客户端发 ping 不够，服务端也必须定期验证连接活性，否则僵尸连接堆积会耗尽服务端 socket 资源。
- 约定 ping/pong payload 为 JSON：
{"type":"ping","ts":1716724588123}，服务端收到后必须回{"type":"pong","ts":...} - 客户端和服务端各自维护独立心跳定时器，超时阈值设为 30 秒；任一方连续 2 次未收到响应即
close() - 服务端在
ws.on('message')中检测非 ping/pong 消息时，重置该连接的空闲计时器；超过 5 分钟无任何消息则主动 close - 前端
onclose触发后，不要立即重连，加 1–3 秒随机退避，防止雪崩
真正难的不是建立 WebSocket 连接，而是让指令和画面在毫秒级延迟下保持时空一致。多数人卡在“画面动了但鼠标点不准”，根源往往是没对齐帧时间戳，或服务端未做坐标归一化（比如把 1920×1080 的坐标直接喂给 1366×768 的虚拟屏）。
