websocket websocket怎么读 收藏 0

浅浅的聊一下 WebSocket

第一次看到 ws:// 和 wss:// 时候，感觉好高级啊，还有这种协议。

WebSocket是在2008年6月诞生的1。经由IEFT标准化后，2009年chrome 4第一个提供了该标准支持，并默认启用。于2011年由IEFT标准化为RFC 6455。

现在的浏览器均已支持该标准。

思考一下我们经常遇到的一种需求场景，要求在某个网页下，网页的内容可以实时更新。

这种情况下，最大众化的方式就是轮询接口了，即通过定时器，定时请求接口，获取到最新的信息后，将内容更新到页面中，如下：

但是我们知道，这种定时器的延时并不是很精确，而且加上接口的请求时延，实际时间可能不止代码中所预先设定的时间长度，所以这种实时更新是伪实时更新。

除此之外，还有一点可能会经常遇到，即，我们更新信息并总是要更新整个页面上所有可以看到的信息，我们更关注一些经常变化的信息，比如状态，状态的信息可能大小只有几个字节，但是我们轮询接口拿到的信息却是这个页面的所有信息，大小自然不只几个字节，但是除状态以外的信息都可以视作是冗余的。

我们实际只需要一个字段，而且即使后端提供只返回状态的接口，但实际在一个请求中还要计算ip报文头的大小，依旧是很占用带宽的。

轮询这种解决方案目前依旧是非常流行，最新的轮询技术是Comet，这种技术虽然可以实现双向通信，但仍然需要反复发出请求。而且在Comet中普遍采用的HTTP长连接也会消耗服务器资源2。

了解网络的都知道，数据传输分为单工、半双工、全双工三种工作模式。

Websocket是基于TCP的，使用全双工通信模式的协议，他使得客户端和服务端之间的数据交换变得更简单。而且，作为一个工作在全双工模式下的协议，服务端可以在建立连接后随时向客户端推送消息。

由于协议是基于TCP的，所以websocket也是需要建连和关闭连接的，但要注意的是，一般在websocket的握手通常指的是：客户端发送一个http请求到服务端，服务端响应后标志这个链接建立起来。而不是指tcp的三次握手。

另外在RFC 6455 1.1节「Background」中介绍：WebSocket通过HTTP端口的80和443进行工作，并支持HTTP代理和中介。

原文：it is designed to work over HTTP ports 80 and 443 as well as to support HTTP proxies and intermediaries

为了实现和HTTP的兼容性，WebSocket握手使用HTTP的Upgrade头将HTTP协议转换成Websocket协议。

作为一种协议，websocket自然也是有其用于协议控制的头部信息的，但是相对于HTTP请求每次都要带上完整的头部信息，传输数据时，websocket数据包的头部信息就相对较小，从而降低了控制开销。

相对于前文所提到的轮询接口，websocket可以做到服务端直接向客户端传输数据，省去了客户端发起请求的步骤，同时没有间隔时间，只要服务端内容变化，就可以告知客户端，实时性上有了很大的提高。

WebSocket使用十分简单，只需要关注以下API：

1. WebSocket(url[, protocol]) 构造函数

使用 new WebSocket(xxx) 创建对象时，会同时建立与服务器的连接

1. WebSocket.onopen , WebSocket.onclose

分别对应连接成功、失败时的回调，这里可以做一些初始化、销毁的工作

1. WebSocket.onmessage

实际处理数据是用的该函数

在数据处理完成后，需要移除回调函数，不然可能会影响到其他地方的处理

1. WebSocket.send

主动向服务端发送消息，可以通过send和onmessage进行数据互动，如：

1. WebSocket.close

关闭连接

Node服务端的实现，这个就参考相关的库吧，比较复杂。

http协议至今，主要经历了三个版本。

• http1.0 短连接，单工通信
• http/1.0默认的模型是短连接，每个HTTP请求都由他自己独立完成，下图左1，可以看到每一个http请求都对应了一个建立连接关闭连接的阶段，每一个请求都有TCP握手和挥手的阶段。
• 在这个模型下，想要做到实时更新页面数据，只能考虑轮询。

• http1.1 支持长链接，半双工通信
• 1.0之后的版本，1.1会让某个连接保持一定的时间，在这段时间里重复发送一系列请求（下图左2），就是保活。

• http2.0 支持多路复用，全双工通信

来源：https://www.cnblogs.com/keepsmart/p/16007094.html

一文让你彻底搞懂 WebSocket 的原理

上一篇文章《浅析一次HTTP请求》我们分析了简单的一次 HTTP 请求具体是怎么样完成的，分析了 HTTP 协议的数据结构，如何连接，如何断开，又是如何多路复用的，那么今天我们来聊聊另外一个协议，WebSocket。由于 WebSocket 的协议的内容非常多，本文只会取其冰山一角进行简单阐述，不会铺开详细说。

在 WebSocket 协议出现以前，创建一个和服务端进双通道通信的 web 应用，需要依赖HTTP协议，进行不停的轮询，这会导致一些问题：

• 服务端被迫维持来自每个客户端的大量不同的连接

