js websocket 可以连接java niosocket吗

一、js websocket 可以连接java niosocket吗

1、JavaScript WebSocket确实可以连接到Java NioSocket。WebSocket协议是一种在单个TCP连接上进行全双工通信的协议，它允许服务器主动向客户端推送数据。Java NioSocket则利用Java NIO（New IO）特性，提供高效、非阻塞的网络通信能力。

2、在实际应用中，WebSocket客户端可以是任何支持WebSocket协议的JavaScript代码。而服务器端则可以是使用Java编写的WebSocket服务器，这类服务器可以通过Java NioSocket实现高效的数据处理。使用NioSocket作为底层通信机制，可以显著提高服务器的并发处理能力和响应速度。

3、要实现JavaScript WebSocket连接Java NioSocket，客户端需要创建一个WebSocket连接到服务器的特定端点。例如，可以通过以下JavaScript代码创建连接：

4、const socket= new WebSocket('ws://example.com:8080/nioSocket');

5、socket.onopen= function(event){

6、console.log('WebSocket连接已打开');

7、socket.onmessage= function(event){

8、console.log('收到消息:', event.data);

9、socket.onclose= function(event){

10、console.log('WebSocket连接已关闭');

11、socket.onerror= function(error){

12、console.error('WebSocket错误:', error);

13、服务器端则需要使用Java NioSocket实现WebSocket服务。这通常涉及到设置NioSocket处理器，处理WebSocket握手过程，以及处理WebSocket消息的接收和发送。使用NioSocket可以实现高性能的WebSocket服务器，适用于处理大量并发连接。

14、总之，JavaScript WebSocket与Java NioSocket的结合可以实现高效、可靠的双向通信，适用于许多场景，如实时数据传输、在线游戏、聊天应用等。

二、WebSocket的简单实现

WebSocket协议是基于TCP的一种新的网络协议。浏览器通信通常是基于HTTP协议，为什么还需要另一个协议？因为http只能由客户端发起，不能由服务端发起。

而WebSocket浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

WebSocket协议本质上是一个基于 TCP的协议。为了建立一个 WebSocket连接，客户端浏览器首先要向服务器发起一个 HTTP请求，这个请求和通常的 HTTP请求不同，包含了一些附加头信息，附加信息如图所示

连接过程（以js（客户端）和java（服务器端）为例）

js：ws.send（ String msg） ps：入参可以是字符串或者json字符串java：onMessage(String message）message为客户端传来的信息

java：sendUser（ String msg） js：ws.onmessage

4.断开连接 onclose（ CloseReason reason）

CloseReason.CloseCode( WebSocket关闭连接的状态码，类似http的404)

ps： session用来唯一标识连接对象

javax websocket：（服务端实现api文档）

js websocket：（客户端api文档）

rfc6455（websocket协议规范）： **产品介绍**

三、前端通讯协议:WebSocket和长轮询对比分析详解

1、长轮询概述

1995年，网景通信聘请BrendanEich在网景Navigator中实现脚本编写能力，在十天的时间里，JavaScript语言诞生了。与现代JavaScript相比，它作为一种语言的能力最初非常有限，它与浏览器的文档对象模型（DOM）交互的能力很有限。JavaScript主要用于提供有限的增强以丰富文档使用功能。例如，浏览器内表单验证和在现有文档中轻量插入动态HTML。

2、1995年，网景通信聘请BrendanEich在网景Navigator中实现脚本编写能力，在十天的时间里，JavaScript语言诞生了。与现代JavaScript相比，它作为一种语言的能力最初非常有限，它与浏览器的文档对象模型（DOM）交互的能力很有限。JavaScript主要用于提供有限的增强以丰富文档使用功能。例如，浏览器内表单验证和在现有文档中轻量插入动态HTML。

3、随着浏览器大战的升温，微软的InternetExplorer达到了第4版甚至更高版本，对最强大特性集的争夺导致微软引入了最终成为XMLHttpRequest的东西。十多年来，所有浏览器都普遍支持这一功能。

4、长轮询实际上是原始轮询技术的一种更有效的形式，向服务器发出重复请求会浪费资源，因为必须建立每个新的传入连接，必须解析HTTP头，必须执行对新数据的查询，并且必须生成和交付响应（通常不提供新数据）。然后必须关闭连接并清除所有资源，而不必为每个客户端多次重复这个过程直到新数据对于一个给定的客户端可用。长轮询是一种技术，其中服务器选择尽可能长时间地保持客户端的连接打开，仅在数据变为可用后才传递响应可用或达到超时阈值。

5、长轮询是在XMLHttpRequest的后面实现的，XMLHttpRequest几乎得到了设备的普遍支持，因此通常不需要支持进一步的后备层。但是，在必须处理异常的情况下，或者可以查询服务器以获取新数据但不支持长轮询（更不用说其他更现代的技术标准）的情况下，基本轮询有时仍然具有有限的用途，并且可以使用XMLHttpRequest或通过简单的HTML脚本标签通过JSONP。

6、长轮询在服务器上要密集得多。可靠的消息排序可能是长轮询的一个问题，因为来自同一客户端的多个HTTP请求可能同时进行。例如，如果客户端打开两个浏览器选项卡使用相同的服务器资源，并且客户端应用程序将数据持久化到本地存储（如localStorage或IndexedDb），则没有内置保证不会重复数据写了不止一次。

7、根据服务器的实现，一个客户端实例对消息接收的确认也可能导致另一个客户端实例根本没有收到预期的消息，因为服务器可能错误地认为客户端已经收到了它预期的数据。

8、大多数库都不会独立于其他传输来实现长轮询，因为一般来说，长轮询通常伴随着其他传输策略，作为后备或当长轮询不起作用时将这些传输作为后备。在2018年及以后，独立的长轮询库尤其不常见，因为面对对更现代的替代方案的广泛支持，这种技术正迅速失去相关性。下面是几种不同语言的长轮询开源库：

9、大约在2008年年中，开发人员MichaelCarter和IanHickson尤其敏锐地感受到了在实现任何真正强大的东西时使用Comet的痛苦和局限性。通过在IRC和W3C邮件列表上的合作，他们制定了一项计划，为网络上的现代实时双向通信引入新标准，因此创造了WebSocket这个名称。

10、这个想法进入了W3CHTML草案标准，不久之后，MichaelCarter写了一篇文章，将Comet社区介绍给WebSockets。2010年，GoogleChrome4是第一个全面支持WebSockets的浏览器，其他浏览器供应商在接下来的几年里也纷纷效仿。2011年，RFC6455（WebSocket协议）发布到IETF网站。

11、简而言之，WebSockets是一个建立在设备TCP/IP堆栈之上的薄传输层。其目的是为Web应用程序开发人员提供本质上尽可能接近原始的TCP通信层，同时添加一些抽象以消除某些可能存在的与Web工作方式有关的摩擦。它们还迎合了这样一个事实，即网络具有额外的安全考虑因素，必须考虑这些因素以保护消费者和服务提供商。

12、WebSocket是一种事件驱动的协议，这意味着可以将其用于真正的实时通信。与HTTP不同（必须不断地请求更新），而使用WebSockets，更新在可用时就会立即发送。

13、WebSockets保持单个持久连接打开，同时消除基于HTTP请求/响应的方法出现的延迟问题。

14、WebSockets通常不使用XMLHttpRequest，因此，每次需要从服务器获取更多信息时，都不会发送标头。这反过来又减少了发送到服务器的数据负载。

15、当连接终止时，WebSockets不会自动恢复，这是应用开发中需要自己实现的机制，也是存在许多客户端开源库的原因之一。

16、早于2011年的浏览器无法支持WebSocket连接，这个现在可以忽略不计。

17、在之前的文章中有很详细的介绍，如有兴趣可以参阅《深入学习WebSockets概念和实践》。

18、通常，WebSockets将是更好的选择。

19、长轮询在服务器上占用的资源要多得多，而WebSockets在服务器上的占用空间非常小。长轮询还需要在服务器和设备之间进行多次跳跃。并且这些网关通常对允许典型连接保持打开状态的时间有不同的看法。如果它保持打开时间太长，某些东西可能会杀死它，甚至在它正在做一些重要的事情时也是如此。

20、为什么你应该使用WebSockets构建：

21、全双工异步消息传递，换句话说，客户端和服务器都可以独立地相互传输消息。

22、WebSockets无需任何重新配置即可通过大多数防火墙。

23、良好的安全模型（基于来源的安全模型）。