本文详解 Java WebSocket 技术，涵盖基础概念、握手升级流程、全双工通信原理及心跳保活机制。对比了 JSR 356 与 Spring WebSocket 两种实现方式，分析了其与 HTTP 在通信模式、连接特性及传输效率上的区别。此外还探讨了离线消息存储与跨服务器通讯的进阶方案，为实时通信场景提供选型建议。
在 Web 开发中，实时通信场景（如在线聊天、直播弹幕、股票行情推送）越来越普遍，而传统 HTTP 通信因'请求 - 响应'的单向限制，难以满足这类场景的需求。WebSocket 作为一种全双工长连接协议，完美解决了这一痛点，成为 Java 后端开发中实现实时通信的核心技术。本文将全面拆解 WebSocket 的基础认知、工作原理、Java 实现方式、与 HTTP 的核心区别，以及离线消息存储、跨服务器拓展等进阶知识点，帮你一文吃透 WebSocket 所有核心内容。
WebSocket 是一种基于 TCP 的应用层全双工长连接通信协议，核心作用是打破传统 HTTP 单向通信的局限，实现客户端与服务端的实时双向交互。
通俗类比：HTTP 是'你问我答'的电话沟通（你不问，我不答），而 WebSocket 是'面对面聊天'的双向对话（双方可随时开口）。
核心优势：
WebSocket 并未脱离 TCP/IP 协议栈，而是在 HTTP 基础上做了'协议升级'，整个工作流程分为 4 个关键阶段，每一步都决定了它的核心特性，全程兼顾兼容性与高效性。
WebSocket 无法直接建立连接，必须先通过 HTTP 完成'握手升级'（兼容现有网络环境），具体流程：
握手成功后，双方进入全双工通信模式，核心依赖 WebSocket 的'帧（Frame）'格式——这是它比 HTTP 高效的核心原因。
WebSocket 帧结构极简，仅包含必要字段：FIN（是否为最后一帧）、Opcode（帧类型：文本/二进制/心跳/关闭）、Masked（客户端帧掩码标识）、Payload Length（数据长度）、Masking-Key（客户端帧掩码）、Payload Data（业务数据）。
核心对比：HTTP 每次传输需携带完整请求头（Host、Cookie 等），头信息往往远大于业务数据；WebSocket 帧头仅 2-10 字节，核心传输业务数据，开销极大降低。
WebSocket 是长连接，但网络不稳定（防火墙、路由器超时）会导致'假死连接'，需通过心跳机制维护：
连接关闭并非直接断开 TCP，而是通过 Close 帧（Opcode=8）优雅关闭：一方发送 Close 帧（携带关闭原因），另一方回复确认，双方确认后再断开 TCP 连接，避免数据丢失。
Java 中实现 WebSocket 主要有两种方式，适配不同项目场景，以下为核心简化代码（完整可直接落地）。
适用于 Tomcat/Jetty 等 Java EE 容器（Tomcat 7+、Jetty 9+ 内置支持），通过注解快速定义端点。
import javax.websocket.*;
import javax.websocket.server.ServerEndpoint;
import java.io.IOException;
// 定义 WebSocket 端点地址：ws://localhost:8080/websocket/demo
@ServerEndpoint("/websocket/demo")
public class MyWebSocketServer {
// 连接建立时触发
@OnOpen
public void onOpen(Session session) {
System.out.println("客户端连接成功，会话 ID：" + session.getId());
}
// 收到客户端消息时触发（双向通信体现）
@OnMessage
public void onMessage(String message, Session session) throws IOException {
System.out.println("收到客户端消息：" + message);
// 服务端主动回复消息
session.getBasicRemote().sendText("服务端已收到：" + message);
}
// 连接关闭时触发
@OnClose
public void onClose(Session session) {
System.out.println("客户端连接关闭，会话 ID：" + session.getId());
}
// 通信异常时触发
@OnError
public void onError(Session session, Throwable error) {
System.err.println("通信异常：" + error.getMessage());
}
}
适用于 Spring Boot 项目，封装 JSR 356，易整合 Spring 生态（如 Spring Security），开发效率更高。
第一步：添加依赖（pom.xml）
<dependencies>
<!-- Spring Boot Web 核心依赖 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- Spring WebSocket 依赖 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-websocket</artifactId>
</dependency>
</dependencies>
第二步：编写配置类
import org.springframework.context.annotation.Configuration;
import org.springframework.web.socket.config.annotation.EnableWebSocket;
import org.springframework.web.socket.config.annotation.WebSocketConfigurer;
import org.springframework.web.socket.config.annotation.WebSocketHandlerRegistry;
@Configuration
@EnableWebSocket // 开启 WebSocket 支持
public class WebSocketConfig implements WebSocketConfigurer {
@Override
public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
// 注册处理器，指定端点地址，允许跨域（生产环境需指定具体域名）
registry.addHandler(new MyWebSocketHandler(), "/ws/demo").setAllowedOrigins("*");
}
}
第三步：编写处理器
import org.springframework.web.socket.TextMessage;
import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.handler.TextWebSocketHandler;
public class MyWebSocketHandler extends TextWebSocketHandler {
// 连接建立时触发
@Override
public void afterConnectionEstablished(WebSocketSession session) throws Exception {
System.out.println("客户端连接成功，会话 ID：" + session.getId());
// 服务端主动推送欢迎消息（实时推送体现）
session.sendMessage(new TextMessage("欢迎连接 Spring WebSocket！"));
}
// 收到客户端文本消息时触发
@Override
protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {
String msg = message.getPayload();
System.out.println("收到客户端消息：" + msg);
// 服务端实时响应
session.sendMessage(new TextMessage("Spring 服务端已收到：" + msg));
}
}
WebSocket 与 HTTP 并非替代关系，而是互补关系，核心区别汇总如下（清晰易懂，快速选型）：
对比维度 | 普通 HTTP 通信 | WebSocket 通信 |
通信模式 | 单向（请求 - 响应），服务端无法主动推送 | 全双工，双方可同时主动收发数据 |
连接特性 | 短连接，请求完成后断开（Keep-Alive 仅复用连接） | 长连接，一次握手后持续保留，主动关闭才断开 |
数据传输开销 | 大，每次携带完整 HTTP 头 | 小，仅 2-10 字节帧头，核心传输业务数据 |
服务端推送 | 不支持，需通过轮询/长轮询模拟（低效） | 原生支持，有数据立即推送，延迟毫秒级 |
协议标识 | http:// / https:// | ws:// / wss://（加密版） |
适用场景 | 低频、非实时请求（网页加载、接口调用） | 高频、实时通信（聊天、弹幕、行情推送） |
结合前面的原理和实现，拆解 WebSocket 四大核心特性的底层逻辑，搞懂'它为什么能做到'：
底层基础：TCP 连接本身就是全双工（类似双向车道），HTTP 的局限是协议层加了'请求 - 响应'单向规则；
WebSocket 突破：握手升级后，抛弃 HTTP 的'请求 - 响应'规则，直接利用 TCP 的双向字节流，双方可随时主动发数据，无需等待对方。
协议层：WebSocket 无'请求完成即断开'规则，只要不主动发 Close 帧，TCP 连接就持续保留；
应用层：通过 Ping/Pong 心跳帧，防止中间网络设备断开'长时间无数据'的连接，确保连接稳定。
帧结构优化：用 2-10 字节极简帧头，替代 HTTP 大体积请求头；
无重复开销：仅握手时携带一次 HTTP 头，后续传输只有帧头 + 业务数据；
额外优化：支持二进制传输（无需 Base64 编码，减少 33% 体积）、数据分片（避免大消息阻塞）。
核心前提：服务器需存储 WebSocket Session（连接会话），用于定位在线客户端，具体存储逻辑：
实现逻辑：服务端产生新数据后，检测目标客户端 Session 是否在线，在线则直接推送；离线则暂存消息，待重连后推送，客户端通过 onmessage 事件实时接收并渲染。
实际开发中，常会遇到'一方不在线''跨服务器通讯'的场景，结合数据库等中间件，汇总落地解决方案：
核心逻辑：离线消息与在线 Session 存储独立，以服务端存储为主，分场景选择存储方式，兼顾内存占用与消息可靠性。
核心痛点：跨服务器 Session 不共享、消息不同步，基于'数据库 + 中间件'实现拓展，分业务规模选择方案：
核心注意事项：确保数据一致性（事务/Redis 原子操作）、避免消息重复推送（唯一标识）、优化性能（减少数据库查询）、增加容错重试机制。
WebSocket 的核心价值，是在现有 TCP/IP 和 HTTP 基础上，通过'协议升级'和'极简设计'，实现高效、实时的双向通信。它没有创造新的通信能力，而是把 TCP 的特性用到极致，同时砍掉 HTTP 的冗余开销，成为实时通信场景的首选。
选型建议（快速匹配业务场景）：
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online