基于HTML5 WebSocket,JavaEE 7在线聊天系统

一个基于WebSocket和LayIM的即时通讯系统，后台使用了Gradle集成了Spring Boot、Scala、Mybatis、DevTools SpringBoot热部署方案以及Redis等。项目地址：https://github.com/scalad/LayIM，我们先来张图感受下：

当今的Web应用在我们的个人生活与商业应用中的各个方面已经表现出愈发重要的作用。这些应用包括社交媒体网络、在线购物、商业应用，乃至家用电器的配置程序。虽然它的增长势头依然迅猛，但Web应用的用户体验与原生应用或桌面应用相比仍然相形见绌，其主要原因是Web应用的设计依赖于单向的HTTP协议。而WebSocket将改变这一现状，它为浏览器与服务端的交互带来了一种新的基础元素，为创建一种能够提供真正的交互性体验的Web应用提供了必要的基础。早期的Web技术都是基于HTTP协议而发展起来的，而HTTP只是一个简单的基于请求 —— 响应操作的协议，所有的请求都是由客户端发起的。这套框架原本足以满足用户的需求，但在如今开发者所设计的web应用中，由客户端发起通信这种方式有着很大的制约。虽然人们提出了各种临时方案，但它们都是基于HTTP协议的，只是应用了轮询或长轮询技术（例如Comet）。Comet能够让负责处理请求的线程得到释放，以防止服务器资源耗尽。由于轮询这种机制并不可靠，因此在2007年时，有人提出了一种名为WebSocket的全双工（full-duplex）类型的通信方式。这项提议用了整整4年的时间才成为一个标准。但是，尽管它已成为一种标准，但它的使用率却相当有限。WebSocket是在TCP/IP协议之上创建的一种帧协议，客户端将通过向服务器发送一种特殊的HTTP请求以启动WebSocket。在最初的握手过程之后，客户端与服务器就能够自由地以异步方式互相进行帧的传送了。帧分为两种类型：即控制帧与数据帧。最小的控制帧仅有2比特的大小，而在数据帧方面，客户端的数据帧最小为6比特，服务端的数据帧最小为2比特。数据帧既可以是文本型，也可以是二进制的。文本帧都经过了UTF-8的编码。帧可以实现分块，因此一个大数据集可以分解为多个帧。WebSocket不会为帧附加任何标识信息，因此不同类型的信息对应的帧不可混用。只有控制帧能够在处理一个大消息时的一系列中间帧中出现。在这些基础的帧之上，还可以定义更复杂的协议。比方说，一个帧能够带有校验和或是它的序列号等相关信息。

WebSocket的API
WebSocket并不限定于仅在某个特定的编程语言、系统或是操作系统中使用。多数主流的编程语言以及许多浏览器都已开始支持WebSocket的编程。虽然在不同的平台与编程语言中存在着大量的标准，但本文仅关注JavaScript HTML5以及Java（J2EE）对
WebSocket的支持。在浏览器这方面有两种实现标准，其最新版本分别为Hixie-76和HyBi-17（不久之后发展为IETF RFC 6455）。HyBi的实现相对更高级，并且得到了目前所有主流浏览器的支持。而在服务端方面，基于Java的实现则是目前最为流行的。早些时
候在Java上曾经出现过几种WebSocket的实现，它们之后已发展为JSR 356这种实现。JSR代表Java规范请求，对规范请求的说明有帮于让之后的各种实现保持一致性，并且易于使用。JSR也让开发者不必依赖于某个特定的实现。JSR 356与servlet规范是相互分离的，但它也允许开发者访问某些servlet对象。JSR 356的内容涵盖了WebSocket连接的客户端与服务端，我们稍后的讨论将集中于配合浏览器端的JavaScript所实现的服务端。JSR 356目前属于J2EE 7的一部分，所有流行的开源Java应用服务器都支持它，包括Tomcat、Jetty、Glassfish以及TJWS等等。除此之外，在Java环境中还存在着大约20种各自独立的WebSocket服务端解决方案，其中有些方案也支持JSR 356。由于WebSocket是J2EE 7的一部分，因而在由Oracle与IBM所推出的商业应用服务器上同样也得到支持。

