爱测未来性能-你不得不知道的WebSocket

Dear 丶 2022-06-16 14:43 312阅读 0赞

# 一、WebSocket出现的背景 #

过去，创建需要在客户端和服务之间双向通信（例如，即时消息和游戏应用）的web应用， 需要一个滥用的 HTTP 来轮询服务器进行更新但以不同的 HTTP 调用发生上行通知。

以前网站为了实现即时通讯，所用的技术都是轮询(polling)。轮询是在特定的时间间隔（如每隔1秒），由浏览器对服务器发出HTTP request，然后由服务器返回最新的数据给客服端的浏览器。

这种传统的HTTPrequest 的模式带来很明显的缺点 – 浏览器需要不断的向服务器发出请求，然而HTTP request 的header是非常长的，里面包含的有用数据可能只是一个很小的值，这样会占用很多的带宽。在 WebSocket API，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。

WebSocket协议是基于TCP的一种新的协议。WebSocket最初在HTML5规范中被引用为TCP连接，作为基于TCP的套接字API的占位符。它实现了浏览器与服务器全双工(full-duplex)通信。

#    二、WebSocket的引入 #

互联网发展的早期，网站上只是一些静态展示页面。用户请求(Request)网站页面，网站回复(Response)页面内容给用户浏览器。因为需求简单，所以也没有很复杂的协议过程。

Browser已经支持http协议，为什么还要开发一种新的WebSocket协议呢？我们知道http协议是一种单向的网络协议，在建立连接后，它只允许Browser/UA（UserAgent）向WebServer发出请求资源后，WebServer才能返回相应的数据。而WebServer不能主动的推送数据给Browser/UA，当初这么设计http协议也是有原因的。

假设WebServer能主动的推送数据给Browser/UA，那Browser/UA就太容易受到攻击，一些广告商也会主动的把一些广告信息在不经意间强行的传输给客户端，这不能不说是一个灾难。那么单向的http协议给现在的网站或Web应用程序开发带来了哪些问题呢？

让我们来看一个案例，现在假设我们想开发一个基于Web的应用程序去获取当前Web服务器的实时数据，例如股票的实时行情，火车票的剩余票数等等，这就需要Browser/UA与WebServer端之间反复的进行http通信，Browser不断的发送Get请求，去获取当前的实时数据。

## 1 传统的web通信模式 ##

*  工作模式：客户端请求-服务端响应
 *  适用场景：信息变化不是特别频繁的场合，如网页刷新
 *  不适用场景：在线游戏，实时监控
 *  问题: 占用网络传输带宽：每次请求和应答都带有完整的Http头，这就增加了每次传输的数据量。实时性差：在全双工通信时常采用轮询进行。

##    2 改进版web通信模式 ##

轮询

*   基于polling（轮询）技术：以频繁请求方式来保持客户端和服务端的同步
 *  问题：客户端的频繁的请求，服务端的数据无变化，造成通信低效

![Center][]

长轮询

*  当服务端没有数据更新的时候，连接会保持一段时间周期知道数据或者状态改变或者过期，依次减少无效的客户端和服务端的交互
 *  当服务端数据变更频繁的话，这种机制和定时轮询毫无区别
 *  ![Center 1][]

技术流

*  在客户端页面通过一个隐藏的窗口向服务端发出一个长连接请求。服务端接到这个请求后作出回应并不断更新链接状态以保证客户端和服务端的连接不过期。
 *  浏览器设计兼容和并发处理问题。

![Center 2][]

# 三、Websocket 协议简介 #

## 1 概念与原理 ##

概念：是html5开始提供的一种在单个TCP连接上进行全双工通讯协议。Websocket通信协议与2011年被IETF定为标准RFC6455，Websocket API被W3C定为标准。原理和TCP一样，只需做一个握手动作，就可以形成一条快速通道。

![Center 3][]

WebSocket协议是一种双向通信协议，它建立在TCP之上，同http一样通过TCP来传输数据，但是它和http最大的不同有两点：

*  WebSocket是一种双向通信协议，在建立连接后，WebSocket服务器和Browser/UA都能主动的向对方发送或接收数据，就像Socket一样，不同的是WebSocket是一种建立在Web基础上的一种简单模拟Socket的协议。
 *  WebSocket需要通过握手连接，类似于TCP它也需要客户端和服务器端进行握手连接，连接成功后才能相互通信。