• 大量的轮询请求会造成高开销，比如会带上多余的header，造成了无用的数据传输。

所以，为了解决这些问题，WebSocket 协议应运而生。

WebSocket 是一种在单个TCP连接上进行全双工通信的协议。WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。

在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。（维基百科）

下图是我参考 RFC6455 5.2章节画的websocket 基础帧的数据结构图，接下里我们重点解析下数据结构图。

• FIN:占用1 bit，表示这是消息的最后一个片段。第一个片段也有可能是最后一个片段。

• RSV1，RSV2，RSV3: 每个1 bit

必须设置为0，除非扩展了非0值含义的扩展。如果收到了一个非0值但是没有扩展任何非0值的含义，接收终端必须断开WebSocket连接。

Opcode: 4 bit,操作码，如果收到一个未知的操作码，接收终端必须断开WebSocket连接。

• %x0 表示一个持续帧

• %x1 表示一个文本帧

• %x2 表示一个二进制帧

• %x3-7 预留给以后的非控制帧

• %x8 表示一个连接关闭包

• %x9 表示一个ping包

• %xA 表示一个pong包

• %xB-F 预留给以后的控制帧

Mask: 1 bit，mask标志位，定义“有效负载数据”是否添加掩码。如果设置为1，那么掩码的键值存在于Masking-Key中。

Payload length: 7 bits, 7+16 bits, or 7+64 bits，以字节为单位的“有效负载数据”长度。

Masking-Key: 0 or 4 bytes，所有从客户端发往服务端的数据帧都已经与一个包含在这一帧中的32 bit的掩码进行过了运算。如果mask标志位（1 bit）为1，那么这个字段存在，如果标志位为0，那么这个字段不存在。

备注：载荷数据的长度，不包括mask key的长度。。

Payload data：有效负载数据

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

我写了一个DMEMO用来抓包分析 websocket,源代码会放在文章末尾的链接。DEMO效果如下：

页面提供连接与断开功能，输入自己的名字发送，服务端返回Hello,名字！功能很简单，我们先看看页面的请求和响应。

请求：

响应：

这里的请求与响应就是反应了 WebSocket 的一次握手，我们根据上图可以简单抽象一下 WebSocket 的请求和响应格式：客户端握手请求格式：

服务端握手响应：

我们重点说明下结果请求字段：

• Upgrade：

  表示HTTP协议升级为webSocket

• connection:Upgrade 请求升级。

• Sec-WebSocket-Key：

  用于服务端进行标识认证，生成全局唯一id,GUID。

• Sec-WebSocket-Version：

  版本

• Sec-WebSocket-Protocol: 请求服务端使用指定的子协议。

  如果指定了这个字段，服务器需要包含相同的字段，并且从子协议的之中选择一个值作为建立连接的响应。

• Sec-WebSocket-Extensions: WebSocket的扩展。

• Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 生成的全局唯一id，GUID。

我在DEMO中的操作流程如下：

• 连接WebSocket

• 发送“LUOZHOU”

• 断开连接

用 Wireshark 抓包如下：

我们结合浏览器截图和抓包截图，发现在真正开启 websocket 之前，浏览器会有两次http请求，分别是：

根据 RFC6455 协议规定 WebSocket 只需要一次握手就可以完成，所以我们只需要分析第二次的http 握手请求，A请求应该是使用的框架层面自己实现。

我们根据截图可以知道，B请求对应的响应是序号 192 的数据，返回码是101，根据 HTTP 返回码我们可以知道，服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在 Upgrade 消息头中定义的那些协议，也就是升级为 WebSocket 协议。所以接着193的包已经变成了 WebSocket 协议了。到这里，WebSocket 的握手连接就已经完成了。

接下来我们分析下发送消息的流程，这里大家肯定会疑惑，就发送了一条消息，为啥会有这么多 WebSocket 的包呢？其实这里多余的包是框架层面进行发送的，比如要进行订阅与发布的注册等等操作。所以真正使我们操作的包就只有断开连接的相关包和发送“LUOZHOU”的包

根据上图我们发现 序号229的包是一个文本类型的包，,然后采用了掩码处理，同时是最后一个处理包。我们仔细发现所有客户端发送服务端的包都会有[MASKED]标记，服务端返回的没有，这就说明了从客户端向服务端发送数据时，需要对数据进行掩码操作；从服务端向客户端发送数据时，不需要对数据进行掩码操作。

• WebSocket 是为了在 web 应用上进行双通道通信而产生的协议，相比于轮询HTTP请求的方式，WebSocket 有节省服务器资源，效率高等优点。

• WebSocket 中的掩码是为了防止早期版本中存在中间缓存污染攻击等问题而设置的，客户端向服务端发送数据需要掩码，服务端向客户端发送数据不需要掩码。

• WebSocket 中 Sec-WebSocket-Key 的生成算法是拼接服务端和客户端生成的字符串，进行SHA1哈希算法，再用base64编码。

• WebSocket 协议握手是依靠 HTTP 协议的，依靠于 HTTP 响应101进行协议升级转换。

作者：木木匠

链接：https://juejin.im/post/5c693a4f51882561fb1db0ff

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com