正如我之前所说，WebSocket是一种消息传递协议。它的API提供了各种在通信双方进行消息传递与接收的方法。这里并不存在经典的订阅者与发布者的关系。消息只有两种类型，即文本型与二进制型。不过，在这些类型的消息处理函数中可以对消息进行逻辑上的分离。在Java中能够以某种方式处理被分解为多个块的部分消息，JavaScript尚未支持这种程度的控制能力。如同之前所说，WebSocket是一种非常泛用的协议，它可以在握手时指定所需的逻辑子协议。当不同的系统能够验证所连到的系统支持这种逻辑子协议及扩展时，使用WebSocket进行系统集成就变得容易很多。WebSocket帧格式允许在它的基础上使用可协商的扩展，这与意味着一般来说帧可能会提供更多的信息，并且可能会引入不同的帧类型。WebSocket对于以下类型的应用程序的开发是一种非常自然的选择：

需要玩家之间实时协作的游戏
实时监控系统
需要用户进行协作的系统，例如聊天、共享文档的编辑等等。

其实，WebSocket在传统的Web应用中也能够展现其优势。大多数Web应用都是基于请求 - 响应这一范式进行设计的。虽然AJAX能够实现异步操作，但在继续处理下一步操作之间，仍然必须等待响应返回。而由于WebSocket连接只需建立一次，从而避免了为每次数据交换重建连接的过程，并且在后续的通信中也无需发送多余的HTTP头信息。这种优势在SSL类型的连接上体现得尤为明显，因为最初的连接握手是一个开销很大的操作。浏览器端的WebSocket发送操作是完全异步的，而Java的服务端代码在发送消息后无需进行等待。由于发送消息的这种自由度，在应用中或许需要对某些操作进行手动记录，以保持应用状态的一致性。在使用WebSocket时也能够模拟请求 - 响应这一范式，但如此一来，WebSocket作为一种真正的异步双向消息传递系统的优势也被大大消减了。由于以上所描述的这些特性，因此应当鼓励开发者在某些场景中对应用程序的设计方式进行重新思考。

假设某一个应用程序包含了复杂的用户界面，其中某些区域的功能需要通过服务端的大量计算才能够生成对应的内容。传统的基于AJAX的实现方式可以选择一种延迟调用的机制，通过某个内容请求调用以生成这一区域的内容。而在使用WebSocket的场合下，服务端可以在浏览器做好准备的情况下直接发送内容，而无需对某个AJAX请求进行响应。AJAX请求这一方式的缺陷在于，由于浏览器所发送的请求是串行的，因此服务端的处理过程无法针对请求的顺序进行相应的优化。而WebSocket为服务端提供了一个自行决定最佳的内容生成方式的机会，因而能够提升Web应用的整体响应性。

要用效地利用WebSocket的功能，还需要仔细考虑几个额外的要点。由于在WebSocket中随时可能出现网络连接的丢失，使数据无法正确地传递，因此对于一些至关重要的数据需要进行一些额外的手动记录操作。一般来说，所收到的每条消息都必须提供足够的信息，以指示如何对其进行处理。但没有有效的手段能够了解信息的请求者是谁，是来自客户端的请求，还是说服务端想要更新某些内容。在具体使用WebSocket的过程中，可能需要对Web应用的设计进行更深入的重新思考。此外，JavaScript代码的功能可以迁移至服务端，打个比方，用户的输入可以立即发送给服务端进行处理，通过这种方式能够实现一些复杂的数据校验操作，而这些校验功能或许是JavaScript所无法处理的。用户的输入还能够即时地保存在后台系统中，因此浏览器就无需将最终的数据传递给服务器进行额外的数据校验，因为数据在保存在后台期间已经经过了校验。如果要使某个应用从富Web客户端转为一种轻量级的客户端，就可以考虑以这种方式增加服务端代码的职责。

