题图：fabio / Unsplash
最近忙的事情是个大数据相关的产品，需求的核心是全量、准确、实时。
从之前的数字货币交易所的开发过程中就不断接触到 WebSocket 这个概念，现在几乎也是每天都会听到，实在受不住似懂非懂良心的良心的煎熬，果断研究了一波，故有此文。
首先来看维基百科的解释：
                 
WebSocket 是一种通信协议，可在单个 TCP 连接上进行全双工通信。WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就可以创建持久性的连接，并进行双向数据传输。
这么说吧，当你需要一个实时更新的页面时，WebSocket 就可以完美实现你的需求。
传统的 HTTP 协议是无状态的，每次发出请求时建立连接，收到回复时便会断开连接。如果使用 HTTP 协议来实现这个需求，就有下面两种方法可以考虑：
第一种是使用轮询的方式，在特定的时间间隔(如1秒)内向由浏览器向服务器发出 HTTP 请求，然后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点，即浏览器需要不断的向服务器发出请求，然而HTTP请求可能包含较长的头部，其中真正有效的数据可能只是很小的一部分，显然这样会浪费很多的带宽等资源。
第二种使用 Comet 去做轮询，它的原理就是发送一个更新请求后，就一直占据着端口，等待服务器响应，直到服务器有数据返回了才会断开连接。反复发出请求，而且普遍采用的是长链接，比较浪费服务器资源。
当原有的技术没法办法很好解决问题时，新的技术就会出现。
在这种情况下，HTML5 定义了 WebSocket 协议，能更好的节省服务器资源和带宽，并且能够更实时地进行通讯。
Websocket 使用 ws 或 wss 的统一资源标志符，类似于 HTTPS，其中 wss 表示在 TLS之 上的Websocket。如：
ws://example.com/wsapiwss://secure.example.com/wsapi
Websocket 使用和 HTTP 相同的 TCP 端口，可以绕过大多数防火墙的限制。默认情况下，Websocket 协议使用 80 端口；运行在 TLS 之上时，默认使用 443 端口。
大多数浏览器都支持该协议，包括 Google Chrome、Firefox、Safari、Microsoft Edge、Internet Explorer 和 Opera。
基本上，总结起来：如果你想实现一个实时性很强的网页，或者想向网页及时推送一些信息，尽可能选择 WebSocket 吧。
那 WebSocket 有没有缺点呢？
IE7 / IE8 / IE9 等沙雕古董浏览器不支持 Websocket ，其他没有了。
然后我们其实再多想一些：Websocket 会使用一次 HTTP的 报文握手，在那之后便是 WebSocket 自身规定的方式进行通讯了。它是个在各种网站都可能被用到的协议。既然它常见，那么就安全。
还可以利用各种 CDN 服务，将你的 WebSocket 进行代理，而让真实的服务器 IP 隐藏在重重 CDN之后。哪怕真实的服务器 IP 消失了，你的服务也不会失效。
只能讲这么多了，剩下的请自行 Google 一下，关键词「Websocket + 小辣椒」。
写到这里思考了下，由于微信公众号不支持外链，很多微信外有价值的内容没法展示出来，但是按照微信现在的策略，对小程序的跳转是没有限制的，因此我们可以在公众号文章中自由插入 GitHub 仓库的小程序链接，方便访问仓库的详情提升阅读体验。
小辣椒-over-websocket
这个操作实在太机智了，值得点个在看。?

	

