WebSocket大数据传输中，协议自动分片透明但不可控，仅解决帧大小限制；应用层手动分块才是实现断点续传、校验、幂等上传等业务需求的可靠方案。

WebSocket 发送大数据量时，分包与重组不是开发者必须手动干预的流程，而是协议内建机制与浏览器/服务端实现共同作用的结果。关键在于分清“协议原生分片”和“应用层分块”两种不同逻辑——前者由底层自动完成但不可控，后者需你主动设计才能支撑断点续传、校验、流控等真实业务需求。

浏览器自动分片：透明但有边界

当你调用 ws.send(arrayBuffer) 发送一个较大二进制数据（例如 20MB 文件），现代浏览器（Chrome/Firefox/Edge）通常会按内部策略将其拆成多个 WebSocket 帧：

• 首帧：FIN = 0，opcode = 2（二进制帧）
• 中间帧：FIN = 0，opcode = 0（continuation）
• 末帧：FIN = 1，opcode = 0（continuation）
• 整个过程对 JavaScript 层完全透明；接收端仍通过单个 message 事件收到完整 ArrayBuffer
• 触发分片没有统一阈值，常见在几 MB 到几十 MB 区间，取决于浏览器实现和内存压力
• 若服务端未严格遵循 RFC 6455 解析 FIN 和 opcode=0 帧，可能出现数据截断或解析失败

手动分块上传：断点续传与可靠性的基础

真正支持断线重连、进度追踪、校验恢复的，是前端在 JS 层把文件切片、编号、带元数据发送，服务端按序存盘并显式确认完成：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 使用 Blob.slice(start, end) 或 File.slice() 切出固定大小块（如 1MB）
• 每块封装为 JSON 对象发送：{ fileId: "abc", chunkIndex: 5, totalChunks: 12, data: arrayBuffer, hash: "sha256..." }
• 前端用 localStorage 或 IndexedDB 持久记录已成功上传的 chunkIndex 或字节偏移量
• 重连后先发查询请求（如 {"type":"query","fileId":"abc"}），服务端返回已收块列表，前端跳过继续发送
• 最后一块发送后，额外发一条文本帧 {"type":"complete","fileId":"abc"} 作为完成信号

服务端重组的关键实践

服务端不能依赖连接是否关闭来判断上传完成，必须基于应用层协议做状态管理：

• 每个分块写入磁盘临时路径：/tmp/uploads/{fileId}/{chunkIndex}，避免内存堆积
• 收到每块后比对前端传来的 hash 字段，不一致则返回错误，拒绝写入
• 收到 "complete" 指令后，按 chunkIndex 排序读取所有临时块，用流式方式（如 fs.createWriteStream）合并为目标文件
• 连接异常断开时，检查该 fileId 是否已标记完成；未完成则清理对应临时目录
• 所有操作需幂等：同一 fileId + chunkIndex 的重复上传应被识别并忽略

为什么不推荐依赖自动分片做关键传输？

协议级分片解决的是“单消息太大导致帧超限”的问题，但它不具备业务所需的可靠性语义：

• 不记录发送进度，断线即从头开始
• 不提供重传机制，任意一帧丢失整条消息失效
• 不保证消息送达顺序，多路并发发送时帧可能乱序（尽管协议要求按序重组，但丢帧后无法补）
• 无法做逐块校验、压缩、加密或权限控制
• 浏览器之间分片策略不一致，跨平台行为难保障