Java 11 java.net.http.WebSocket 不支持跨多次 sendBinary() 累积拼接超16KB消息；必须将应用层消息预分割为 ≤16KB 的独立帧，并对每一帧单独调用 sendBinary(..., true)，禁用内部累积缓冲。
java 11 `java.net.http.websocket` 不支持跨多次 `sendbinary()` 累积拼接超16kb消息；必须将应用层消息预分割为 ≤16kb 的独立帧，并对每一帧单独调用 `sendbinary(..., true)`，禁用内部累积缓冲。
在使用 Java 11 原生 java.net.http.WebSocket 实现客户端时，一个常见但易被忽视的关键限制是：其内部实现不遵循 RFC 6455 对“消息分片（message fragmentation）”的语义要求。尽管协议规范明确允许通过连续发送多个 FIN=false 的二进制帧来组成一条逻辑消息，Java 11 的 WebSocket 实现却将所有 last=false 的 sendBinary() 调用视为同一逻辑消息的“待累积片段”，并在收到首个 last=true 帧时尝试将此前所有未完成片段合并写入一个固定大小的内部缓冲区（默认 16,384 字节）。一旦累积总长度超过该阈值，即使单个帧远小于此值，也会触发 1009 错误（Message too big），正如错误日志所示：
No async message support and buffer too small. Buffer size: [16,384], Message size: [1,656]
⚠️ 注意：此处的 “Message size” 并非当前帧大小，而是自上次 last=true 后所有 last=false 帧的累计字节数 —— 这正是问题根源。
✅ 正确解决方案：应用层分帧 + 每帧独立终结
由于 Java 11 WebSocket 不支持真正的协议级分片传输，必须在应用层绕过该限制：
- 将原始业务消息按 ≤16,384 字节切分为多个独立、完整、可单独处理的应用帧（Application Segments）；
-
对每个帧调用
ws.sendBinary(buffer, true)，即始终设置last = true； - 服务端（如 Tomcat）需配合改造：识别这些独立帧为“逻辑上属于同一业务消息”，并自行在应用层完成重组（例如通过帧头携带消息ID与序号）。
这样，Java 客户端每次发送都是一条独立的、FIN=true 的 WebSocket 消息，完全规避了其内部累积缓冲机制，从而可靠支持任意大小的消息传输。
? 示例代码（安全分帧发送）
public void sendLargeBinary(WebSocket ws, byte[] payload) {
final int MAX_FRAME_SIZE = 16_384; // 必须 ≤ 16384
int offset = 0;
while (offset <h3>⚠️ 重要注意事项</h3>
-
不要混用
last=false和last=true：一旦开始发送last=false，就必须确保后续所有片段总和 ≤16,384 字节，否则必然失败；而采用“每帧独立终结”策略则彻底规避此约束。 -
服务端必须适配：Tomcat 等服务器虽能接收大消息，但默认会将每个
FIN=true帧作为独立onMessage()事件触发。你需要在协议设计中加入帧元数据（如messageId,sequence,totalParts），由服务端完成业务层拼接。 - 性能权衡：虽然增加了帧头开销和网络往返次数，但在绝大多数场景下（尤其是非高频小包），该方案稳定、可预测且无需依赖第三方库。
- 替代方案提示：若无法修改服务端逻辑，可考虑迁移到成熟 WebSocket 库（如 Jetty WebSocket Client 或 OkHttp），它们原生支持标准 RFC 分片。
总之，面对 Java 11 java.net.http.WebSocket 的这一实现局限，最稳健、最符合规范精神的做法，是将分片责任上移到应用层，并严格遵守“每帧自包含、每帧独立终结”的原则。这不仅解决了 16KB 瓶颈，也提升了协议设计的清晰性与跨平台兼容性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
