WebSocket断开的原因有很多，最好在WebSocket断开时，将错误打印出来。
 ws.onclose = function (e) {
 console.log('websocket 断开: ’ + e.code + ’ ’ + e.reason + ’ ’ + e.wasClean)
 console.log(e)
 }
 错误状态码：
 
WebSocket断开时，会触发CloseEvent, CloseEvent会在连接关闭时发送给使用 WebSockets 的客户端. 它在 WebSocket 对象的 onclose 事件监听器中使用。CloseEvent的code字段表示了WebSocket断开的原因。可以从该字段中分析断开的原因。
 
CloseEvent有三个字段需要注意, 通过分析这三个字段，一般就可以找到断开原因
 
CloseEvent.code: code是错误码，是整数类型
 CloseEvent.reason: reason是断开原因，是字符串
 CloseEvent.wasClean: wasClean表示是否正常断开，是布尔值。一般异常断开时，该值为false
 状态码 名称 描述
 0–999 保留段, 未使用.
 1000 CLOSE_NORMAL 正常关闭; 无论为何目的而创建, 该链接都已成功完成任务.
 1001 CLOSE_GOING_AWAY 终端离开, 可能因为服务端错误, 也可能因为浏览器正从打开连接的页面跳转离开.
 1002 CLOSE_PROTOCOL_ERROR 由于协议错误而中断连接.
 1003 CLOSE_UNSUPPORTED 由于接收到不允许的数据类型而断开连接 (如仅接收文本数据的终端接收到了二进制数据).
 1004 保留. 其意义可能会在未来定义.
 1005 CLOSE_NO_STATUS 保留. 表示没有收到预期的状态码.
 1006 CLOSE_ABNORMAL 保留. 用于期望收到状态码时连接非正常关闭 (也就是说, 没有发送关闭帧).
 1007 Unsupported Data 由于收到了格式不符的数据而断开连接 (如文本消息中包含了非 UTF-8 数据).
 1008 Policy Violation 由于收到不符合约定的数据而断开连接. 这是一个通用状态码, 用于不适合使用 1003 和 1009 状态码的场景.
 1009 CLOSE_TOO_LARGE 由于收到过大的数据帧而断开连接.
 1010 Missing Extension 客户端期望服务器商定一个或多个拓展, 但服务器没有处理, 因此客户端断开连接.
 1011 Internal Error 客户端由于遇到没有预料的情况阻止其完成请求, 因此服务端断开连接.
 1012 Service Restart 服务器由于重启而断开连接.
 1013 Try Again Later 服务器由于临时原因断开连接, 如服务器过载因此断开一部分客户端连接.
 1014 由 WebSocket标准保留以便未来使用.
 1015 TLS Handshake 保留. 表示连接由于无法完成 TLS 握手而关闭 (例如无法验证服务器证书).
 1016–1999 由 WebSocket标准保留以便未来使用.
 2000–2999 由 WebSocket拓展保留使用.
 3000–3999 可以由库或框架使用.? 不应由应用使用. 可以在 IANA 注册, 先到先得.
 4000–4999 可以由应用使用.
 
END

最近从在写一个课程上报的模块，要求前端使用websocket长连接到后端，实现实时上报学习进度的功能。这次没有使用php或者java，尝试使用一把golang作为上报模块的开发语言。用到了gorm和websocket，这次总结下遇到的坑。
 
1.websocket无法检测到连接断开
 
在使用websocket的时候，因为其底层基于tcp连接，所以不执行发送命令是获取不到连接断开的通知的；因此前端发送心跳包到后端，后端可以以返回一个心跳包的形式，判断是否出现err，如果出现err则说明连接断开，处理断开后的逻辑，保存进度等操作。
 
2.gorm导致的504问题
 
从百度和google搜到的全部都是因为Quer导致的rows没有close的问题，还有说使用gorm的db.Close解决，但我们都没解决。用navicat->工具->服务器监控发现数据库里建立了大量的链接。
 最后发现是程序处理心跳的协程使用for死循环，使用了事务，但是open没有执行rollback或者commit，直接continue了，continue之后又会执行一个新的事务begin。加上rollback就解决了

前段时间由于工作需要，自己使用websocket编写了一个简单的IM功能，刚开始测试时，简单的测试了功能，都可以满足要求，后来发现通信不是很稳定。
 
后来专门花时间测试，最终发现是服务器那边对连接有个默认超时释放的机制。
 
解决方案
 
 
 
在客户端的连接关闭事件中处理。我就添加每次关闭后自动尝试重新连接服务器的功能，之后再测试，功能稳定了。
调整超时参数。我测试出的时间为1分钟无动作后自动断开，应该是服务器主动断开的。现在还不知道在那里调整这个参数。看来自己对通信机制了解不足，等找到调整地方再来更新。
 
 

 

服务主要架构 springcloud
 springboot
 springcloud gateway 网关
 nginx 反向代理
 
问题：
 
客户端连接websocket，握手正常，服务端和客户端正常交互，停一会就客户端就会出现 WebSocketBase::onCloseWrapper code : 1009 reason: The decoded text message was too big for the output buffer and the endpoint does not support partial messages remote : true[^1]: 大致意思就是数据量太大服务端无法处理，并且断开了连接。1009就是数据帧太大，关闭连接。
 
debug：
 
通过debug 发现 默认最大处理是 8192字节，由于客户端发的信息大于8192个字节，所以才会出现这种问题。
 
解决方法：
 
修改前：
 
    @OnOpen
    public void onOpen(Session session) {
        log.info("有新的客户端连接了: {}", session.getId());
    }
 
修改后：
 
    @OnOpen
    public void onOpen(Session session) {
        session.setMaxTextMessageBufferSize(maxMessageBufferSize);
        session.setMaxBinaryMessageBufferSize(maxMessageBufferSize);
        log.info("有新的客户端连接了: {}", session.getId());
    }