WebSocket原理与应用

最新推荐文章于 2024-05-27 21:07:55 发布

纵横AI大世界

最新推荐文章于 2024-05-27 21:07:55 发布

阅读量814

点赞数

文章标签：网络 java http socket 网络通信

本文链接：https://blog.csdn.net/naisongwen/article/details/117576464

版权

本文首发微信公众号：码上观世界

WebSocket概述

WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工（同时、双向）通讯的协议。WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。WebSocket作为一个协议，与HTTP协议、FTP协议、DNS服务同属于应用层，是TCP/IP协议族下的一个子集。同HTTP协议一样，WebSocket也是基于TCP协议基础上实现的。在创建WebSocket连接过程中，WebSocket协议在第一次握手连接时，通过HTTP协议传送WebSocket支持的版本号，协议的字版本号，原始地址，主机地址等一些列字段给服务端，两者之间就直接可以创建持久性的连接。

其中红框中的请求头是主要差别：

Connection 必须设置 Upgrade，表示客户端希望连接升级。
Upgrade 字段必须设置 websocket，表示希望升级到 Websocket 协议。
Sec-WebSocket-Key 是随机的字符串，服务器端会用这些数据来构造出一个 SHA-1 的信息摘要。把 “Sec-WebSocket-Key” 加上一个特殊字符串 “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，然后计算 SHA-1 摘要，之后进行 BASE-64 编码，将结果做为 “Sec-WebSocket-Accept” 头的值，返回给客户端。如此操作，可以尽量避免普通 HTTP 请求被误认为 Websocket 协议。
Sec-WebSocket-Version 表示支持的 Websocket 版本。RFC6455 要求使用的版本是 13。

在响应内容头中，Connection 和Upgrade 跟请求头一致，响应码101，表示服务端已经接受请求，成功建立Websocket连接。

但WebSocket协议跟HTTP协议是独立的两套协议，有独立的规范和API，更突出的差别是WebSocket是全双工、双向通信的，而HTTP协议是单工、单向通信（同一时间只有一方能接受或发送信息）的。在一次连接会话中，HTTP协议的客户端首先建立通信，然后只能由客户端发起HTTP请求，服务器做出响应，服务器在没有接收到请求之前不会发送响应。而WebSocket的客户端和服务端都可以主动向对方发送数据。正是因为这点的不同，导致在实时数据推送应用场景，WebSocket成为替代HTTP应用的首选技术。

在没有应用WebSocket之前，因为服务器无法及时通知客户端数据已经准备就绪，客户端如何才能知道服务端数据可用呢？自然的想法是定时轮询服务端，主动请求建立HTTP连接获取响应，如果没有数据，就断开连接，下次继续请求。这种方法简单直接，但是缺点很明显：导致大量的无用请求，在服务端并发量或者操作代价较高的情况下就成为不得不面对的问题。作为改进，客户端发起请求，一直等到服务端数据准备就绪或者等待超时才返回。而WebSocket可以做到在客户端不断开连接的情况下，当服务端数据准备就绪，主动推送到客户端。下图展示了基于HTTP的轮询方式与基于WebSocket的方式在实时获取服务端数据的情形：

WebSocket全双工实现原理

WebSocket建立在Socket之上，Socket 是为了方便使用 TCP 或 UDP 而抽象出来的一层，是位于应用层和传输控制层之间的一组接口。Socket本身并不是一个协议，而是一个门面模式，把复杂的TCP/IP协议族隐藏在Socket接口后面。WebSocket则是一个典型的应用层协议。WebSocket和HTTP一样，都是建立在TCP之上，通过TCP来传输数据。为什么WebSocket能够做到全双工？这要归功于其依赖的底层Socket，因为在操作系统内核空间，每个Socket都有独立的读写缓冲区，网卡接收到数据包后，通过CPU中断指令触发系统调用，将网卡接收缓冲区中的数据解包并复制到接收缓冲区，然后再通知应用程序从内核缓冲区读数据。同理，当应用程序将应用空间的数据写入内核发送缓冲区后，网卡通过中断触发内核系统调用，将发送缓冲区的数据经过封包后复制到网卡发送缓冲区，如下图所示：

全双工让Socket的两端可以同时独立读写数据，那为什么在同一个连接中，数据有来有往，为什么不会”碰头“呢？首先需要明确的是连接只是虚拟概念，表示双方能互相感知对方的存在，但是中间链路是不固定的，数据在链路上传递可能会根据链路节点情况动态选择路由。然而在确定的两个节点之间，这种同时收发数据的冲突性还是存在的，比如在基于总线结构的局域网中，多个节点主机共享总线，可以同时发送和接收数据，假设节点A向B发送数据，虽然在A发送之前，通过载波监听检测到总线空闲，但因为数据在总线传播有一定时延，B 若在 A 发送的信息到达 B 之前也发送数据(因为这时 B 的载波监听检测不到 A 所发送的信息)，则必然要在某个时间和 A 发送的数据发生碰撞，碰撞示意图如下：