## 2 数据通信 ##

WebSocket的数据在发送时，被组织为依次序的一串数据帧(data frame)，然后进行传送。

传送的帧类型分为两类：数据帧(data frame)和控制帧(Control frame)。数据帧可以携带文本数据或者二进制数据；控制帧包含关闭帧(Closeframe)和Ping/Pong帧。

数据帧

数据帧（例如，非控制帧）由操作码最高位是 0 的操作码标识。当前为数据帧定义的操作码包括 0x1(文本)、0x2（二进制）。操作码 0x3-0x7 保留用于未来尚未定义的非控制帧。数据帧携带应用层和/或扩展层数据。操作码决定了数据的解释：

Text：“负载数据”是编码为 UTF-8 的文本数据。注意，一个特定的文本帧可能包括部分 UTF-8 序列；不管怎么样，整个消息必须包含有效的 UTF-8。

Binary：“负载数据”是随意的二进制数据，其解释仅仅是在应用层。

控制帧

控制帧由操作码确定，其中操作码最重要的位是 1。当前定义的用于控制帧的操作码包括 0x8 （Close）、0x9（Ping）、和 0xA（Pong）。操作码 0xB-0xF 保留用于未来尚未定义的控制帧。控制帧用于传达有关 WebSocket 的状态。控制帧可以插入到分片消息的中间。

控制帧必须有一个 125 字节的负载长度或更少， 必须不被分段。

##    3 设计理念 ##

WebSocket 协议应该以最小帧的原则设计（唯一存在的框架是使协议基于帧而不是基于流且支持区分 Unicode 文本和二进制帧）。期望通过应用层将元数据分层在WebSocket之上，同样地，通过应用层将元数据分层在TCP之上（例如，HTTP）。

从概念上讲，WebSocket 只是 TCP 之上的一层，执行以下操作：

1.  为浏览器添加一个 web 基于来源的安全模型
2.  添加一个寻址和协议命名机制来支持在一个 IP 地址的一个端口的多个主机名的多个服务
3.  在 TCP 之上分一个帧机制层以回到 TCP 基于的 IP 包机制，但没有长度限制
4.  包括一个额外的带内（in-band）关闭阶段握手，其被设计来工作在现存的代理和其他中间件。

除此之外，WebSocket 没有添加任何东西。基本上，它的目的是尽可能接近仅暴露原始 TCP 到脚本，尽可能考虑到 Web 的约束。它也被设计为它的服务器能与HTTP 服务器共享一个端口的这样一种方式，通过持有它的握手是一个有效的HTTPUpgrade 请求。

一个可以在概念上使用其他协议来建立客户端-服务器消息，但 WebSocket 的意图是提供一个相对简单的协议，可以与现有 HTTP 和部署的 HTTP 基础设施（例如代理）同时存在，并尽可能接近 TCP，且对于使用考虑到安全考虑的这样的基础设施同样是安全的，有针对性的补充以简化使用并保持简单的事情简单（如增加的消息语义）。

## 4 握手 ##

在TCP会话期间，有三次握手．即对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。为了提供可靠的传送，TCP在发送新的数据之前，以特定的顺序将数据包的序号，并需要这些包传送给目标机之后的确认消息。TCP总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP，由于TCP需要时刻跟踪．这需要额外开销，使得TCP的格式有些显得复杂。

TCP握手协议释TCP/IP协议巾。TCP协议提供可靠的连接服务．采用三次握手建立一个连接。

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN—SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN(ack=i+j)，同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN—RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包．向服务器发送确认包

ACK(ack=k+1)．此包发送完毕．客户端和服务器进入ESTABI．ISHED状态。

完成三次握手．客户端与服务器开始传送数据

下面是一个简单的建立握手的时序图：

![Center 4][]

这里简单说明一下WebSocket握手的过程。

当Web应用程序调用newWebSocket(url)接口时，Browser就开始了与地址为url的WebServer建立握手连接的过程。