一、概述
上一篇文章《浅析一次HTTP请求》我们分析了简单的一次 HTTP 请求具体是怎么样完成的，分析了 HTTP 协议的数据结构，如何连接，如何断开，又是如何多路复用的，那么今天我们来聊聊另外一个协议，WebSocket。由于 WebSocket 的协议的内容非常多，本文只会取其冰山一角进行简单阐述，不会铺开详细说。
二、什么是 WebSocket
2.1 WebSocket 产生的背景
在 WebSocket 协议出现以前，创建一个和服务端进双通道通信的 web 应用，需要依赖HTTP协议，进行不停的轮询，这会导致一些问题：
服务端被迫维持来自每个客户端的大量不同的连接
大量的轮询请求会造成高开销，比如会带上多余的header，造成了无用的数据传输。
所以，为了解决这些问题，WebSocket 协议应运而生。
2.2 WebSocket 的定义
WebSocket 是一种在单个TCP连接上进行全双工通信的协议。WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。
在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。(维基百科)
三、WebSocket 的基础帧结构分析
下图是我参考 RFC6455 5.2章节画的websocket 基础帧的数据结构图，接下里我们重点解析下数据结构图。
FIN:占用1 bit，表示这是消息的最后一个片段。第一个片段也有可能是最后一个片段。
RSV1，RSV2，RSV3: 每个1 bit
必须设置为0，除非扩展了非0值含义的扩展。如果收到了一个非0值但是没有扩展任何非0值的含义，接收终端必须断开WebSocket连接。
Opcode: 4 bit,操作码，如果收到一个未知的操作码，接收终端必须断开WebSocket连接。
%x0 表示一个持续帧
%x1 表示一个文本帧
%x2 表示一个二进制帧
%x3-7 预留给以后的非控制帧
%x8 表示一个连接关闭包
%x9 表示一个ping包
%xA 表示一个pong包
%xB-F 预留给以后的控制帧
Mask: 1 bit，mask标志位，定义“有效负载数据”是否添加掩码。如果设置为1，那么掩码的键值存在于Masking-Key中。
Payload length: 7 bits, 7+16 bits, or 7+64 bits，以字节为单位的“有效负载数据”长度。
Masking-Key: 0 or 4 bytes，所有从客户端发往服务端的数据帧都已经与一个包含在这一帧中的32 bit的掩码进行过了运算。如果mask标志位(1 bit)为1，那么这个字段存在，如果标志位为0，那么这个字段不存在。
备注：载荷数据的长度，不包括mask key的长度。。
Payload data：有效负载数据
为什么需要掩码？
为了安全，但并不是为了防止数据泄密，而是为了防止早期版本的协议中存在的代理缓存污染攻击(proxy cache poisoning attacks)等问题。
四、 抓包分析
4.1 DEMO展示及分析
我写了一个DMEMO用来抓包分析 websocket,源代码会放在文章末尾的链接。DEMO效果如下：
页面提供连接与断开功能，输入自己的名字发送，服务端返回Hello,名字！功能很简单，我们先看看页面的请求和响应。
请求：
响应：
这里的请求与响应就是反应了 WebSocket 的一次握手，我们根据上图可以简单抽象一下 WebSocket 的请求和响应格式：客户端握手请求格式：
 GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
服务端握手响应：
 HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
我们重点说明下结果请求字段：
Upgrade：
表示HTTP协议升级为webSocket
connection:Upgrade 请求升级。
Sec-WebSocket-Key：
用于服务端进行标识认证，生成全局唯一id,GUID。
Sec-WebSocket-Version：
版本
Sec-WebSocket-Protocol: 请求服务端使用指定的子协议。
如果指定了这个字段，服务器需要包含相同的字段，并且从子协议的之中选择一个值作为建立连接的响应。
Sec-WebSocket-Extensions: WebSocket的扩展。
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 生成的全局唯一id，GUID。
4.2 抓包
我在DEMO中的操作流程如下：
连接WebSocket
发送“LUOZHOU”
断开连接
用 Wireshark 抓包如下：
我们结合浏览器截图和抓包截图，发现在真正开启 websocket 之前，浏览器会有两次http请求，分别是：
A请求 GET /gs-guide-websocket/info?t=1551252237372 HTTP/1.1

B请求 GET /gs-guide-websocket/690/pdsz5x1q/websocket HTTP/1.1
根据 RFC6455 协议规定 WebSocket 只需要一次握手就可以完成，所以我们只需要分析第二次的http 握手请求，A请求应该是使用的框架层面自己实现。
我们根据截图可以知道，B请求对应的响应是序号 192 的数据，返回码是101，根据 HTTP 返回码我们可以知道，服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在 Upgrade 消息头中定义的那些协议，也就是升级为 WebSocket 协议。所以接着193的包已经变成了 WebSocket 协议了。到这里，WebSocket 的握手连接就已经完成了。
接下来我们分析下发送消息的流程，这里大家肯定会疑惑，就发送了一条消息，为啥会有这么多 WebSocket 的包呢？其实这里多余的包是框架层面进行发送的，比如要进行订阅与发布的注册等等操作。所以真正使我们操作的包就只有断开连接的相关包和发送“LUOZHOU”的包
根据上图我们发现 序号229的包是一个文本类型的包，opcode:1,然后采用了掩码处理，同时是最后一个处理包。我们仔细发现所有客户端发送服务端的包都会有[MASKED]标记，服务端返回的没有，这就说明了从客户端向服务端发送数据时，需要对数据进行掩码操作；从服务端向客户端发送数据时，不需要对数据进行掩码操作。
五、总结
WebSocket 是为了在 web 应用上进行双通道通信而产生的协议，相比于轮询HTTP请求的方式，WebSocket 有节省服务器资源，效率高等优点。
WebSocket 中的掩码是为了防止早期版本中存在中间缓存污染攻击等问题而设置的，客户端向服务端发送数据需要掩码，服务端向客户端发送数据不需要掩码。
WebSocket 中 Sec-WebSocket-Key 的生成算法是拼接服务端和客户端生成的字符串，进行SHA1哈希算法，再用base64编码。
WebSocket 协议握手是依靠 HTTP 协议的，依靠于 HTTP 响应101进行协议升级转换。
作者：木木匠
链接：https://juejin.im/post/5c693a4f51882561fb1db0ff

利用nginx代理websocket的时候，发现客户端和服务器握手成功后，如果在60s时间内没有数据交互，连接就会自动断开，如下图：

