WebSocket入门及使用指南_new websocket

为何使用websocket

在浏览器与服务器通信间，传统的 HTTP 请求在某些场景下并不理想，比如实时聊天、实时性的小游戏等等，

其面临主要两个缺点：

• 无法做到消息的「实时性」；
• 服务端无法主动推送信息；

其基于 HTTP 的主要解决方案有：

• 基于 ajax 的轮询：客户端定时或者动态相隔短时间内不断向服务端请求接口，询问服务端是否有新信息；其缺点也很明显：多余的空请求（浪费资源）、数据获取有延时；
• Long Poll：其采用的是阻塞性的方案，客户端向服务端发起 ajax 请求，服务端挂起该请求不返回数据直到有新的数据，客户端接收到数据之后再次执行 Long Poll；该方案中每个请求都挂起了服务器资源，在大量连接的场景下是不可接受的；

可以看到，基于 HTTP 协议的方案都包含一个本质缺陷 —— 「被动性」，服务端无法下推消息，仅能由客户端发起请求不断询问是否有新的消息，同时对于客户端与服务端都存在性能消耗。

WebSocket 是 HTML5 开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。 WebSocket 通信协议于2011年被IETF定为标准RFC 6455，WebSocketAPI 被 W3C 定为标准。 在 WebSocket API 中，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。

WebSocket 是 HTML5 中提出的新的网络协议标准，其包含几个特点：

• 建立于 TCP 协议之上的应用层；
• 一旦建立连接（直到断开或者出错），服务端与客户端握手后则一直保持连接状态，是持久化连接；
• 服务端可通过实时通道主动下发消息；
• 数据接收的「实时性（相对）」与「时序性」；
• 较少的控制开销。连接创建后，ws客户端、服务端进行数据交换时，协议控制的数据包头部较小。在不包含头部的情况下，服务端到客户端的包头只有2~10字节（取决于数据包长度），客户端到服务端的的话，需要加上额外的4字节的掩码。而HTTP协议每次通信都需要携带完整的头部。
• 支持扩展。ws协议定义了扩展，用户可以扩展协议，或者实现自定义的子协议。（比如支持自定义压缩算法等）

---

实践

在浏览器中使用 Websocket 非常简单，在支持 Websocket 的浏览器中会提供了原生的 WebSocekt 对象，其中对于消息的接收与数据帧处理在浏览器中已经封装好了。
以下将用一个简单的例子解释如何使用 WebSocekt；
浏览器中提供了原生类 WebSocket ，使用 new 关键字实例化它：

WebSocket WebSocket(String url,optional String | [] protocols);
//let websocket = new WebSocket("ws://echo.websocket.org/");
1
2

接收两个参数：

• url 表示需要连接的地址，比如：ws://localhost:8080；

• protocols 可选参数，可以是一个字符串或者一个数组，用来表示子协议，这样做可以让一个服务器实现多种 WebSocket 子协议；
  实例化对象提供两个方法：

• send 接收一个 String|ArrayBuffer|Blob 数据，作为数据发送到服务端；

• close 接收一个（可选）的 code（关闭状态号，默认为 1000） 与一个（可选）的字符串（表示断开原因），客户端主动断开连接；
  连接状态：

WebSocket 类提供了一些常量表示连接状态：

• WebSocket.CONNECTING 0 连接还没开启；
• WebSocket.OPEN 1 连接已开启并准备好进行通信；
• WebSocket.CLOSING 3 连接正在关闭的过程中；
• WebSocket.CLOSED 4 连接已经关闭，或者连接无法建立；
• WebSocket 的实例对象中提供了 readyState 属性来判断当前状态；

实例化对象中可以监听到以下事件：

• open 连接打开的回调事件，这时 readyState 变为 OPEN；
• message 收到消息的回调事件，同时回调函数接收到一个 MessageEvent 数据；
• close 连接关闭的回调事件，这时 readyState 变为 CLOSED；
• error 建立与连接过程发生错误的回调事件；

代码实现

