本文已参与「新人创作礼」活动，一起开启掘金创作之路。
上一篇文章简单总结了一下 WebSocket 是什么，大致了解到它并不是我之前想象的“登录认证”，这里继续总结介绍一下 WebSocket 的特点
WebSocket 特点
WebSocket 是一个真正全双工的通信协议，它和 TCP 一样，客户端、服务器可以随时向对方发送数据，但开头的协议名不再是 “http”，而是 “ws” 和 “wss”，分别表示明文和加密后的 WenSocket 协议。
WebSocket 的默认端口也选择了 80 和 443，因为现在互联网上的防火墙屏蔽了绝大多数的端口，只对 HTTP 的 80、443 端口放行，所以 WebSocket 就可以伪装成 HTTP 协议，比较容易地穿透防火墙，与服务器建立连接。
要注意的一点是，WebSocket 的名字容易让人产生误解，虽然大多数情况下我们会在浏览器里调用 API 来使用 WebSocket，但它不是一个“调用接口的集合”，而是一个通信协议。
WebSocket 握手
和 TCP、TLS 一样，WebSocket 也要有一个握手过程，然后才能正式收发数据。
这里它还是搭上了 HTTP 的“便车”，利用了 HTTP 本身的“协议升级”特性，“伪装”成 HTTP，这样就能绕过浏览器沙盒、网络防火墙等等限制，这也是 WebSocket 与 HTTP 的另一个重要关联点。
WebSocket 的握手是一个标准的 HTTP GET 请求，但要带上两个协议升级的专用头字段：
“Connection: Upgrade”，表示要求协议“升级”；
“Upgrade: websocket”，表示要“升级”成 WebSocket 协议。
另外，为了防止普通的 HTTP 消息被“意外”识别成 WebSocket，握手消息还增加了两个额外的认证用头字段(所谓的“挑战”，Challenge)；
Sec-WebSocket-Key：一个 Base64 编码的 16 字节随机数，作为简单的认证密钥；
Sec-WebSocket-Version：协议的版本号，当前必须是 13。
服务器收到 HTTP 请求报文，看到上面的四个字段，就知道这不是一个普通的 GET 请求，而是 WebSocket 的升级请求，于是就不走普通的 HTTP 处理流程，而是构造一个特殊的“101 Switching Protocols”响应报文，通知客户端，接下来就不用 HTTP 了，全改用 WebSocket 协议通信。(有点像 TLS 的“Change Cipher Spec”)
WebSocket 的握手响应报文也是有特殊格式的，要用字段“Sec-WebSocket-Accept”验证客户端请求报文，同样也是为了防止误连接。
具体的做法是把请求头里“Sec-WebSocket-Key”的值，加上一个专用的 UUID “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，再计算 SHA-1 摘要；
客户端收到响应报文，就可以用同样的算法，比对值是否相等，如果相等，就说明返回的报文确实是刚才握手时连接的服务器，认证成功；
握手完成，后续传输的数据就不再是 HTTP 报文，而是 WebSocket 格式的二进制帧了。
简单总结一下 WebSocket 的特点以及它的“握手”方式
我向你敬礼啊，Salute！
