WebSocket —— 为Web应用带来桌面应用般的灵活性.docxVIP

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