获取为什么websockets用关闭代码1006关闭的原因

Question 1

我想知道websockets关闭的原因，所以我可以向用户显示正确的消息。

我有

sok.onerror=function (evt) 
     {//since there is an error, sockets will close so...
       sok.onclose=function(e){
           console.log("WebSocket Error: " , e);}

代码始终为1006，原因始终为“”。但我想分开说说不同的结案原因。

例如，命令行给出了一个错误原因：“您不能删除它，因为数据库不允许您这样做”。但是在Chrome的控制台上，原因仍然是“”。

还有其他方法可以区分不同的关闭原因吗？

Question 2

关闭代码1006是一个特殊的代码，它表示浏览器实现异常（本地）关闭了连接。

如果您的浏览器客户端报告关闭代码1006，那么您应该在websocket.onerror(evt)事件中查看详细信息。

但是，Chrome很少会1006向Javascript方面报告任何接近代码的原因。这很可能是由于WebSocket规范中的客户端安全规则所致，以防止滥用WebSocket。（例如使用它扫描目标服务器上的开放端口，或为拒绝服务攻击生成大量连接）。

请注意，1006如果HTTP升级到Websocket时发生错误，Chrome通常会报告关闭代码（这是从技术上“连接” WebSocket之前的步骤）。由于诸如身份验证或授权不正确或协议使用不当（例如请求子协议，但服务器本身不支持该子协议）之类的原因，甚至是试图与非WebSocket的服务器位置进行通信的原因（例如尝试连接到ws://images.google.com/）

从根本上讲，如果您看到一个关闭的代码1006，则WebSocket本身有一个非常低级的错误（类似于“无法打开文件”或“套接字错误”），并不是真正的用户，因为它指出了一个低级问题与您的代码和实现。解决您的低级问题，然后在连接时可以包含更合理的错误代码。您可以根据项目的范围或严重性来完成此操作。示例：信息和警告级别是项目特定协议的一部分，不会导致连接终止。使用严重或致命消息进行报告时，还可以使用项目的协议来传达所需的详细信息，然后使用WebSocket关闭流的有限功能来关闭连接。

请注意，WebSocket关闭代码的定义非常严格，并且关闭原因短语/消息的长度不能超过123个字符（这是WebSocket的故意限制）。

但是，如果您只是出于调试原因而需要此信息，那么关闭的详细信息以及其潜在原因，并不是所有信息都会丢失，但通常会在Chrome的Javascript控制台中报告大量详细信息。

Question 3

就我而言，可能是@BIOHAZARD nginx proxy timeout。默认情况60下，套接字无活动的时间是秒

我将其更改为24hnginx并解决了问题

proxy_read_timeout 86400s;
proxy_send_timeout 86400s;

Question 4

Chrome似乎不符合WebSocket标准时，情况就是这样。当服务器启动关闭并向客户端发送关闭帧时，Chrome认为这是错误，并使用代码1006并没有原因消息将其报告给JS端。在我的测试中，Chrome从不响应服务器启动的关闭帧（关闭代码1000），表明代码1006可能表示Chrome正在报告自己的内部错误。

PS Firefox v57.00可以正确处理此情况，并成功将服务器的原因消息传递给JS端。

Question 5

认为这对其他人可能会很方便。孩子们，了解正则表达式很有用。呆在学校。

编辑：变成了方便的花花公子功能！

let specificStatusCodeMappings = {
    '1000': 'Normal Closure',
    '1001': 'Going Away',
    '1002': 'Protocol Error',
    '1003': 'Unsupported Data',
    '1004': '(For future)',
    '1005': 'No Status Received',
    '1006': 'Abnormal Closure',
    '1007': 'Invalid frame payload data',
    '1008': 'Policy Violation',
    '1009': 'Message too big',
    '1010': 'Missing Extension',
    '1011': 'Internal Error',
    '1012': 'Service Restart',
    '1013': 'Try Again Later',
    '1014': 'Bad Gateway',
    '1015': 'TLS Handshake'
};

function getStatusCodeString(code) {
    if (code >= 0 && code <= 999) {
        return '(Unused)';
    } else if (code >= 1016) {
        if (code <= 1999) {
            return '(For WebSocket standard)';
        } else if (code <= 2999) {
            return '(For WebSocket extensions)';
        } else if (code <= 3999) {
            return '(For libraries and frameworks)';
        } else if (code <= 4999) {
            return '(For applications)';
        }
    }
    if (typeof(specificStatusCodeMappings[code]) !== 'undefined') {
        return specificStatusCodeMappings[code];
    }
    return '(Unknown)';
}

用法：

getStatusCodeString(1006); //'Abnormal Closure'

{
    '0-999': '(Unused)',
    '1016-1999': '(For WebSocket standard)',
    '2000-2999': '(For WebSocket extensions)',
    '3000-3999': '(For libraries and frameworks)',
    '4000-4999': '(For applications)'
}

{
    '1000': 'Normal Closure',
    '1001': 'Going Away',
    '1002': 'Protocol Error',
    '1003': 'Unsupported Data',
    '1004': '(For future)',
    '1005': 'No Status Received',
    '1006': 'Abnormal Closure',
    '1007': 'Invalid frame payload data',
    '1008': 'Policy Violation',
    '1009': 'Message too big',
    '1010': 'Missing Extension',
    '1011': 'Internal Error',
    '1012': 'Service Restart',
    '1013': 'Try Again Later',
    '1014': 'Bad Gateway',
    '1015': 'TLS Handshake'
}

来源（为简洁起见，进行了少量编辑）：https : //developer.mozilla.org/zh-CN/docs/Web/API/CloseEvent#Status_codes

Question 6

在nginx代理下使用Chrome作为客户端并将golang gorilla websocket用作服务器时出现错误

每隔一秒钟解决问题，就从服务器向客户端发送一些“ ping”消息

Question 7

这可能是您在设备中使用的websocket URL不同（您从android / iphonedevice中击中了不同的websocket URL）