<h1>Echo Test</h1>
    <input id="sendTxt" type="text">
    <button id="sendBtn">发送</button>
    <div id="recv"></div>
    <script type="text/javascript">
        var websocket = new WebSocket("ws://echo.websocket.org/");
        // 引入websocket
        websocket.onopen = function(){
            console.log('websocket open');
            document.getElementById("recv").innerHTML = "Connected";
        }
        // 结束websocket
        websocket.onclose = function(){
            console.log('websocket close');
        }
        // 接受到信息
        websocket.onmessage = function(e){
            console.log(e.data);
            document.getElementById("recv").innerHTML = e.data;
        }
        // 点击发送webscoket
        document.getElementById("sendBtn").onclick = function(){
            var txt = document.getElementById("sendTxt").value;
            websocket.send(txt);
        }
    </script>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

首先触发 open 事件，之后每次发送数据服务端都会回复数据，因此触发了 message 事件，如果触发 close 事件；这里最后一次发送之后未收到服务端回复也是因为客户端立即断开了连接；websocket.send()是发送信息方法

 

---

事件与数据

对 WebSocket 实例监听事件有两种方式，这里以 message 事件为例：

• 对 onmessage 属性直接赋值，正如以上：ws.onmessage = function () {};
• 使用 addEventListener 监听事件，如：ws.addEventListener('message', function () {})；

在 message 回调函数中得到 MessageEvent 类型参数 e ，我们需要的数据可以通过 e.data 获取；

需要注意的一点是：不论服务端与客户端，其接受到的数据都是序列化后的字符串（当然也有 ArrayBuffer|Blob 类型数据），很多时候我们需要解析处理数据，比如 JSON.parse(e.data)；

连接稳定性

由于网络环境复杂，某些情况会出现断开连接或者连接出错，需要我们在 close 或者 error 事件中监听非正常断开并重连；

由于一些原因在 error 时浏览器并不会响应回调事件，因此稳妥的做法还需要在 open 之后开启一个定时任务去判断当前的连接状态 readyState ，在出现异常情况下尝试重连；

心跳

websocket规范定义了心跳机制，一方可以通过发送ping（opcode 0x9）消息给另一方，另一方收到ping后应该尽可能快的返回pong（0xA）。

心跳机制是用于检测连接的对方在线状态，因此如果没有心跳，那么无法判断一方还在连接状态中，一些网络层比如 nginx 或者浏览器层会主动断开连接，

在 JavaScript 中，WebSocket 并没有开放 ping/pong 的 API ，虽然浏览器自带了心跳处理，然而不同厂商的实现也不尽相同，因此需要在我们开发时候与服务端约定好一个自实现的心跳机制；

比如浏览器中，检测到 open 事件后，启动一个定时任务，每次发送数据 0x9 给服务端，而服务端返回 0xA 作为响应；

实践下来，心跳的定时任务一般是相隔 15-20 秒发送一次。

 

举例，WebSocket服务端向客户端发送ping，只需要如下代码（采用ws模块）

ws.ping('', false, true);
1

网络协议

前文说到，Websocket 是建立与 TCP 之上，那么其与 HTTP 协议有和关系呢？

Websocket 连接分为建连阶段与连接阶段，在建立连接阶段借助于 HTTP ，而在连接阶段则与 HTTP 无关。

建连阶段

从浏览器的 Network 中，找到 ws 连接，可以看到：

General
Request URL:ws://localhost:8080/
Request Method:GET
Status Code:101 Switching Protocols

Response Headers
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: py9bt3HbjicUUmFWJfI0nhGombo=

Request Headers
GET ws://localhost:8080/ HTTP/1.1
Host: localhost:8080
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost:8080
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7,la;q=0.6,ja;q=0.5
Sec-WebSocket-Key: 2idFk3+96Hs5hh+c9GOQCg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

这是一个标准的 HTTP 请求，相比于我们常见的 HTTP 请求协议，请求头中多了几个字段：

Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: 2idFk3+96Hs5hh+c9GOQCg==
1
2
3
4

重点请求首部意义如下：

