spring-websocket 从入门到使用

最新推荐文章于 2025-06-03 12:11:08 发布

CN-LILU

最新推荐文章于 2025-06-03 12:11:08 发布

阅读量1.2k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： websocket-java 文章标签： websocket html5

本文链接：https://blog.youkuaiyun.com/weixin_41558061/article/details/78933846

本文介绍了WebSocket的基本概念、优点，详细阐述了WebSocket的逻辑，包括握手过程和数据帧传输。接着，文章展示了如何在Spring环境中使用WebSocket，包括添加依赖、实现WebSocketConfigurer接口、创建握手拦截器和WebSocketHandler。最后，提到了WebSocket集成redis和rabbitMQ的后续更新计划。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. websocket是什么

Websocket是html5提出的一个协议规范，websocket约定了一个通信的规范，通过一个握手的机制，客户端（浏览器）和服务器（webserver）之间能建立一个类似tcp的连接，从而方便c－s之间的通信。在websocket出现之前，web交互一般是基于http协议的短连接或者长连接。WebSocket是为解决客户端与服务端实时通信而产生的技术。websocket协议本质上是一个基于tcp的协议，是先通过HTTP/HTTPS协议发起一条特殊的http请求进行握手后创建一个用于交换数据的TCP连接，此后服务端与客户端通过此TCP连接进行实时通信。

2. websocket的优点

web server实现推送技术或者即时通讯，用的都是轮询（polling），在特点的时间间隔（比如1秒钟）由浏览器自动发出请求，将服务器的消息主动的拉回来，在这种情况下，我们需要不断的向服务器发送请求，然而HTTP request 的header是非常长的，里面包含的数据可能只是一个很小的值，这样会占用很多的带宽和服务器资源。

而最比较新的技术去做轮询的效果是Comet – 用了AJAX。但这种技术虽然可达到全双工通信，但依然需要发出请求(reuqest)。

WebSocket API最伟大之处在于服务器和客户端可以在给定的时间范围内的任意时刻，相互推送信息。浏览器和服务器只需要要做一个握手的动作，在建立连接之后，服务器可以主动传送数据给客户端，客户端也可以随时向服务器发送数据。此外，服务器与客户端之间交换的标头信息很小。

从服务器角度来说，websocket有以下好处：

1、节省每次请求的header
http的header一般有几十字节

2、Server Push
服务器可以主动传送数据给客户端

如图：只需要请求一次握手成功过后就升级为tcp协议实现长连接双工通讯
基于http升级过后的tcp协议
反之：http协议轮训
这就是http协议轮训

看到这里相信已经对这轮训和长连接有了一个深刻的认识了吧！

3. websocket逻辑

与http协议不同的请求/响应模式不同，Websocket在建立连接之前有一个Handshake（Opening Handshake）过程，在关闭连接前也有一个Handshake（Closing Handshake）过程，建立连接之后，双方即可双向通信。
在websocket协议发展过程中前前后后就出现了多个版本的握手协议，这里分情况说明一下：

基于flash的握手协议
使用场景是IE的多数版本，因为IE的多数版本不都不支持WebSocket协议，以及FF、CHROME等浏览器的低版本，还没有原生的支持WebSocket。此处，server唯一要做的，就是准备一个WebSocket-Location域给client，没有加密，可靠性很差。
客户端请求：

GET /ls HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: www.qixing318.com
Origin: http://www.cn-lilu168.com

服务器返回：

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://www.cn-lilu168.com
WebSocket-Location: ws://www.cn-lilu168.com/ls

. 基于md5加密方式的握手协议
客户端请求：

GET /demo HTTP/1.1
Host: example.com
Connection: Upgrade
Sec-WebSocket-Key2: 
Upgrade: WebSocket
Sec-WebSocket-Key1: 
Origin: http://www.cn-lilu168.com
[8-byte security key]

服务端返回：

HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://www.cn-lilu168.com
WebSocket-Location: ws://example.com/demo
[16-byte hash response]

