简介
咱们晓得WebSocket是建设在TCP协定根底上的一种网络协议，用来进行客户端和服务器端的实时通信。十分的好用。最简略的应用WebSocket的方法就是间接应用浏览器的API和服务器端进行通信。
本文将会深入分析WebSocket的音讯交互格局，让大家得以明确，websocket到底是怎么工作的。
WebSocket的握手流程
咱们晓得WebSocket为了兼容HTTP协定，是在HTTP协定的根底之上进行降级失去的。在客户端和服务器端建设HTTP连贯之后，客户端会向服务器端发送一个降级到webSocket的协定，如下所示：
GET /chat HTTP/1.1Host: example.com:8000Upgrade: websocketConnection: UpgradeSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==Sec-WebSocket-Version: 13留神，这里的HTTP版本必须是1.1以上。HTTP的申请办法必须是GET
通过设置Upgrade和Connection这两个header，示意咱们筹备降级到webSocket了。
除了这里列的属性之外，其余的HTTP自带的header属性都是能够承受的。
这里还有两个比拟特地的header，他们是Sec-WebSocket-Version和Sec-WebSocket-Key。
先看一下Sec-WebSocket-Version， 它示意的是客户端申请的WebSocket的版本号。如果服务器端并不明确客户端发送的申请，则会返回一个400 ("Bad Request")，在这个返回中，服务器端会返回失败的信息。
如果是不懂客户端发送的Sec-WebSocket-Version，服务器端同样会将Sec-WebSocket-Version返回，以告知客户端。
这里要特地关注的一个header字段就是Sec-WebSocket-Key。咱们接下来看一下这个字段到底有什么用。
当服务器端收到客户端的申请之后，会返回给客户端一个响应，通知客户端协定曾经从HTTP降级到WebSocket了。
返回的响应可能是这样的：
HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=这里的Sec-WebSocket-Accept是依据客户端申请中的Sec-WebSocket-Key来生成的。具体而言是将客户端发送的Sec-WebSocket-Key 和 字符串"258EAFA5-E914-47DA-95CA-C5AB0DC85B11" 进行连贯。而后应用SHA1算法求得其hash值。
最初将hash值进行base64编码即可。
当服务器端返回Sec-WebSocket-Accept之后，客户端能够对其进行校验，已实现整个握手过程。
webSocket的音讯格局
之所以要应用webSocket是因为client和server能够随时随地发送音讯。这是websocket的神奇所在。那么发送的音讯是什么格局的呢？咱们来具体看一下。
client和server端进行沟通的音讯是以一个个的frame的模式来传输的。frame的格局如下：
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+MASK示意的是音讯是否是被编码过的，对于从client过去的音讯来说，MASK必须是1。如果client发送给server端的音讯，MASK不为1，则server须要断开和client的连贯。然而server端发送给client端的音讯，MASK字段就不须要设置了。
RSV1-3是扩大的字段，能够疏忽。
opcode示意怎么去解释payload字段。payload就是理论要传递的音讯。0x0示意持续，0x1示意文本，0x2示意二进制，其余的示意管制字段。
FIN示意是否是音讯的最初一个frame。如果是0，示意该音讯还有更多的frame。如果是1示意，该frame是音讯的最初一部分了，能够对音讯进行解决了。
为什么须要Payload len字段呢？因为咱们须要晓得什么时候进行接管音讯。所以须要一个示意payload的字段来对音讯进行具体的解决。
怎么解析Payload呢？这个就比较复杂。
- 首先读取9-15 bits，将其解析为无符号整数。如果其小于125，那么这个就是payload的长度，完结。如果是126，那么就去到第二步。如果是127，那么就去到第三步。
- 读取下一个16 bits，而后将其解析为无符号整数，完结。
- 读取下一个64 bits。将其解析为符号整数。完结。
如果设置了Mask，那么读取下4个字节，也就是32bits。这个是masking key。当数据读取结束之后，咱们就获取到了编码过后的payload:ENCODED,和MASK key。要解码的话，其逻辑如下：
var DECODED = "";for (var i = 0; i < ENCODED.length; i++) { DECODED[i] = ENCODED[i] ^ MASK[i % 4];FIN能够和opcode一起配合应用，用来发送长音讯。
FIN=1示意，是最初一个音讯。 0x1示意是text音讯，0x2是0，示意是二净值音讯，0x0示意音讯还没有完结，所以0x0通常和FIN=0 一起应用。
Extensions和Subprotocols
在客户端和服务器端进行握手的过程中，在规范的websocket协定根底之上，客户端还能够发送Extensions或者Subprotocols。这两个有什么区别呢？
首先这两个都是通过HTTP头来设置的。然而两者还是有很大的不同。Extensions能够对WebSocket进行管制，并且批改payload，而subprotocols只是定义了payload的构造，并不会对其进行批改。
Extensions是可选的，而Subprotocols是必须的。
你能够将Extensions看做是数据压缩，它是在webSocket的根底之上，对数据进行压缩或者优化操作，能够让发送的音讯更短。
而Subprotocols 示意的是音讯的格局，比方应用soap或者wamp。
子协定是在WebSocket协定根底上倒退进去的协定，次要用于具体的场景的解决，它是是在WebSocket协定之上，建设的更加严格的标准。
比方，客户端申请服务器时候，会将对应的协定放在Sec-WebSocket-Protocol头中：
GET /socket HTTP/1.1...Sec-WebSocket-Protocol: soap, wamp服务器端会依据反对的类型，做对应的返回，如：
Sec-WebSocket-Protocol: soap总结
本文解说了webSocket音讯交互的具体格局，能够看到很多弱小性能的协定，都是由最最根本的构造组成的。
本文已收录于 http://www.flydean.com/07-websocket-message/
最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！
欢送关注我的公众号:「程序那些事」,懂技术，更懂你！