• Connection: Upgrade：表示要升级协议
• Upgrade: websocket：表示要升级到websocket协议。
• Sec-WebSocket-Version: 13：表示websocket的版本。如果服务端不支持该版本，需要返回一个Sec-WebSocket-Versionheader，里面包含服务端支持的版本号。
• Sec-WebSocket-Key ：是一个 Base64 encode 的值，由浏览器随机生成的，用于验证服务器连接的正确性；与后面服务端响应首部的Sec-WebSocket-Accept是配套的，提供基本的防护，比如恶意的连接，或者无意的连接。
• Connection 为 Upgrade ，Upgrade 为 websocket ，表示告知 Nginx 与 Apache 等服务器该次连接并非为 HTTP 连接，实质上是一个 websocket ，因此服务器会转发到相应的 websocket 任务处理；
• Sec-WebSocket-Versio 表示为使用的 websocket 服务版本；

 

响应头中：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: py9bt3HbjicUUmFWJfI0nhGombo=
1
2
3
4

可以看到其返回状态码为 101 ，表示切换协议；
Upgrade 与 Connection 用于回复客户端表示已经切换协议成功；
Sec-WebSocket-Accept 字段与 Sec-WebSocket-Key 相对应，用于验证服务的正确性；

连接阶段

当通过 HTTP 建立连接握手后，接下来则是真正的 Websocket 连接了，其基于 TCP 收发数据，Websocket 封装并开放接口。

WSS

在 HTTP 协议中，很多时候为了加密与安全需要使用 HTTPS 请求（HTTP + TCL）；
相应的，在 Websocket 协议中，也是可以使用加密传输的 —— wss ，比如 wss://localhost:8080。

使用的也是与 HTTPS 一样的证书，在这里一般是交由 Nginx 等服务层去做证书处理。

 

Sec-WebSocket-Key/Accept的作用

前面提到了，Sec-WebSocket-Key/Sec-WebSocket-Accept在主要作用在于提供基础的防护，减少恶意连接、意外连接。

作用大致归纳如下：

1. 避免服务端收到非法的websocket连接（比如http客户端不小心请求连接websocket服务，此时服务端可以直接拒绝连接）
2. 确保服务端理解websocket连接。因为ws握手阶段采用的是http协议，因此可能ws连接是被一个http服务器处理并返回的，此时客户端可以通过Sec-WebSocket-Key来确保服务端认识ws协议。（并非百分百保险，比如总是存在那么些无聊的http服务器，光处理Sec-WebSocket-Key，但并没有实现ws协议。。。）
3. 用浏览器里发起ajax请求，设置header时，Sec-WebSocket-Key以及其他相关的header是被禁止的。这样可以避免客户端发送ajax请求时，意外请求协议升级（websocket upgrade）
4. 可以防止反向代理（不理解ws协议）返回错误的数据。比如反向代理前后收到两次ws连接的升级请求，反向代理把第一次请求的返回给cache住，然后第二次请求到来时直接把cache住的请求给返回（无意义的返回）。
5. Sec-WebSocket-Key主要目的并不是确保数据的安全性，因为Sec-WebSocket-Key、Sec-WebSocket-Accept的转换计算公式是公开的，而且非常简单，最主要的作用是预防一些常见的意外情况（非故意的）。

强调：Sec-WebSocket-Key/Sec-WebSocket-Accept 的换算，只能带来基本的保障，但连接是否安全、数据是否安全、客户端/服务端是否合法的 ws客户端、ws服务端，其实并没有实际性的保证。

 

数据掩码的作用

WebSocket协议中，数据掩码的作用是增强协议的安全性。但数据掩码并不是为了保护数据本身，因为算法本身是公开的，运算也不复杂。除了加密通道本身，似乎没有太多有效的保护通信安全的办法。

那么为什么还要引入掩码计算呢，除了增加计算机器的运算量外似乎并没有太多的收益。

答案还是两个字：安全。但并不是为了防止数据泄密，而是为了防止早期版本的协议中存在的代理缓存污染攻击（proxy cache poisoning attacks）等问题。

 

 

 

原文：https://www.cnblogs.com/gitnull/p/10728653.html