为了保持长连接，可以采取来两种方式．
１．nginx.conf 文件里location 中的proxy_read_timeout 默认60s断开，可以把他设置大一点，你可以设置成自己需要的时间，我这里设置的是十分钟（600s）．
nginx配置如下：
server {
		listen 80;
		server_name carrefourzone.senguo.cc;
		#error_page 502 /static/502.html;

		location /static/ {
		    root /home/chenming/Carrefour/carrefour.senguo.cc/source;
		    expires 7d;
        	}

		location / {
		    proxy_pass_header Server;
		    proxy_set_header Host $http_host;
		    proxy_redirect off;
		    proxy_set_header X-Real-IP $remote_addr;
		    proxy_set_header X-Scheme $scheme;
		    proxy_pass       http://127.0.0.1:9887;
		    proxy_http_version  1.1;
		    proxy_set_header    Upgrade    "websocket";
		    proxy_set_header    Connection "Upgrade";
		    proxy_read_timeout 600s; 
		}
	}
按照上述方法设置好后，我们可以发现，如果在10分钟之内没有数据交互的话，websocket连接就会自动断开，所以这种方式还是有点问题，如果我页面停留时间超过十分钟而且又没有数据交互的话，连接还是会断开的，所以需要同时结合第二种方法．
上面nginx配置的时候还出了一个小插曲，微改了nginx配置之后，没有重启nginx服务，导致设置的过期时间一直没有生效，所以需要用　sudo nginx -s reload 　重启nginx服务
2.在nginx延长超时时间的基础上，前端在超时时间内发心跳包，刷新再读时间，前端具体实现见如下代码(此处代码包含了前端整个websocket的实现过程，其中红色重点标注了发心跳包的内容)：
// websocket连接
var websocket_connected_count = 0;
var onclose_connected_count = 0;
function newWebSocket(){
    var websocket = null;
    // 判断当前环境是否支持websocket
    if(window.WebSocket){
        if(!websocket){
            var ws_url ="wss://"+domain+"/updatewebsocket";
            websocket = new WebSocket(ws_url);
        }
    }else{
        Tip("not support websocket");
    }

    // 连接成功建立的回调方法
    websocket.onopen = function(e){
        heartCheck.reset().start();   // 成功建立连接后，重置心跳检测
        Tip("connected successfully")
    }
    // 连接发生错误，连接错误时会继续尝试发起连接（尝试5次）
    websocket.onerror = function() {
        console.log("onerror连接发生错误")
        websocket_connected_count++;
        if(websocket_connected_count <= 5){
            newWebSocket()
        }
    }
    // 接受到消息的回调方法
    websocket.onmessage = function(e){
        console.log("接受到消息了")
        heartCheck.reset().start();    // 如果获取到消息，说明连接是正常的，重置心跳检测
        var message = e.data;
        if(message){
           //执行接收到消息的操作，一般是刷新ＵＩ
        }
    }

    // 接受到服务端关闭连接时的回调方法
    websocket.onclose = function(){
        Tip("onclose断开连接");
    }
    // 监听窗口事件，当窗口关闭时，主动断开websocket连接，防止连接没断开就关闭窗口，server端报错
    window.onbeforeunload = function(){
        websocket.close();
    }

    // 心跳检测, 每隔一段时间检测连接状态，如果处于连接中，就向server端主动发送消息，来重置server端与客户端的最大连接时间，如果已经断开了，发起重连。
    var heartCheck = {
        timeout: 55000,        // 9分钟发一次心跳，比server端设置的连接时间稍微小一点，在接近断开的情况下以通信的方式去重置连接时间。
        serverTimeoutObj: null,
        reset: function(){
            clearTimeout(this.timeoutObj);
            clearTimeout(this.serverTimeoutObj);
            return this;
        },
        start: function(){
            var self = this;
            this.serverTimeoutObj = setInterval(function(){
                if(websocket.readyState == 1){
                    console.log("连接状态，发送消息保持连接");
                    websocket.send("ping");
                    heartCheck.reset().start();    // 如果获取到消息，说明连接是正常的，重置心跳检测
                }else{
                    console.log("断开状态，尝试重连");
                    newWebSocket();
                }
            }, this.timeout)
        }
    }
}

上述过程就是保持长连接的过程，前端部分也包含了大部分websocket初始化的内容．

1.nodejs里用的是ws那个库
2.用户断开连接的代码是这样写的
var WebSocketServer = require('D:/0.ProgramFiles/2.Devel/4.NodeJs/node_modules/ws').Server;
var wss = new WebSocketServer({port: 8888});
var userList = [];
wss.on('connection', function (ws,req) {
// console.log(req.connection.remoteAddress)
console.log(getUUID());
ws.on('message', function (message) {
console.log("收到消息：" + message);
wss.clients.forEach(function each(client) {
client.send(message);
});
});
ws.on('close', function (message) {
console.log(id);
});
});
现在的情况是：
用户直接关闭前台网页后，后端只能收到1001这个数字，
怎么能获取具体是哪个用户下线了呢？？？