一、WebSocket应用场景
通俗的讲，WebSocket 是一种服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，实现真正的双向平等对话的协议。 WebSocket是为了解决HTTP的短链接而产生的一种协议。如果不与http客户端产生关系，那么直接用TCP协议即可。无需使用WebSocket协议。
所以，在web客户端如果实现双向通信，想要服务端主动往web客户端推送消息的话，可以考虑使用websocket技术。
二、WebSocket原理
WebSocet是借用了一层HTTP协议，又对TCP协议进一步封装而成的一种协议。
WebSocket是基于HTTP协议的，借用HTTP协议来完成了一部分握手动作。我们看websocket的请求头:
我们着重看请求头的这两行:
Upgrade: websocket
Connection: Upgrade
这两行是WebSocket的关键。通过这两行信息，告诉Apache、Nginx等http服务器，此协议要用WebSocket技术处理，而不是用HTTP协议处理。WebSocket技术诞生于2008年，至今大多数HTTP服务器已经支持了该协议。由此可见，WebSocket先通过HTTP协议与服务器建立联系，然后通知HTTP服务器，要按照WebSocket协议来处理。至此，客户端和服务端就建立了WebSocket长连接。
Sec-WebSocket-Key 是一个 Base64 encode 的值，这个是浏览器随机生成的，是会话的唯一标识。
我们再看服务器对WebSocket请求的响应:
这里就是HTTP协议负责的最后区域，告诉客户端，已经成功切换为WebSocket协议了。
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept 这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key ，作为身份认证使用。
至此，HTTP 已经完成它所有工作了，接下来就是完全按照 WebSocket 协议进行了。
三、WebSocket特点
- 建立在 TCP 协议之上，服务器端的实现比较容易。
- 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP代理服务器。
- 数据格式比较轻量，性能开销小，通信高效。
- 可以发送文本，也可以发送二进制数据。
- 没有同源限制，客户端可以与任意服务器通信。
- 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。
四、与HTTP协议区别
Websocket 其实是一个新协议，跟 HTTP 协议基本没有关系，只是为了兼容现有浏览器，所以在握手阶段使用了 HTTP 。
http协议是短链接，因为请求之后，都会关闭连接，下次重新请求数据，需要再次打开连接。WebSocket协议是一种长连接，只需要通过一次请求来初始化链接，然后所有的请求和响应都是通过这个TCP链接进行通信。
五、心跳机制
WebSocket是基于TCP协议的，TCP协议自带keepalive心跳机制。所以WebSocket也有keepalive心跳机制。
TCP的keepalive机制，我们后面研究。使用WebSocket技术，一般我们要自己实现心跳机制。那为什么不直接用TCP的keepalive机制呢，原因如下:
1.client异常挂死，此时keepalive机制无法反馈真实的client状态；
2.client 异常断电断网出现TCP假死keepalive并不能根本性解决问题，实际上互联网环境很不稳定；3.ws在应用层，基于传输层，在ws中操作TCP也很不方便。封装就意味着易用性提高灵活性降低。
所以我们在应用层开启心跳。(上面的原因，我们在研究TCP的keepalive后再做体会)。应用层频率为1次/10mins。
六、断开重连处理机制
客户端正常/异常断开处理机制:
服务端正常/异常断开处理机制:
server断电断网时client如何感知:
补充一下中间线路断网情况:
如:中间nat设备断网(互联网环境中间nat设备是非常多的)或者server网络断开.这里大家注意client断网不算是中间线路断网,因为client端断网应用程序马上可以感知.但是client所在局域网的出口nat断开的就算是中间网络断开.
其实上边已经提到了server网络断开的情况,分别说明了server和client各自的检测办法.但是很多网络不稳定的情况,如:断开18分钟后网络又恢复了,这里涉及到一个重连机制,首先大家要明白当中间网络断开时实际上是两段各自维护本端tcp的.最终会触发tcp强制拆链(不发送四次挥手).分为两种情况讨论:
(1)网络恢复时,client已经将自己连接断开了,但是server认为网络还在连接中,和tcp假死很像.这种情况在服务端检测心跳超时之前,服务端推送消息是没有办法到达客户端的.但是这时服务端的试图发消息动作会触发服务端发现这个连接已经断开了. 从现象看ws重连时间为: 网络恢复时间——>server发现连接断开(server发消息)+超时/server心跳检测超时 (前提:网络断开后到网络恢复中间这段时间server没法过消息给client,如果发送过可能网络连接上立即触发服务端发现连接断开.)
(2)网络恢复时,client没有将自己连接断开,但是server已经断开.这种情况在client下一次心跳发送后会触发tcp重发,重发一定时间没有回复client也会进行强制拆链.ws重连时间为:网络恢复时间——>client下一次心跳时间+超时. (前提:网络断开后到网络恢复中间这段时间client没发过心跳给server,如果发送过可能网络连接上立即触发客户端发现连接断开.)
上边两个前提有点难懂,意思是当网络断开到网络恢复中间这段时间发送过消息,那么这个消息第一次发送肯定是到不了对端,但是这时就已经开始tcp重传机制了,可能网络恢复时恰好有一次重传,你的消息可以发到对端了,但是对端tcp端口已经关闭,tcp发生异常也就立即触发了本端tcp的关闭.
综上:tcp重连是需要时间的,这个时间肯定是越短越好,但是又不能太短,这个时间的确定大家可以参考本篇最后的测试.