所以为了提高以太网带宽利用率，通常采用星形结构网络，通过交换机将不同的主机通过独立端口连接在一起，每个主机独享传输媒体，因为以太网交换机的每个接口都直接与主机相连，所以可以进行全双工无碰撞地传输数据。实际上，在交换机到主机的最后“一公里”物理线路上也常用双绞线媒介。

所谓双绞线(Twisted Pair)就是由一对相互绝缘的金属导线绞合而成，采用这种方式，不仅可以抵御一部分来自外界的电磁波干扰，也可以降低多对绞线之间的相互干扰。把两根绝缘的导线互相绞在一起，干扰信号作用在这两根相互绞缠在一起的导线上是一致的（这个干扰信号叫做共模信号），在接收信号的差分电路中可以将共模信号消除，从而提取出有用信号（差模信号）。

双绞线通常由8根不同颜色的线分成4对线绞合在一起，并且按照次序编号1~8引脚：

比如EIA/TIA-568B标准，在实际使用中10M、100M以太网的网线只使用 1、2、3、6编号的芯线传递数据，即1、2用于发送，3、6用于接收，按颜色来说：橙白、橙两条用于发送；绿白、绿两条用于接收；4、5，7、8是双向线。1000M网卡需要使用四对线，即8根芯线全部用于传递数据。由此可知，在物理链路媒介层面决定了全双工通信的可能性。然而，如果采用无线网络，因为收发信号在自由空间的自干扰性导致在商业上实现全双工的代价较高，实际上还是半双工方式。因此可以说此时的Socket是应用层面逻辑上的全双工。

WebSocket通信报文格式

在WebSocket握手过程中，客户端首先发起一个HTTP请求，服务端会有一个HTTP响应。握手过程是HTTP，但是握手完成之后客户端与服务端之间的通信采用的是WebSocket协议。一个WebSocket通信报文格式如图所示：

WebSocket协议的通信报文是二进制格式，大致包含以下字段：

（1）FIN：占用一位。如果其值是1，表示该帧是消息的最后一个数据帧；如果其值是0，表示该帧不是消息的最后一个数据帧。

（2）Opcode：WebSocket帧的操作码，占用4位。操作码的值决定了应该如何解析后续的数据载荷（Data Payload）。如果操作码是不认识的，那么接收端应该断开链接。WebSocket协议的操作码取值说明具体如表所示：

WebSocket控制帧有3种：Close、Ping以及Pong。控制帧的Opcode操作码定义为0x08（关闭帧）、0x09（Ping帧）、0x0A（Pong帧）。Close帧很容易理解：客户端如果接收到关闭帧，就关闭连接；当然，客户端也可以发送关闭帧给服务端，服务端收到该帧之后也会关闭连接。

Ping和Pong是WebSocket的心跳帧，用来保证客户端维持正常在线状态。WebSocket为了保持客户端、服务端的实时双向通信，需要确保客户端、服务端之间的TCP通道保持连接没有断开。然而，如果长时间没有数据往来的连接，依旧保持着双向连接，就可能会浪费服务端的连接资源，所以需要关闭这些长时间空闲的连接。

有一些场景需要保持那些长时间空闲的连接，这时可以采用Ping和Pong两个心跳帧来完成。一般来说，服务端给客户端发送Ping，然后客户端发送Pong来回应，表明自己仍然在线。

（3）Mask：一位（值为1时抓包会显示为true），表示是否要对数据载荷进行掩码操作。客户端向服务端发送数据时，需要对数据执行掩码操作；从服务端向客户端发送数据时，不需要对数据进行掩码操作，如果服务端接收到的数据没有进行掩码操作，那么服务器需要断开连接。所有的客户端发送到服务端的数据帧，Mask值都是1。

（4）Masking-Key：掩码键，如果Mask值为1，就需要用这个掩码键来对数据进行反掩码，以获取到真实的通信数据。为了避免被网络代理服务器误认为是HTTP请求，从而招致代理服务器被恶意脚本攻击，WebSocket客户端必须对所有送给服务器的数据帧执行掩码操作。

客户端必须为发送的每一个数据帧选择新的不同掩码值，并要求这个掩码值是无序、无法预测的。在掩码算法的选择上，为了保证随机性，可以借助密码学中的随机数生成器生成每一个新掩码值。

（5）Payload Length：通信报文中数据载荷的长度。

（6）Payload：通信报文数据帧的有效数据载荷，也就是真正的通信消息内容。

WebSocket应用场景

在网络层及其下层采用全双工能极大提高网络传输效率，然而在应用层，是否采用全双工要看使用场景，比如基于HTTP协议，虽然能够实现全双工，但是这样的话会导致请求和应答的次序难以保证，增加了实施难度。跟网络通话一样，假如通信双方自由对讲，那对话将是无意义的，所以双方自觉采用半双工方式。实际上，基于Socket的应用开发虽然可以做到自由收发，但通常的实现逻辑也是一来一回，见下图中的框中逻辑，形成了3个循环：

