前提说明
本篇文章对websocket的连接关闭码做一下说明，而且会教你如何在windows上本地模拟closeStatus=1006的情况。
使用的技术栈说明：
后端：spring-boot-starter-websocket + sockjs + stomp-websocket
前端：sockjs + stomp.js
关闭状态码一览表
| 状态码 | 名称 | 描述 |
| 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 | 可以由应用使用. |
从上图中我们可以看到，closeStatus=1000是正常关闭，closeStatus=1006是非正常关闭，一般非正常的情况就比较复杂一些，如果你查资料，大多情况都是因为websocket 连接在nginx 配置的 proxy_read_timeout 内没有收到数据，nginx主动发起的连接断开（不是客户端主动断开，也不是服务端主动断开的），本篇文章就模拟这种情况。
域名映射
因为我是在windows上模拟，我需要先加一个域名，打开 C:/Windows/System32/drivers/evt/hosts文件，新增一行：
127.0.0.1 www.testwebsocekt.com
这样，我们访问域名www.testwebsocekt.com时就是访问本地服务了。
Nginx Websocket配置
server { listen 80; server_name www.testwebsocekt.com; # 上面配置的域名 location /test-ws { proxy_set_header Host $host:8000; proxy_pass http://localhost:8081/test-ws; #http://localhost:8081/test-ws 为本地后端服务websocket配置的Endpoint proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header X-real-ip $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; } }
proxy_read_timeout 默认为60s
启动 start nginx 。
代码实现
- 后端打印closeStatus
(SessionDisconnectEvent.class) public void handleWebsocketDisconnectListner(SessionDisconnectEvent event) { LOGGER.info("=====session closed : sessionId={}, status={}", event.getSessionId(), event.getCloseStatus()); }
- 前端websocket客户端实现
<script type="application/javascript" src="sockjs.min.js"></script> <script type="application/javascript" src="https://cdn.bootcss.com/stomp.js/2.3.3/stomp.min.js"></script> <script> // 同服务端建立连接 let socket = new SockJS('http://www.testwebsocekt.com/test-ws'); stompClient = Stomp.over(socket); connect(); function connect() { stompClient.connect( {}, // 连接成功回调函数 frame => { console.log('服务端 Socket 连接建立') // something... }, function(error) { console.log('Socket 连接失败, error: ' + error); } ); };
运行服务观察现象
通过Chrome Network工具我们可以观察到：
- 客户端和服务端成功建立了连接
- 每隔25s客户端就会收到一条内容 "h"，其实就是服务端发送的心跳信息，具体代码在org.springframework.web.socket.sockjs.transport.session.AbstractSockJsSession.HeartbeatTask，有兴趣的可以看一下
我们上面说过 nginx 的proxy_read_timeout 默认为60s，那我们改小一点，比如改为：10s，加一行配置
proxy_read_timeout 10s;
重启nginx -s reload 后，刷新客户端页面重新建立连接后过了大概10s，服务端收到了DISCONNECT的请求：
我们期望的closeStauts.code = 1006出现了。
再来看客户端，
建立连接后，还没等收到心跳信息（隔25s才会收到）时，nginx配置的proxy_read_timeout 就已经超时了，所以nginx向服务端发送的DISCONNECT请求（closeStaus.code=1006）。
总结
上面我们在windows系统上模拟了websocket出现closeStatus=1006的情况，一般出现这种情况都是非正常关闭，此时就需要我们关注这个问题了，解决方案也比较简单：
- 增大nginx的proxy_read_timeout 时间设置；
- 减小服务端和客户端之间的心跳间隔；