*  Browser与WebSocket服务器通过TCP三次握手建立连接，如果这个建立连接失败，那么后面的过程就不会执行，Web应用程序将收到错误消息通知。
 *  在TCP建立连接成功后，Browser/UA通过http协议传送WebSocket支持的版本号，协议的字版本号，原始地址，主机地址等等一些列字段给服务器端。例如：

GET /chat HTTP/1.1

Host:server.example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key:dGhlIHNhbXBsZSBub25jZQ==

Origin: http://example.com

Sec-WebSocket-Protocol:chat,superchat

Sec-WebSocket-Version:13

*   WebSocket服务器收到Browser/UA发送来的握手请求后，如果数据包数据和格式正确，客户端和服务器端的协议版本号匹配等等，就接受本次握手连接，并给出相应的数据回复，同样回复的数据包也是采用http协议传输。

HTTP/1.1 101Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept:s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Sec-WebSocket-Protocol:chat

*  Browser收到服务器回复的数据包后，如果数据包内容、格式都没有问题的话，就表示本次连接成功，触发onopen消息，此时Web开发者就可以在此时通过send接口想服务器发送数据。否则，握手连接失败，Web应用程序会收到onerror消息，并且能知道连接失败的原因。

# 四、Websocket的优势 #

##    1 websocket和http的联系 ##

WebSocket与http协议一样都是基于TCP的，所以他们都是可靠的协议，Web开发者调用的WebSocket的send函数在browser的实现中最终都是通过TCP的系统接口进行传输的。WebSocket和Http协议一样都属于应用层的协议，那么他们之间有没有什么关系呢？

答案是肯定的，WebSocket在建立握手连接时，数据是通过http协议传输的，这里面用到的只是http协议一些简单的字段。但是在建立连接之后，真正的数据传输阶段是不需要http协议参与的HTTP和WebSocket都是应用层协议，传输层协议是TCP，应用层解决如何包装数据问题，HTTP和WebSocket两者的差距不大。浏览网页时，经过三个过程

1.  浏览器经过三次握手与web服务器建立链接
2.  web服务器返回响应
3.  浏览器通过四次握手主动断开链接

![Center 5][]

## 2 websocket和http的区别 ##

WebSocket 是 HTML5 一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯，它建立在 TCP 之上，同 HTTP 一样通过TCP 来传输数据，但是它和 HTTP 最大不同是：

*  WebSocket 是一种双向通信协议，在建立连接后，WebSocket 服务器和Browser/Client Agent 都能主动的向对方发送或接收数据，就像 Socket 一样。
 *  WebSocket 需要类似 TCP 的客户端和服务器端通过握手连接，连接成功后才能相互通信。

## 3 websocket的优势 ##

现在很多网站为了实现即时通讯，所用的技术都是轮询(polling)。轮询是在特定的的时间间隔（如每1秒），由浏览器对服务器发出HTTP request，然后由服务器返回最新的数据给客户端的浏览器。这种传统的HTTPrequest 的模式带来很明显的缺点 – 浏览器需要不断的向服务器发出请求，然而HTTP request 的header是非常长的，里面包含的有用数据可能只是一个很小的值，这样会占用很多的带宽。

而比较新的技术去做轮询的效果是Comet– 用了AJAX。但这种技术虽然可达到全双工通信，但依然需要发出请求。轮询（polling）和Comet技术。其实后者本质上也是一种轮询，只不过有所改进。在 WebSocket API，浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。在此WebSocket 协议中，为我们实现即时服务带来了两大好处：

*  Header：互相沟通的Header是很小的-大概只有 2 Bytes
 *  Server Push：服务器的推送，服务器不再被动的接收到浏览器的request之后才返回数据，而是在有新数据时就主动推送给浏览器。

相对于传统 HTTP 每次请求-应答都需要客户端与服务端建立连接的模式，WebSocket 是类似 Socket 的 TCP 长连接的通讯模式，一旦 WebSocket 连接建立后，后续数据都以帧序列的形式传输。在客户端断开WebSocket 连接或 Server 端断掉连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。

# 五、WebSocket的实现 #

WebSocket 的实现分为客户端和服务端两部分，客户端（通常为浏览器）发出 WebSocket 连接请求，服务端响应，实现类似 TCP 握手的动作，从而在浏览器客户端和 WebSocket 服务端之间形成一条 HTTP 长连接快速通道。两者之间后续进行直接的数据互相传送，不再需要发起连接和相应。

