WebSocket协议（rfc6455）原文地址：
https://datatracker.ietf.org/doc/html/rfc6455websocket 协议 HTML5 带来的新协议，相对于 http，它是一个持久连接的协议，它利用 http 协议完成握手，然后通过 TCP 连接通道发送消息，使用 websocket 协议可以实现服务器主动推送消息。
首先，客户端若要发起 websocket 连接，首先必须向服务器发送 http 请求以完成握手，请求行中的 path 需要使用ws:开头的地址，请求头中要分别加入upgrade、connection、Sec-WebSocket-Key、Sec-WebSocket-Version标记
然后，服务器收到请求后，发现这是一个 websocket 协议的握手请求，于是响应行中包含Switching Protocols，同时响应头中包含upgrade、connection、Sec-WebSocket-Accept标记
当客户端收到响应后即可完成握手，随后使用建立的 TCP 连接直接发送和接收消息。
由于HTTP协议是请求-响应模式，请求必须在前，响应必须在后，这就导致了服务器无法「主动」的把消息告诉客户端。
常用方案：
短轮询 short polling
客户端每隔一小段时间就向服务器请求一次，询问有没有新消息
实现短轮询是非常简单的，客户端只需要设置一个计时器不断发送请求即可
这种方案的缺陷是非常明显的：
- 会产生大量无意义的请求
- 会频繁打开关闭连接
- 实时性并不高
长轮询 long polling
长轮询有效的解决了「话痨问题」，让每一次请求和响应都是有意义的
但长轮询仍然存在问题：
- 客户端长时间收不到响应会导致超时，从而主动断开和服务器的连接这种情况是可以处理的，但ajax请求因为超时而结束时，立即重新发送请求到服务器虽然这种做法会让之前的请求变得无意义，但毕竟比短轮询好多了
- 由于客户端可能「过早的」请求了服务器，服务器不得不挂起这个请求直到新消息的出现。这会让服务器长时间的占用资源却没什么实际的事情可做。
WebSocket
- WebSocket也是建立在TCP协议之上的，利用的是TCP全双工通信的能力
- 使用WebSocket，会经历两个阶段：握手阶段、通信阶段
虽然优于轮询方案，但WebSocket仍然是有缺点的：
- 兼容性WebSocket是HTML5新增的内容，因此古董版本的浏览器并不支持
- 维持TCP连接需要耗费资源对于那些消息量少的场景，维持TCP连接确实会造成资源的浪费
当客户端需要和服务器使用WebSocket进行通信时，首先会使用HTTP协议完成一次特殊的请求-响应，这一次请求-响应就是WebSocket握手
在握手阶段，首先由客户端向服务器发送一个请求，请求地址格式如下：
# 使用HTTP
ws://mysite.com/path
# 使用HTTPS
wss://mysite.com/path请求头如下：
Connection: Upgrade /* 升级 */
Upgrade: websocket /* 我们把后续的协议升级为websocket */
Sec-WebSocket-Version: 13 /* websocket协议版本就用13好吗？ */
Sec-WebSocket-Key: YWJzZmFkZmFzZmRhYw== /* 暗号：xxx */服务器如果同意，就应该响应下面的消息
HTTP/1.1 101 Switching Protocols /* 换，马上换协议 */
Connection: Upgrade /* 协议升级了 */
Upgrade: websocket /* 升级到websocket */
Sec-WebSocket-Accept: ZzIzMzQ1Z2V3NDUyMzIzNGVy /* 暗号：xxx */握手完成，后续消息收发不再使用HTTP，任何一方都可以主动发消息给对方
