一、简介
WebSocket一种在单个 TCP 连接上进行全双工通讯的协议，起初由 HTML5 定义，后被IETF定为标准RFC 6455，最新规范为RFC7936。
二、来源背景
基本的 HTTP 是半双工的请求-响应的模式：客户端发起请求，服务端响应请求。
问题一：服务端如何实时地主动推送最新数据到客户端？
方案一：轮询 客户端定期发起请求，服务器立即返回响应。 缺点： 1. 轮询每次要发起请求建立连接，效率低下。 2. 响应内容不可预测，当HTTP请求头部大于有效数据，浪费带宽资源。
方案二：Comet技术（长轮询和iframe流） 长轮询：客户端发出请求，服务器收到请求后，在请求内容不可得时，对客户端不立即返回响应，而是延后一段时间。如果需要的内容在延后的时间内出现则返回，否则，服务器关闭请求。 缺点： 1. 并发请求较大时，服务器需要维护长轮询产生的长连接，损耗了服务器性能。 iframe流：在页面中插入一个隐藏的iframe，利用其src属性在服务器和客户端之间创建一条长链接，服务器向iframe传输数据，来实时更新页面。
共同缺点：
基于 HTTP 的传输技术实现繁杂、开销较大（比如频繁的 TCP 握手和 HTTP header 传递），而且总是会受到 HTTP 单向传输和连接数的限制
三、优点
1. 较少的控制开销。在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。在不包含扩展的情况下，对于服务器到客户端的内容，此头部大小只有2至10字节（和数据包长度有关）；对于客户端到服务器的内容，此头部还需要加上额外的4字节的掩码。相对于HTTP请求每次都要携带完整的头部，此项开销显著减少了。 2. 更强的实时性。由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；即使是和Comet等类似的长轮询比较，其也能在短时间内更多次地传递数据。 3. 保持连接状态。于HTTP不同的是，Websocket需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）。 4. 更好的二进制支持。Websocket定义了二进制帧，相对HTTP，可以更轻松地处理二进制内容。 5. 可以支持扩展。Websocket定义了扩展，用户可以扩展协议、实现部分自定义的子协议。如部分浏览器支持压缩等。 6. 更好的压缩效果。相对于HTTP压缩，Websocket在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率。 7. Websocket使用和 HTTP 相同的端口，可以绕过大多数防火墙的限制。默认情况下，Websocket协议使用80端口；运行在TLS之上时，默认使用443端口
四、HTTP & Websocket
Websocket 解决了服务端主动向客户推送数据的难题，而 HTTP/2 提供了 server push 特性，两者有何不同，HTTP/2 能否取替 Websocket ？ HTTP/2 的 Server push 特性： 通过服务端在主页响应之前，通过一个 PUSH PROMISE 告诉客户端有哪些比较重要资源需要预先加载，只能被浏览器执行用于加载文件；如果客户端没有请求，服务端并不能主动推送。
五、适用场景
1. 实时性要求高 2. 无明显 C/S 结构的消息交换，如：无中心多人聊天（嗯 受 pandada 指正这个需求应该用 WebRTC） 3. 高频次、小体积消息传输
六、其他
1）Real-Time Web Applications with WebSocket
2）Nginx WebSocket proxying
七、其他
1）如何解决WebSocket Server返回数据不一致问题