其中 Sec-WebSocket-Key1，Sec-WebSocket-Key2 和 [8-byte security key] 这几个头信息是web server用来生成应答信息的来源，依据 draft-hixie-thewebsocketprotocol-76 草案的定义。
web server基于以下的算法来产生正确的应答信息：

逐个字符读取 Sec-WebSocket-Key1 头信息中的值，将数值型字符连接到一起放到一个临时字符串里，同时统计所有空格的数量；
将在第（1）步里生成的数字字符串转换成一个整型数字，然后除以第（1）步里统计出来的空格数量，将得到的浮点数转换成整数型；
将第（2）步里生成的整型值转换为符合网络传输的网络字节数组；
对 Sec-WebSocket-Key2 头信息同样进行第（1）到第（3）步的操作，得到另外一个网络字节数组；
将 [8-byte security key] 和在第（3）、（4）步里生成的网络字节数组合并成一个16字节的数组；
对第（5）步生成的字节数组使用MD5算法生成一个哈希值，这个哈希值就作为安全密钥返回给客户端，以表明服务器端获取了客户端的请求，同意创建websocket连接
基于sha加密方式的握手协议
也是目前见的最多的一种方式，这里的版本号目前是需要13以上的版本。
客户端请求：

GET /ls HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: www.qixing318.com
Sec-WebSocket-Origin: http://www.cn-lilu168.com
Sec-WebSocket-Key: 2SCVXUeP9cTjV+0mWB8J6A==
Sec-WebSocket-Version: 13

服务器返回：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: mLDKNeBNWz6T9SxU+o0Fy/HgeSw=

其中 server就是把客户端上报的key拼上一段GUID（ “258EAFA5-E914-47DA-95CA-C5AB0DC85B11″），拿这个字符串做SHA-1 hash计算，然后再把得到的结果通过base64加密，最后再返回给客户端。

————-Date Froming——
Websocket协议通过序列化的数据帧传输数据。数据封包协议中定义了opcode、payload length、Payload data等字段。其中要求：

客户端向服务器传输的数据帧必须进行掩码处理：服务器若接收到未经过掩码处理的数据帧，则必须主动关闭连接。
服务器向客户端传输的数据帧一定不能进行掩码处理。客户端若接收到经过掩码处理的数据帧，则必须主动关闭连接。
针对上情况，发现错误的一方可向对方发送close帧（状态码是1002，表示协议错误），以关闭连接。
具体数据帧格式如下图所示：

websocket_frame

FIN
标识是否为此消息的最后一个数据包，占 1 bit
RSV1, RSV2, RSV3: 用于扩展协议，一般为0，各占1bit
Opcode
数据包类型（frame type），占4bits
0x0：标识一个中间数据包
0x1：标识一个text类型数据包
0x2：标识一个binary类型数据包
0x3-7：保留
0x8：标识一个断开连接类型数据包
0x9：标识一个ping类型数据包
0xA：表示一个pong类型数据包
0xB-F：保留
MASK：占1bits
用于标识PayloadData是否经过掩码处理。如果是1，Masking-key域的数据即是掩码密钥，用于解码PayloadData。客户端发出的数据帧需要进行掩码处理，所以此位是1。
Payload length
Payload data的长度，占7bits，7+16bits，7+64bits：
如果其值在0-125，则是payload的真实长度。
如果值是126，则后面2个字节形成的16bits无符号整型数的值是payload的真实长度。注意，网络字节序，需要转换。
如果值是127，则后面8个字节形成的64bits无符号整型数的值是payload的真实长度。注意，网络字节序，需要转换。
这里的长度表示遵循一个原则，用最少的字节表示长度（尽量减少不必要的传输）。举例说，payload真实长度是124，在0-125之间，必须用前7位表示；不允许长度1是126或127，然后长度2是124，这样违反原则。

Payload data
应用层数据

server解析client端的数据

接收到客户端数据后的解析规则如下：

1byte
1bit: frame-fin，x0表示该message后续还有frame；x1表示是message的最后一个frame
3bit: 分别是frame-rsv1、frame-rsv2和frame-rsv3，通常都是x0
4bit: frame-opcode，x0表示是延续frame；x1表示文本frame；x2表示二