实时Web应用开发领域的经典著作，由实时Web技术领域的布道者和资深Web开发工程师撰写
系统讲解构建实时Web应用的过程、方法与核心技术，同时包含大量代码和设计示例，实战性极强
海报：
实时Web应用开发领域的经典著作，由实时Web技术领域的布道者和资深Web开发工程师撰写。不仅详细讲解了构建实时Web应用所需的各项技术，还系统讲解了实时Web应用规划与设计的的过程和方法，为构建实时Web应用提供了翔实的指导。此外，《构建实时Web应用：基于HTML5 WebSocket、PHP和jQuery》包含大量代码和设计示例，实战性极强。
《构建实时Web应用：基于HTML5 WebSocket、PHP和jQuery》一共10章：第1章介绍了什么是实时Web技术及其原理；第2章详细讲解了构建实时Web应用需要哪些技术和工具；第3章讲解了如何利用Pusher构建实时Web应用；第4章介绍了如何根据需要在Web应用和原生应用之间做出选择；第5章讲解了如何规划应用程序的功能和结构；第6章讲解了实时Web应用的设计，第7章讲解了如何为实时Web应用创建HTML和CSS标记；第8章和第9章则非常详细地讲解了如何构建实时Web应用的后端程序；第10章讲解了如何实现实时事件和jQuery效果。
第一部分
熟悉必备技术
构建Web应用程序并不是一件单纯的事情。现代Web开发人员需要综合利用多种技术来构建满足用户需求的应用程序。
在本书的这一部分，你将熟悉构建第一个实时Web应用程序所需要的技术。由于该项目会利用在本书编写时更常使用的Web技术，因此你也许会对书中该部分的许多内容感到熟悉。如果你觉得不用复习这些内容，那么可以跳过它们。
第1章 什么是实时
如果你关注最近一两年Web开发的趋势，那么你肯定会发现“实时”（realtime）这个术语无处不在。那么，什么是“实时”？它与当前的Web技术有何不同？为什么我们要使用实时技术？
为了能够更好地理解“实时”的含义，以及实时技术如何改变我们已经了解的Internet，让我们来看看实时技术试图解决的问题的历史。实时技术要解决的问题是：我们如何在不需要用户部分做任何动作的情况下影响客户端上Web应用程序的状态？
1.1 传媒的演化
实事求是地说，当谈到信息时，我们会期望首先得到最新的消息。这种期望可以归因于一种与生俱来的知识渴求，期望第一时间获悉某个消息，或者仅仅因为我们想成为消息灵通人士。如图1-1所示，在某些情况下，成为第一个获得消息的人甚至比消息本身是什么更重要。（这正是消息灵通人士存在的全部理由。）我们想要首先知道消息，这意味着我们希望信息立即出现。
图1-1 某一特定类型的信息感知价值随着该信息的广泛流传而减小
对最新消息无休止地追求使我们成为现在这个样子：我们不再满足于洞穴里的壁画、厚重的手写巨著、书或宣传单这样的出版物，我们还期待更多的东西；虽然报纸和期刊可以快到每天上午更新一次，但是那些更新的内容都是昨天发生的；广播和电视可以给我们传递信息，但是那需要数小时，在最好的情况下也要数分钟。
Internet让我们能够与全球的用户共享信息。但是，在其中发现信息仍然需要花费较长的时间。同时，我们会依赖像电子邮件或论坛这样的东西来传递消息。Google通过让数据更容易被发现，改变了这一切。即使这样，页面索引的速度意味着我们仍然需要在搜索时等待待发现的数据。实时更新博客的发明意味着如果我们知道从何处寻找更新，那么我们就能更频繁地接受更新。而更新发生的地方常常是常见的传媒品牌。
一些社会传媒发动大众，创建了一个全球的网络。在这个网络中，任何人都可以分享消息。对一些像2011埃及革命这样的事件，Twitter这样的服务是我们信息的主要来源。但是，第一个实时Web游戏规则的改变者是这样的一种应用，它第一次实现了新消息在发布后就即刻可以通过搜索发现。这开始说明了通过Internet访问新信息的价值，并增加用户对实时内容的期望，甚至导致了著名科技评论家Robert Scoble发出“实时Web是否对Google造成威胁”的疑问。
社交媒体平台逐渐转变为实时通信平台。在一个人发出状态更新后不久，他就会得到一个或多个用户的回复。我们中的大多数人都觉得这种快速的、交互式的反馈十分新颖。在这之前，我们可能只是玩基于Flash的游戏，习惯于Internet应用程序提供相对静态的单用户体验。这种新的多用户交互功能会使用户的粘性更强，有效提升用户体验。
现在，传媒已经从原先有延时的、静态的内容演进为更丰富、更生动、更具交互性的内容。用户已经看到了这些改变，他们对Internet应用程序的期望大大增加。
Internet和社会媒体演示了这些即时的满足感。即使这样，许多来源仍然不能给我们以实时内容的形式提供新闻，或不能给我们提供交互性的、有趣的体验。为什么这些媒体不能提供这样的体验呢？
1.1.1 是网站而不是Web应用
在传统情况下，Internet用于分享静态内容。网站只是一些静态实体结构，这些实体属于一个静态集合。网站的主要焦点在于显示内容。现在的网站仍然以“内容为王”。即使使用那些创建“动态内容”的技术，实际上也只是说服务器现在能够基于一组不同的但是定义过的参数和值来动态地生成静态内容。
我们使用那些应用程序来关注Internet或Web浏览器上的实体。这些应用程序主要聚焦于保证它满足最新的需求。这些需求包括下载和呈现HTML和图像，理解如何跟踪那些链接。在开始时，这就足够了。
传媒的形式被迫不断演进，网站也是如此。因为我们想要让我们的网站更好看，所以我们引入了CSS。因为我们想要网站对用户输入的交互性更好（你相信人们曾经需要为DHTML库付费吗？例如，下拉菜单），所以引入了JavaScript（让我们忘记VBScript的存在吧）。这些技术增强了Web浏览器的能力，但是，它们集中于增强网站的页面。
一些先驱者看到静态网站以外的机会。他们开始思考动态的Web应用程序。在Web应用程序中，关注点从服务器转移到了客户端。客户端需要做更多的事情：它需要动态地检索和载入内容，它可以基于用户反馈改变用户界面（User Interface，UI），UI能够以一种与桌面应用程序关联的方式呈现。它不再那么关注页面的重新载入，不再那么关注一般意义上的页面。在Web应用程序中，内容也变得不会那么基于文本，我们开始实现了更加吸引人的、更具交互性的表示。
1.1.2 HTTP解决方案
开发人员是技术的先驱。在越来越多的开发人员开始构建Web应用程序时，对Web浏览器的需求也增加了。这时，性能变成了问题。这种问题不仅由于Web浏览器应用程序，还与浏览器运行的机器有关。它们实实在在地推动网络技术和Web应用程序的发展，但是也遇到了一个重大的绊脚石：HTTP。
HTTP是一种协议。在设计之初，客户端可以使用该协议请求获得数据并接受响应。但是，一些Web应用程序开始要求信息从服务器发送到客户端，所以，我们需要主动进入客户端。主动进入客户端需要非标准的、复杂的解决方案。考虑到不同的Web浏览器支持的特性不同，你可以想象，要同时支持这么多种情况，问题必然比较复杂。（后文会涉及其中一些问题。）
当今流行的Twitter和Facebook采用了一些解决方案，这些解决方案可以用来演示实时网络技术带来体验的好处和需求。在这种需求的推动下，实时网络技术得到了极大的改进，可用性大大增强。
1.1.3 一个先要解决的问题：实时究竟意味着什么
术语“实时”指的是在事件发生和我们意识到事件发生之间是即时的。从事件发生到事件传递的时间差实际上取决于事件。如果事件是用脚踩踏汽车的刹车，则在要用脚踩踏和刹车起作用之间的时间需要尽可能短。但是，如果事件是在一个足球论坛中发送一条聊天消息，使该消息显示给其他用户，则延迟几秒钟不会有太大影响。从根本上看，对于那些需要在足够短的时间里传递的事件，传递事件的时间还是有影响的；延时要使得在应用消息时消息的意义仍然在上下文中有效。不妨想象扇耳光的场景：在扇耳光和感到疼痛之间是没有延时的，这就是实时。如果在这个场景中有延时，就会令人相当困惑。
然而，在一开始为所有情况添加任何类型的实时体验特性并不是那么简单。但是，开发人员并没有被轻易打败。他们提出了一些聪明的变通方法，想出了解决服务器与客户端之间通信故障的方法。
注意：这里省略了一些与服务器双向通信的早期的方法，这是因为它们现在并不常使用。
1.1.4 AJAX
随着JavaScript开始流行，开发人员开始利用XMLHttpRequest对象来异步地（asynchronously）发送HTTP请求，而不需要重新载入当前页面。这称为异步JavaScript和XML（Asynchronous JavaScript and XML，AJAX）。
对于往网页应用中添加用户触发的功能而言，这种方法非常好用。从这个角度看，因为AJAX仍然典型地依赖于浏览器中的事件（例如，单击事件），所以它并没有真正解决关于请求内容实时更新的任何问题。
1.1.5 轮询
在使用AJAX后，离浏览器自动触发事件并处理新信息只有一步之遥了。开发人员设计了一种类似于JavaScript中setInterval()函数的自动刷新的机制，以在每隔几秒钟就检查一次更新（见图1-2）。
图1-2 频繁地轮询发送HTTP请求来检查新信息
为了更好地了解这样做是多么浪费资源，可以把这种通信想象成客户端和服务器在进行下面这样的对话：
与现实生活中类似，像这样的客户端与服务器之间的交流十分烦人，而且效率低下。
尽管这种轮询的解决方案确实是一个起点，但是它有一些缺点。最明显的问题在于，它创建了许多空的请求，这为应用程序带来了许多不必要的开销。这种开销限制了应用程序的规模。如果一个应用程序每秒都要轮询一次数据，那么在有100?000个用户同时使用这个应用程序时，每分钟就会有6?000?000个请求。
如果考虑每个HTTP请求的开销（在Peter Lubbers给出的测试中，每次请求和响应需要871字节），则仅仅为了确认服务器没有发生新的事件，就来回发送了很多额外的信息。
1.1.6 HTTP长轮询
在实时技术的演化历程中，下一步是HTTP长轮询（long-polling）。如图1-3所示，这种方法打开一个HTTP请求，并等待一段时间以侦听服务器返回。如果有新数据，服务器就会发送新数据并关闭请求；否则，在到达一定的时间限制后，就会关闭请求，打开一个新请求。
图1-3 HTTP长轮询保持HTTP请求打开一段时间以检查更新
与标准的轮询相比，长轮询效率更高。它降低了开销，减少了应用程序发送的请求数。客户端与服务器之间的对话会变成如下所示：
显然这就好多了。这种方法提供了一种机制，使得服务器可以通过这种机制在不需要客户端部分有任何动作的情况下通知客户端有新的数据。
如果客户端与服务器之间需要双向通信，那么就可以看到HTTP长轮询的一个主要缺点。一旦开启了长轮询的HTTP连接，客户端要与服务器通信的唯一方法就是再进行一次HTTP请求。这就导致了资源的重复使用：一份资源用于服务器到客户端的消息，另一份资源用于客户端到服务器的消息。这种重复的确切影响取决于发生了多少双向通信；客户端与服务器之间交互的越多，资源消耗也就越多。
这种方法的另一个问题是，在两次长轮询请求之间有一个短小的时间间隔，在这段时间里客户端的数据与服务器的数据不是同步的。只有在重新建立连接后，客户端才能检查是否有新的数据。这个问题的后果实际上取决于数据。如果数据对时间高度敏感，那么这就不是一件好事。
1.1.7 HTTP流
除了在新数据到达或给定的间隔时间内连接不关闭外，HTTP流（stream）与HTTP长轮询都非常相似。与HTTP长轮询中的情形不同，新的数据通过一直保持打开的现有连接传送。
客户端与服务器间的“交谈”现在变成如下所示：
这种解决方案的好处是，客户端与服务器间的连接是持久化的，所以一旦有新数据，就可以即时发送给客户端。所有的新数据也都是通过相同连接发送的。这保证了服务器与客户端能够保持同步。
HTTP流仍然不能提供双向通信，于是它也潜在地要求为从客户端到服务器的通信使用第二个连接。
HTTP流这种方法还有个大问题。在不同的Web浏览器中，它的实现方式并不一致。在基于Gecko的浏览器中，可以使用有多个部分的可替换头部来告诉浏览器将旧数据用新收到的数据替换。这在其他浏览器中就不可能。所以，对应的响应缓冲区会越来越大，直到实在太大了而不得不关闭连接，再重新打开对服务器的连接。
……
译者序
前言
第一部分 熟悉必备技术
第1章 什么是实时
1.1 传媒的演化
1.1.1 是网站而不是Web应用
1.1.2 HTTP解决方案
1.1.3 一个先要解决的问题：实时究竟意味着什么
1.1.4 AJAX
1.1.5 轮询
1.1.6 HTTP长轮询
1.1.7 HTTP流
1.1.8 在Web浏览器中使用基于HTTP的解决方案的其他问题
1.2 解决方案：WebSocket
1.3 为什么要学习实时Web技术
1.4 请即刻在你的应用中使用实时Web技术
1.5 小结
第2章 工具
2.1 我们要构建什么
2.2 选择工具
2.2.1 HTML5
2.2.2 CSS3
2.2.3 JavaScript和jQuery
2.2.4 PHP
2.2.5 MySQL
2.2.6 HTML5的WebSocket技术和Pusher
2.2.7 OAuth
2.3 小结
第3章 Pusher
3.1 Pusher简史
3.2 为什么要使用Pusher
3.2.1 扩展性
3.2.2 WebSocket、旧技术支持和自动重连接
3.2.3 其他客户端库
3.2.4 REST API
3.2.5 服务器库
3.2.6 开发人员工具
3.2.7 文档
3.3 Pusher中的术语
3.4 开始使用Pusher
3.5 使用Pusher发送事件
3.6 调试Pusher应用程序
3.7 小结
第二部分 规划应用
第4章 选择Web应用
4.1 为什么要在Web应用与原生应用间做抉择
4.2 要考虑的因素
4.2.1 了解用户
4.2.2 市场推广
4.2.3 销售
4.2.4 发布应用程序
4.2.5 外观和性能
4.2.6 开发
4.3 根据需要进行选择
4.3.1 选择Web应用而不是原生应用
4.3.2 最终的决定：构建Web应用程序
4.4 小结
第5章 确定应用的功能和结构
5.1 应用要做什么
5.2 应用不做什么
5.3 用户扮演的角色
5.3.1 主持人
5.3.2 参与者
5.4 前端规划
5.4.1 要使用的技术
5.4.2 使用HTML5
5.4.3 CSS3、媒体查询以及它们如何影响设计和HTML
5.4.4 效果和动画
5.5 后端规划
5.6 将所有这些整合入线框图中
5.6.1 筹划主页
5.6.2 筹划参与者的问答页面
5.6.3 筹划主持人的问答页面
5.7 小结
第三部分 构建基本内容
第6章 设计应用
6.1 为设计设置目标
6.2 定义颜色面板
6.3 选择字体
6.4 设计常见的页面元素
6.4.1 创建页眉
6.4.2 创建页脚
6.4.3 表单元素
6.5 设计主页视图
6.5.1 创建房间的表单
6.5.2 加入房间的表单
6.6 设计房间视图
6.6.1 设计参与者视图
6.6.2 设计关闭的房间视图
6.6.3 设计主持人视图
6.7 小屏幕布局
6.8 小结
第7章 创建HTML和CSS标记
7.1 开始构建基本部分：设置HTML5文档
7.2 获得需要的字体
7.3 常见的元素
7.3.1 页眉标记
7.3.2 页脚标记
7.3.3 样式
7.3.4 使得页眉和页脚具有响应
7.4 开发主页视图
7.4.1 编写标记
7.4.2 添加媒体查询
7.5 开发参与者的活动房间视图
7.5.1 编写标记
7.5.2 实现CSS
7.5.3 添加媒体查询
7.6 开发参与者的关闭的房间的视图
7.6.1 尽可能少引入新标记
7.6.2 添加样式
7.6.3 关于媒体查询
7.7 开发主持人的房间视图
7.7.1 修改现有的标记
7.7.2 更新CSS
7.7.3 更新媒体查询
7.8 小结
第8章 构建后端：
第1部分
8.1 计划简单的MVC框架
8.1.1 确定文件夹结构
8.1.2 为所有的请求设置路由
8.1.3 设置实用工具函数
8.1.4 结束路由的编写
8.1.5 设置核心类
8.1.6 创建抽象模型类
8.2 增加页眉标记和页脚标记
8.3 构建主页
8.3.1 创建主页控制器
8.3.2 创建主页视图
8.4 添加错误处理程序
8.4.1 创建错误控制器
8.4.2 创建错误视图
8.4.3 添加与错误有关的样式
8.4.4 测试错误页面
8.5 构建数据库
8.6 处理表单提交
8.6.1 计划表单提交工作流程
8.6.2 设置并检查有效的动作
8.6.3 防止重复提交和欺骗性的提交
8.6.4 编写表单处理方法
8.7 小结
第9章 构建后端：
第2部分
9.1 构建问题
9.1.1 构建Question控制器
9.1.2 添加问题视图
9.1.3 完成视图编写
9.1.4 添加提出问题表单
9.1.5 构建问题模型
9.1.6 为控制器添加表单处理程序和数据访问方法
9.2 构建房间
9.2.1 增加Room控制器
9.2.2 构建房间模型
9.2.3 向Room控制器添加表单处理程序
9.3 测试所有代码
9.3.1 创建第一个房间
9.3.2 关闭房间
9.3.3 重新打开房间
9.3.4 加入房间
9.3.5 提出第一个问题
9.3.6 为问题投票
9.3.7 回答问题
9.4 小结
第10章 实现实时事件和jQuery效果
10.1 添加需要的证书和库
10.1.1 获得Pusher的API证书
10.1.2 下载Pusher的PHP API包装
10.1.3？载入Pusher的JavaScript API包装
10.1.4？载入jQuery
10.2 在后端实现实时
10.2.1 创建事件
10.2.2 测试实时事件
10.3 在前端实现实时
10.3.1 订阅通道
10.3.2 绑定事件
10.4 增加效果
10.4.1 处理房间事件
10.4.2 为增加新问题添加动画
10.4.3 为问题增加投票
10.4.4 回答问题中的动画和问题重排
10.5 小结
附录A 深入理解OAuth