使用WebSocket时所需注意的要点
在Web应用开发时使用WebSocket也会面对一些特别的挑战，WebSocket的Session与HTTP的Session之间并无任何关联，虽然也可将其用作类似的目标。在Session中可以附加某些通用的数据，因此所有的消息处理过程都可以依赖于Session中所维护的某些状态和数据。WebSocket的Session也可以根据空闲（不活跃）时间间隔的配置产生超时情况，正如HTTP Session一样。不过有些系统会自动地持续发送Ping这一控制消息，以防止出现超时。JSR 356建议将HTTP Session与WebSocket Session的超时进行同步。一旦HTTP Session超时，在其范围内所创建的所有WebSocket连接也都必须关闭。但有些Web应用的设计不会产生任何HTTP Session，而有些应用的Session超时不依赖于HTTP Session，而是由JavaScript所管理的，因此这种机制并不能够进行可靠的推广。另一种需要注意的要点在于，某些浏览器会维护一个连接池，以重用连接的方式访问相同的网站，因此这种流程可以被串行化。而如果浏览器为WebSocket连接也创建一个连接池，那么它会受到严重的制约。因为如果没有某种机制保持WebSocket连接的关闭，这个连接就永远处于活跃状态，而其它任何创建新连接的尝试都会产生死锁。因此，最佳实践的推荐做法是只使用一个WebSocket连接。浏览器无法对通过WebSocket进行传递的数据进行缓存，因此通过WebSocket传递可以在浏览器中缓存的资源。

参考来自：http://www.infoq.com/cn/articles/websocket-desktop-agility-web-applications/

基于HTML5 WebSocket,JavaEE 7在线聊天系统相关推荐

ofd转成html,基于HTML5的OFD文件在线显示的方法以及装置与流程
技术特征: 1.一种基于HTML5的OFD文件在线显示的方法,其特征在于:包括如下步骤: 步骤1.服务器端将OFD文件压缩包进行解压,并将解压后得到的OFD文档目录结构映射至HTML5客户端的URL: ...
打通B/S与C/S ！让HTML5 WebSocket与.NET Socket公用同一个服务端！
随着HTML5 WebSocket技术的日益成熟与普及,我们能够借助WebSocket来更加方便地打通BS与CS -- 由于B/S中的WebSocket能够直接连接到C/S的服务端,并进行双向通信.例 ...
html5 websocket与c,打通B/S与C/S ！让HTML5 WebSocket与.NET Socket公用同一个服务端！
随着HTML5 WebSocket技术的日益成熟与普及,我们可以借助WebSocket来更加方便地打通BS与CS -- 因为B/S中的WebSocket可以直接连接到C/S的服务端,并进行双向通信.如 ...
html在线表单生成,一种基于html5的在线表单设计系统的制作方法
一种基于html5的在线表单设计系统的制作方法 [技术领域] [0001]本发明涉及计算机技术领域,尤其涉及一种基于HTML5的在线表单设计系统. [背景技术] [0002]现有很多表单设计工具大多数 ...
html5 websocket 游戏,基于Websocket的H5在线游戏对战平台
基于Websocket的H5在线游戏对战平台摘要随着计算机的普及与互联网技术的发展,人们的生活方式发生了巨大的变化.基于B/S(Browser/Server)结构的系统不需要用户安装客户端软件,它 ...
基于SSM实现在线聊天系统
基于SSM实现在线聊天系统本聊天系统基于SSM的实现在线聊天功能,通过WEBSOCKET实现消息发送,可以实现在线实时聊天互动,并统计时时在线人数.聊天时可以发送文字.图片.表情等操作,并可以进行清 ...
java在线聊天项目ppt_基于JavaEE的在线聊天聊天.ppt
基于JavaEE的在线聊天聊天.ppt 聊城大学论文答辩,指导教师,学生姓名,年月,基于JavaEE的在线聊天聊天系统的设计与实现,论文提纲,,选题背景.研究内容,1,JavaEE技术介绍,主要创 ...
独立开发的基于springboot + websocket IM网站聊天系统总结
聊天交友趣平台--介绍文章目录聊天交友趣平台--介绍一.应用技术二.系统简介及功能三.设计思路四.过程回顾和收获总结该项目前后端是作者独立设计 .开发完成的,以锻炼自己的设计思维以 ...
基于 SpringBoot+WebSocket 无DB实现在线聊天室（附源码）
文章目录基于 SpringBoot+WebSocket 无DB实现在线聊天室 0 项目说明 0.1 样例展示 0.2 源码地址 1 WebSocket 简介 1.1 HTTP 1.2 WebSock ...

基于HTML5 WebSocket,JavaEE 7在线聊天系统

基于HTML5 WebSocket,JavaEE 7在线聊天系统相关推荐

最新文章

热门文章