WebSocket 连接异常：CLOSING/CLOSED 状态与数据长度限制的排查与解决

1. 为什么WebSocket会突然进入CLOSING/CLOSED状态？

最近在做一个实时股票行情推送系统时，遇到了一个让人头疼的问题：WebSocket连接总是莫名其妙断开，浏览器控制台不断报错"WebSocket is already in CLOSING or CLOSED state"。刚开始以为是网络问题，后来发现每次推送大段K线数据时就会触发这个错误。

经过排查发现，这其实是WebSocket的一个自我保护机制。就像快递员送包裹，如果包裹太大超过了他的承载能力，他就会直接拒绝派送。WebSocket默认设置了一个8192字节（约8KB）的数据长度限制，当传输的数据超过这个限制时，连接就会自动进入关闭流程（CLOSING状态），最终完全断开（CLOSED状态）。

这个限制在不同的服务器环境中表现略有不同：

• Tomcat 7.x/8.x：默认8192字节
• Jetty：默认65536字节
• Netty：默认65536字节

有趣的是，这个限制其实是为了防止恶意攻击和内存溢出。想象一下如果有人故意发送超大数据包，服务器内存可能就会被撑爆。所以这个限制就像是一个安全阀，虽然有时候会给开发带来麻烦，但确实很有必要。

2. 如何判断问题是否由数据长度引起？

遇到WebSocket连接异常时，首先要确认是不是数据长度导致的。这里分享几个我常用的排查方法：

方法一：监控数据包大小

javascript复制// 前端发送数据时计算大小
const data = JSON.stringify({...});
console.log('Data size:', new Blob([data]).size);

// 后端接收时打印长度
@OnMessage
public void onMessage(String message, Session session) {
    System.out.println("Received message length: " + message.length());
}

方法二：逐步增加测试数据
我通常会准备几组测试数据：

1. 小于8KB的正常数据
2. 刚好8KB的临界数据
3. 明显大于8KB的数据

通过对比测试，如果发现只有大数据包会触发问题，那基本可以确定是