以下简要描述 WebSocket 服务端 API 及客户端 API。

## 1 WebSocket 服务端 API ##

WebSocket 服务端在各个主流应用服务器厂商中已基本获得符合 JEE JSR356 标准规范 API 的支持，以下列举了部分常见的商用及开源应用服务器对 WebSocketServer 端的支持。

<table> 
 <thead> 
 <tr> 
 <td> 厂商 </td> 
 <td> 应用服务器 </td> 
 <td> 备注 </td> 
 </tr> 
 </thead> 
 <tbody> 
 <tr> 
 <td> IBM </td> 
 <td> WebSphere </td> 
 <td> WebSphere 8.0 以上版本支持，7.X 之前版本结合 MQTT 支持类似的 HTTP 长连接 </td> 
 </tr> 
 <tr> 
 <td> 甲骨文 </td> 
 <td> WebLogic </td> 
 <td> WebLogic 12c 支持，11g 及 10g 版本通过 HTTP Publish 支持类似的 HTTP 长连接 </td> 
 </tr> 
 <tr> 
 <td> 微软 </td> 
 <td> IIS </td> 
 <td> IIS 7.0+支持 </td> 
 </tr> 
 <tr> 
 <td> Apache </td> 
 <td> Tomcat </td> 
 <td> Tomcat 7.0.5＋支持，7.0.2X 及 7.0.3X 通过自定义 API 支持 </td> 
 </tr> 
 <tr> 
 <td> Jetty </td> 
 <td> Jetty 7.0＋支持 </td> 
 </tr> 
 </tbody> 
</table>

## 2 WebSocket 客户端 API ##

对于 WebSocket 客户端，主流的浏览器（包括 PC 和移动终端）现已都支持标准的 HTML5 的 WebSocket API，这意味着客户端的 WebSocket JavaScirpt脚本具备良好的一致性和跨平台特性，以下列举了常见的浏览器厂商对 WebSocket 的支持情况：

<table> 
 <thead> 
 <tr> 
 <td> 浏览器 </td> 
 <td> 支持情况 </td> 
 </tr> 
 </thead> 
 <tbody> 
 <tr> 
 <td> Chrome </td> 
 <td> Chrome version 4+支持 </td> 
 </tr> 
 <tr> 
 <td> Firefox </td> 
 <td> Firefox version 5+支持 </td> 
 </tr> 
 <tr> 
 <td> IE </td> 
 <td> IE version 10+支持 </td> 
 </tr> 
 <tr> 
 <td> Safari </td> 
 <td> IOS 5+支持 </td> 
 </tr> 
 <tr> 
 <td> Android Brower </td> 
 <td> Android 4.5+支持 </td> 
 </tr> 
 </tbody> 
</table>

客户端 WebSocket API 基本上已经在各个主流浏览器厂商中实现了统一，因此使用标准 HTML5 定义的 WebSocket 客户端的 JavaScript API 即可，当然也可以使用业界满足 WebSocket 标准规范的开源框架。

想要了解关于更多性能测试的文章，请关注我们的公众号：

关于我们：

公众号：itest\_forever

![Center 6][]

[CSDN:http://blog.csdn**.**net/itest\_2016][CSDN_http_blog.csdn_._net_itest_2016]

QQ群：274166295（爱测未来2群）、610934609（爱测未来3群）

[Center]: /images/20220616/7aabcf65c2664aaba237c08ab62c5c8b.png
[Center 1]: /images/20220616/359fa55bf0d942be9db19b32eb6d156b.png
[Center 2]: /images/20220616/5492918b280948d59465bb4bc12d29bf.png
[Center 3]: /images/20220616/7543ae120dc84e86b42564d4965e8530.png
[Center 4]: /images/20220616/c60f232836d14828bf1784ce8c044587.png
[Center 5]: /images/20220616/f88fadc951bd4b78a787ebcd14af8f05.png
[Center 6]: /images/20220616/d642e7da9bf14326875b730504ba8b60.png
[CSDN_http_blog.csdn_._net_itest_2016]: http://blog.csdn.net/itest_2016