websocket本质是客户端与服务器间的长连接，非真正p2p；实现a向b私聊需服务端维护用户id与websocket会话映射，消息携带结构化收件人字段，并校验目标会话有效性。
WebSocket 本身不是真正的 P2P，它本质是客户端与服务器之间的长连接。所谓“点对点”在 WebSocket 场景中，是指消息由服务端**精准路由到指定目标用户**，而非广播给所有人——即逻辑上的私聊，物理上仍经由中心服务器中转。
核心：服务端需维护用户身份与连接的映射关系
要实现 A 给 B 发消息、只有 B 收到，关键在于服务端能识别谁是谁、谁连着谁。常见做法是：
- 客户端连接时，通过 URL 参数（如
?userId=1001）、Token 或握手阶段的 HTTP Header 传递唯一用户标识 - 服务端用
Map<string websocketsession></string>（如 Java）或Map<userid ws></userid>（如 Node.js）实时记录在线用户及其会话 - 每次收到消息，解析目标接收者 ID（例如消息体里带
{"to": "1002", "content": "hi"}），查表找到对应 session，直接 send
消息格式需明确收件人字段
不能只发原始文本。客户端发送的消息必须携带结构化信息，典型 JSON 示例：
{"type":"private","to":"2005","from":"1001","content":"你好，今天忙吗？"}服务端据此提取 to 字段，定位目标 session；同时可校验 from 是否合法，避免伪造身份。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
连接状态必须实时校验
目标用户可能已断线，但 session 还没及时清理。发送前务必检查：
- 目标 session 是否存在（map 中有 key）
- session 的
isOpen()或readyState === OPEN是否为真 - 建议搭配心跳机制（ping/pong）定期探测，超时未响应则主动移除 session
注意不是真 P2P，而是服务端可控的单播
这种方案不涉及 NAT 穿透、信令交换或 WebRTC 那样的浏览器直连。所有流量走服务端，好处是：
- 兼容性好，无需 STUN/TURN 服务器
- 权限和审计可控（可记录谁何时发给谁）
- 易于扩展群聊、离线消息、消息回执等功能
缺点是服务器成为瓶颈和单点，高并发时需做连接池、分片或引入消息队列（如 RabbitMQ）解耦。
