WebSocket最大传输长度是多少 WebSocket大数据包拆分发送【指南】-js教程-PHP中文网

WebSocket无统一最大传输长度，实际受限于协议层（RFC 6455仅强制支持128MB）、服务端框架（如Netty默认10MB、Tomcat默认8KB）、反向代理（nginx默认4KB缓冲、Cloudflare免费版限10MB）及浏览器实现（Chrome/Firefox虽支持≥100MB但受内存与API限制），任一层超限均会导致连接关闭或异常。

websocket最大传输长度是多少 websocket大数据包拆分发送【指南】

WebSocket 没有统一的“最大传输长度”，实际能发多大，取决于协议层、服务端框架、反向代理、浏览器实现这四层叠加限制，且任意一层卡住都会导致连接关闭或 TooLongFrameException 等错误。

WebSocket 协议本身只规定了编码能力，不保证可用性

RFC 6455 允许用 64 位字段表示 payload 长度，理论支持到 2⁶⁴−1 字节（≈1.8 × 10¹⁹ B），但协议明确声明：实现只需保证至少支持 128 MB，更高值不强制互操作。这意味着：

客户端和服务端各自宣称支持 1GB，并不代表它们能互相收发 1GB 消息
超长帧没有标准恢复机制；一旦失败，连接大概率被单方面关闭
分片（fragmentation）是协议原生支持的，但需由应用层显式控制（如发送 ContinuationWebSocketFrame），浏览器 API 不暴露分片控制权

常见服务端框架的默认帧/消息长度限制

不同框架对 maxFramePayloadLength 或 maxMessageSize 的默认值差异极大，且底层依赖可能覆盖上层配置：

Netty：默认 WebSocketServerProtocolHandler 的 maxFramePayloadLength 是 10 * 1024 * 1024（10 MB），不改就抛 TooLongFrameException
Spring WebFlux：WebSocketSession.setMaxMessageSize(64 * 1024 * 1024) 可设到 64 MB，但若底层 Reactor Netty 未同步调大 maxFramePayloadLength，仍会截断
ws（Node.js）：默认 maxPayload: 100 * 1024 * 1024（100 MB），但在高并发下易触发 RangeError: invalid websocket frame length（V8 堆碎片所致）
Tomcat：需在 web.xml 中配 org.apache.tomcat.websocket.textBufferSize 和 org.apache.tomcat.websocket.binaryBufferSize，默认仅 8 KB

nginx、Cloudflare 等反向代理是隐形瓶颈

即便服务端和浏览器都放开限制，流量经过代理时仍会被二次拦截：

WebSocket 8.18.2

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

下载

nginx：proxy_buffer_size（默认 4 KB）、proxy_buffers（默认 8×4 KB）、client_max_body_size（影响 upgrade 请求头解析）三者共同决定 WebSocket 帧能否完整缓冲
Cloudflare：免费版硬性限制 WebSocket 单消息 ≤ 10 MB，且连接空闲超 100 秒即断；企业版可调，但需显式开启 WebSockets 功能开关
所有 TLS 终止点（如 ALB、CDN）若未启用 WebSocket 支持，会在 upgrade 阶段直接返回 400 或 426，根本进不到帧传输阶段