回到WebSocket，除了具有全双工的特性，还有哪些优势呢？

支持双向通信，实时性更强。
更好的二进制支持。
较少的数据传输开销。
支持扩展，用户可以扩展协议，或者实现自定义的子协议。

于是Websocket应该适合什么样的场景呢？显然不适合高频的交互等待，这样就回到典型的HTTP应用场景了，最适合无交互等待的场景，双方同时“自由表达”的场景，数据传输效率最高，比如：

即时聊天通信：指的是当有对方消息到达，主动推送过来，而不是间歇性拉取
多玩家游戏：每个玩家的状态信息实时推送给其他玩家
在线协同编辑/编辑：实时推送最新编辑状态
体育/游戏实况：体育/游戏实况的即使推送
实时地图位置：GPS等地理位置实时推送

WebSocket应用开发

基于Springboot开发WebSocket非常简单，基本步骤是：

1. 引入依赖包spring-boot-starter-websocket，比如以下版本：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-websocket</artifactId>
    <version>2.5.0</version>
</dependency>

2. 实现WebSocket处理器接口WebSocketHandler

其中afterConnectionClosed和afterConnectionEstablished是WebSocketHandler提供的连接断开和建立之后的回调方法，连接建立和断开的事件通知有助于实时获取当前连接的实时在线会话数量。handleMessage是消息处理回调方法，当有新消息到达时触发执行。

3. 实现握手拦截器接口HandshakeInterceptor

拦截器接口提供了握手建立连接前后的回调方法，握手前的回调方法可用于设置握手请求头信息，比如从HTTP升级到WebSocket的重要请求头：

4. 配置WebSocket接口WebSocketConfigurer

WebSocketConfigurer提供了一个接口registerWebSocketHandlers，用于注册处理器和拦截器以及设置跨域访问等，比如下面的示例代码注册了一个处理器和一个拦截器，以及设置了允许任何来源站点的请求：

其中，自定义处理器关联到路径/ws上，当连接请求该路径时，通过该处理器和拦截器来处理。注意这里虽然实现了一个拦截器，但是Spring缺自动添加了一个跨域请求处理拦截器OriginHandshakeInterceptor：

#AbstractWebSocketHandlerRegistration
protected HandshakeInterceptor[] getInterceptors() {
   List<HandshakeInterceptor> interceptors = new ArrayList<>(this.interceptors.size() + 1);
   interceptors.addAll(this.interceptors);
   OriginHandshakeInterceptor interceptor = new OriginHandshakeInterceptor(this.allowedOrigins);
   if (!ObjectUtils.isEmpty(this.allowedOriginPatterns)) {
      interceptor.setAllowedOriginPatterns(this.allowedOriginPatterns);
   }
   interceptors.add(interceptor);
   return interceptors.toArray(new HandshakeInterceptor[0]);
}

所以setAllowedOrigins("*");也只能在registerWebSocketHandlers方法中调用，在其他地方比如在拦截器的请求头中设置是无效的。

以上步骤是开发WebSocket应用的最少步骤，到这里能够开启一个Websocket应用服务了。接下来实现一个Websocket客户端，用于接收服务端的实时推送数据。

WebSocket客户端提供了连接打开、关闭、收到消息和异常时候的回调函数，以及发送消息到服务端的函数send，一个实现示例如下：

<script type="text/javascript">
    var websocket;
    // 首先判断是否 支持 WebSocket
    if('WebSocket' in window) {
        websocket = new WebSocket("ws://localhost:8080/ws");
    } else if('MozWebSocket' in window) {
        websocket = new MozWebSocket("ws://localhost:8080/ws");
    } else {
        websocket = new SockJS("ws://localhost:8080/ws");
    }
    // 打开连接时
    websocket.onopen = function(event) {
        console.log("websocket.onopen");
    };
    // 收到消息时
    websocket.onmessage = function(event) {
        console.log("receive msg:"+event.data);
        websocket.send('you can continue')
    };
    websocket.onerror = function(event) {
        console.log("websocket.onerror:"+event);
    };
    websocket.onclose = function(event) {
        console.log("websocket.onclose");
    };
</script>

以上展示了客户端如何跟服务器连接和通讯，服务端也可以随时跟任意客户端推送消息，实现方式为：先记录所有连接的客户端的会话信息，然后调用任意会话的sendMessage方法发送消息。比如一个广播推送消息的示例程序如下：



Map<String, WebSocketSession> userMap = new HashMap<>();
public void sendMsgToAllUsers(String msg) throws IOException {
    Iterator<Map.Entry<String, WebSocketSession>> it = userMap.entrySet().iterator();
    while (it.hasNext()) {
        final Map.Entry<String, WebSocketSession> entry = it.next();
        TextMessage message = new TextMessage(msg);
        entry.getValue().sendMessage(message);
    }
}

纵横AI大世界

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
WebSocket原理与应用

本文首发微信公众号：码上观世界WebSocket概述WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工（同时、双向）通讯的协议。WebSocket 使得客户...
复制链接

扫一扫