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的常用场景外，我们可以通过该组件实现Android/ target=_blank class=infotextkey>安卓和IOS的消息推送。

优点：性能良好，支持广播、组播，断线重连、心跳检测、二进制。支持安卓和IOS平台。社区活跃。

缺点：需要自行封装同Spring的集成，服务端并非社区维护，资源消耗大。

2.4 ReactiveStream

一些反应流规范和框架也对Websocket进行了实现。Spring Webflux和RSocket就是其中的代表，目前官方已经放出了一些相关的DEMO。

优点：高吞吐量、高性能。

缺点：技术比较新、学习资料少。

3. 总结

如果业务量非常少而且非常急迫的话第一种可以尝试一下。SockJS和Socket.IO的争论点在于性能上后者要好一些，当然资源也消耗大，对移动端的推送功能支持更好一些。在Spring整合上以及全套解决方案上SockJS更具优势。如果追求高性能、高吞吐量的Websocket那么无疑反应式更加合适，但是学习成本也相对较高。其它小众的技术这里不做评测，如果你有比较好的方案可留言讨论。

附：性能基准测试

以下是国外某论文在2020年对原生Websocket、SockJS、Socket.IO进行的性能测试的一些关键指标。

随着客户端的增多创建连接的耗时

随着客户端连接增多接收消息的平均时间

接收一条消息所消耗的连接数和重组的TCP分段数

服务端内存占用趋势