前 言
对于Web开发人员迅速发展的工具箱而言，WebSocket协议是一种新的网络协议。它除了作为HTML 5的核心技术外，还被从桌面到平板电脑和智能手机的所有主流浏览器迅速采用，不过为什么Web开发人员还要关心另一种网络技术？
长轮询
在2000年之前，全世界的多数主流公司都使用Web。在发展中国家，个人电脑的革命使得大部分家庭都至少通过一个通道接入互联网。企业迅速地在互联网上建立其Web站点，作为一种展示产品和服务的手段，并且作为交付这些产品和服务的一个日益增长的渠道。Web的基本技术(例如HTTP、HTML和JavaScript)推动了人们如何与其他人、其学校和其工作地点交互，如何规划假期，甚至如何购买生活用品的革命。
Web网站从静态和无趣的目录式风格不断发展，开发人员找到了新方法使得Web网站更加具有交互性。他们指望在合适的时候通过为浏览者注入有趣的信息并在必要时对页面中的信息进行更新来为Web网站添加活力。然而开发人员发现，基本的HTTP及其标记式技术存在着限制。开发人员需要更新股票报价、最新出价、登录到同一网站的当前好友列表、新的处理价以及游戏结果。同时他们也需要在不依赖用户的持续交互的情况下完成这些事情。他们需要从Web服务器端发起数据更新，保持Web网站更新、更迷人、更有趣。他们需要Web网站访问者转变为其渠道的一个观察者，并且他们需要访问者为了获取推送给他们的信息做尽可能少的事情。
在之后的几年中，开发人员通过各种非正规手段来完成更新一个网站最新的各种类型的信息到所有当前访问者的任务。最明显的手段是通过浏览器向服务器轮询更新。开发人员将一小段JavaScript嵌入相关的Web页面中，强迫浏览器以预定的间隔周期刷新整个页面。无论获取的数据是否需要刷新，此方法都将刷新所有的数据。即使除去获取非必需数据之外，此方法的网络延迟也是比较明显的，所以其用户体验比较糟糕。
稍微复杂一些的处理方式是使用HTTP Keep Alive机制。在这种机制中，Web页面中的JavaScript代码将保持打开一个长生命周期的HTTP连接，如同一个持续不断的软件下载，它将定期地使用新信息进行更新。关于浏览器和服务器应保持连接打开多久方面的巨大差异导致了大量问题。一般情况下，客户端的浏览器将需要频繁地重新打开连接，而无论其是否从服务器获取数据。
随着开发人员接触这些技术，开发框架(例如Comet和AJAX)逐步开始支持并包含这些基本技术。在某种程度上，它们可以隐藏这些基本技术的一些不足。然而，有两个基础问题即使是最好的实现也不能克服。首先，HTTP是一个发送简单信息的昂贵的网络协议。仅仅请求简单的股票报价更新，连接上下文在每次请求中都会被重新调用：例如限定客户端和服务器平台的所有头信息、认证属性、负载描述等。其次，更糟糕的是，无论服务器是否有新的信息传送，都需要建立昂贵的连接。
WebSocket的引入
2009年，WebSocket的引入工作始于一项允许客户端与服务器建立一个轻量级的连接，并允许双向通信和一个轻量级的内容模型的技术。服务器能够仅在必要时将数据推送到已连接的客户端。一旦连接建立后，在每次发送消息时无须重新创建连接上下文，客户端和服务器都将有办法发送简单信息。
不必要的更新的日子即将结束。
为了理解轮询方式如何浪费网络资源，考虑一个拍卖网站。物品可以发布在网站上，在定义的时间段内，用户可以对物品进行投标，在投标时间结束后，物品被卖给出价最高的用户。在拍卖的整个过程中，任意访问投标页面的用户都能够看到当前的出价并使用此信息来决定更高的出价。若网站提供一个极其令人满意的物品来拍卖(一个稍微使用过的iPod，毕竟它是2003年的产品)，同时此物品的拍卖时间仅仅只有一个小时。假设当这个iPod有新的出价时，网站需要仅仅传送一个简短消息，包含新的价格以及可能的一些附加信息(例如，竞标者的线上名称)。我们估计这些信息总是符合64个字节。若考虑到所有已登录的用户，为了获取新的信息，一些Cookie信息需要在HTTP请求中传送。连同内容类型头、可能两三个特定于应用的头、内容长度、浏览器ID等一起，我们估计头信息大约为512字节。现在假设平均有100个用户登录到此网站，在拍卖过程中平均每30秒有一个新的出价。假设出价的频率并不是平均分布的；在某一时刻，出价也许相隔几秒钟(接近于拍卖时间的结束)，而在平时(拍卖时间开始)出价可能相隔几分钟。竞标者将希望最近价格信息一直可用，所以他将谨慎地每两秒钟刷新一次价格；否则，因为在竞标者获取更新前另一个出价已完成，当出价不被通过时，竞标者会变得失意。下面将为了获取更新发送的所有数据进行合计：
平均每分钟30次更新，总计60分钟 = 1800次更新
每次更新带来大约512字节的头信息
发送和接收的头信息总计为：
1800 × 512字节 = 921 600字节 = 900KB
现在，若每次更新包含64字节。同时在此拍卖中，假设有120次出价。因此所有更新信息为：120 × 64字节 = 7.5KB。
因此，有用数据与重复数据的粗略的效率比计算是7.5 / 900 = 0.8%。
这并不是一个理想的分数，并且在更长时间的拍卖下，我们甚至不知道此效率比是如何降低的。
WebSocket旨在通过仅在建立连接时发送上下文信息，并且在连接建立后允许连接的两端在携带着极少的标识信息的上下文信息的情况下发送消息(即使是同时发送)来显著增加这种类型的网络效率。
这样，连接到Web服务器的Web页面能够仅在服务器决定它们需要更新时才接收更新。同时当发送此更新时，它不需要使用关于连接的大负载的上下文信息来使得消息的负荷太重。
WebSocket协议介绍
WebSocket协议是一个网络协议，允许两个相连的端在一个单一TCP连接上进行全双工消息通信。对WebSocket的一个合适的类比是打电话。当打电话时，你通过拨号初始化一个电话呼叫。如果你尝试呼叫的人通过拿起话筒接受了呼叫，连接就已建立。当连接活跃时，如果乐意，双方可以同时说话(虽然并不推荐此种自由交谈)，同时即使在说话时双方也都可以听到正在说些什么。这就是全双工通信的含义所在。不管是否有人在讲话，连接一直保持活跃，直到双方中的一方决定挂断电话。
在WebSocket的场景中，连接通过HTTP和WebSocket端点交互的方式建立。连接的发起者发送一个专门制定的HTTP请求，其中包含其希望连接的WebSocket端点的URL。它开始活动并被称为打开阶段握手。如果服务器愿意接受连接，服务器制定一个称为打开阶段握手响应的特殊的HTTP响应并将其发送回客户端。此时，TCP连接可能已经建立，能够保证WebSocket消息的往返传递。连接将一直保持活跃直到任意一方决定终止连接，或者是某些外部因素导致连接关闭(例如，非活跃期太长导致超时或者物理网络的问题)。
尽管没有任何特定的协议需要部署设置，WebSocket主要用来作为托管在Web服务器上的Web应用和浏览器客户端之间的通信机制。同样，WebSocket连接可以在网络间的任意两端建立，而不必是浏览器和Web服务器上。然而，由于技术的起源，WebSocket技术最直接的机会是为静态Web站点带来活力，并且能够很容易地通过实时数据和活动来增强Web网站和Web应用。
在设置中，存在于浏览器中的WebSocket是使用已经被W3C标准化的称为JavaScript WebSocket API的一个JavaScript API创建的。存在于托管在Web网站的Web服务器上的WebSocket可以通过多种语言来开发。WebSocket的普及如此突然，以至于多种不同语言和Web平台都开始支持它。特别是，Java平台已经快速建立了对WebSocket的支持。本书的主要关注点是探索这个新的Java API的基础设施，尽管一些示例将依赖于那些使用JavaScript API来支持WebSocket的代码。
Java Web Socket API是最近的Java EE 7平台的核心特性，并且任何已经熟悉用其他Java技术或者基于Java的技术来构建Web应用(例如Java Servlet、JSP、JavaServer Faces或者与这些技术相关的任何其他技术)的Web程序员应该熟悉Java平台中的WebSocket并且会考虑通过引入此技术为现有或者未来的应用带来新鲜的和现代的感觉。通过本书，你将学习如何编写WebSocket应用。还将学习Java WebSocket API的所有主要设施，包括WebSocket应用可用的配置选项和多种消息模式、可以在何处存储应用状态、如何配置WebSocket使得它仅可以被安全地访问，以及如何将WebSocket集成到Java EE应用中。你在本书中每一章所学习的知识都将通过示例应用来演示。
本书共包含8章内容。
第1章：Java WebSocket基本原理
该章深入介绍了第一个WebSocket应用：Echo应用。虽然比较简单，但是介绍了Java WebSocket API的主要特性，从而形成了本书中其他章节的基础。
第2章：Java WebSocket生命周期
该章介绍了在WebSocket应用中创建的主要组件——WebSocket端点——的生命周期。此生命周期定义了一个框架，通过此框架可以管理WebSocket端点使用的资源，并且最重要的是定义了如何拦截WebSocket消息。此生命周期通过Lifecycle应用来举例说明。此示例为用户展示了一系列的交通信号灯，以便强调WebSocket端点生命期中的关键阶段。
第3章：消息通信基础
该章使用团体合作绘图应用作为其示例应用，介绍了Web应用中发送和接收消息的基本方面。此示例使用Java应用作为客户端，所以该章也同样展示了Java WebSocket API作为客户端的用法。
第4章：配置与Session
该章阐述了Java WebSocket API中的两个最重要的对象：WebSocket会话对象和端点配置对象。其中前者表示一个和WebSocket对等端的会话，后者保存端点的配置信息。在一个在线聊天的示例应用中，我们使用这些对象说明其特性。
第5章：高级消息处理
该章详细介绍了开发人员用于发送和接收WebSocket消息的所有可用选项。我们以第3章为基础介绍了一些高级话题，例如消息编码和解码策略、同步和异步消息模式。该章中的示例应用使用一个用户界面来阐明API中可用的消息选项。
第6章：WebSocket路径映射
该章覆盖了路径映射的9条规则，讲解了Java WebSocket API中将WebSocket端点发布到一个URI使得对等节点能够连接上的所有可用选项。该章使用一个简单的股票投资组合示例说明精确路径匹配、模板映射、查询字符串等技术，并且讨论了你可能选择某种技术而非另一种技术的各种情况。
第7章：保护WebSocket服务器端点
该章介绍了如何将对WebSocket端点的访问限制为仅是Web应用的某种用户，还介绍了如何确保WebSocket端点间的通信保持为私有。我们回顾了股票投资组合应用，使用安全技术来保护此应用并且使之个性化。
第8章：Java EE平台中的WebSocket
该章首先介绍如何将WebSocket端点集成到大规模的Java EE应用中。该章改进了第4章中的聊天应用，从而利用Java EE平台中的两个关键组件：Java Servlet和EJB，提供了一些在WebSocket端点和其他Java Web组件之间，以及和企业JavaBean间共享应用信息的方法。
目标读者对象
本书适合于如下读者：
希望为Web应用增加交互特性的Web开发人员
希望和WebSocket服务器应用交互的富客户端应用开发人员
有兴趣为支持HTML5的浏览器开发应用的Java EE开发人员
本书假设你具备一些Java编程语言的运用知识、一些Java SE平台的经验和一些JavaScript编程语言的知识。此外，尽管不是必要的，但具备一些Web应用的开发经验可能是有用的。
获取示例应用
所有的示例应用代码都可以从Oracle Press网站www. OraclePressBooks.com下载。文件包含在一个压缩文件中。一旦下载了此压缩文件，就需要解压其内容。示例运行于Glassfish 4.0应用服务器上。Glassfish 4.0可以从https://glassfish.java.net/免费下载，并且可以使用NetBeans IDE进行构建。NetBeans IDE可以从https://netbeans.org/免费下载。
我希望本书能够激发你使用前所未有的想法来编写应用！
