1. 前言
Websocket是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据，当然也支持客户端发送数据到服务端。通常用来社交聊天、弹幕、多玩家游戏、协同编辑、股票基金实时报价、资讯自动更新等场景，那么今天就简单聊一下在 Java 开发中对Websocket的技术选型。
技术选型是结合自身业务选择最适合的技术方案，并不存在褒贬。
2. 常用的 Websocket 技术
2.1 Java Websocket 规范
这是JavaEE提供的规范，在包javax.websocket下，包含客户端 API 和服务端 API，服务端 API 完全依赖于客户端 API，只是在其基础上添加了一些功能，所以只需要导入服务端依赖即可。 具体实现需要 Web 容器、JavaEE 服务器或者框架提供。我们常用的 Web 容器Tomcat、Undertow等都支持。
优点：集成起来简单，原生的Java支持。
缺点：和 Web 服务器等共享容器耦合度高，广播、组播需要自行控制。并发量较低，调优麻烦，存在兼容性问题。
2.2 SockJS
SockJS是一个浏览器JavaScript库，对Websocket进行了抽象。SockJS为您提供了一个一致的，跨浏览器的Javascript API，该 API 在浏览器和 Web 服务器之间创建了低延迟，全双工，跨域的通信通道。SockJS尝试首先使用本机WebSockets。如果失败了，它将尝试其它各种特定于浏览器的传输协议,例如xhr-streaming、Server sent events 以及长轮询等。通常也会配合STOMP(面向消息的简单文本协议)来简化其使用。其实Spring 的Websocket组件中采用的就是此协议。
优点：社区活跃，技术成熟，协议栈丰富，有全套 Spring 解决方案，兼容性强，另外可以结合发布订阅模式。
缺点：需要对 SockJS 和 STOMP 进行学习，断线重连、心跳检测、二进制支持不好。
2.3 Socket.IO
Socket.IO 是一个基于 Node.js 的实时应用程序框架，在即时通讯、通知与消息推送，实时分析等场景中有较为广泛的应用，但是它提供基于Netty的服务端实现以及客户端实现，同时支持Websocket和长轮询。除了Websocket的常用场景外，我们可以通过该组件实现安卓和IOS的消息推送。
优点：性能良好，支持广播、组播，断线重连、心跳检测、二进制。支持安卓和 IOS 平台。社区活跃。
缺点：需要自行封装同 Spring 的集成，服务端并非社区维护，资源消耗大。
2.4 ReactiveStream
一些反应流规范和框架也对Websocket进行了实现。Spring Webflux和RSocket就是其中的代表，目前官方已经放出了一些相关的 DEMO。
优点：高吞吐量、高性能。
缺点：技术比较新、学习资料少。
3. 总结
这里无法给出也不可能哪种更好的结论。如果业务量非常少而且非常急迫的话第一种可以尝试一下。SockJS和Socket.IO的争论点在于性能上后者要好一些，当然资源也消耗大，对移动端的推送功能支持更好一些。在Spring整合上以及全套解决方案上SockJS更具优势。如果追求高性能、高吞吐量的Websocket那么无疑反应式更加合适，但是学习成本也相对较高。其它小众的技术这里不做评测，如果你有比较好的方案可留言讨论。
附：性能基准测试
以下是国外某论文在 2020 年对原生Websocket、SockJS、Socket.IO进行的性能测试的一些关键指标。
随着客户端的增多创建连接的耗时随着客户端连接增多接收消息的平均时间接收一条消息所消耗的连接数和重组的TCP分段数服务端内存占用趋势
Dunizb 本文转载自微信公众号「 码农小胖哥」，可以通过以下二维码关注。转载本文请联系 码农小胖哥公众号。
