ASP.NET MVC SignalR（1）：背景

系列目录：ASP.NET MVC SignalR

关键词：HTTP、轮询、WebSocket、Server-Sent Events、长轮询、forever frame。

---

1. HTTP

HTTP(HyperText Transfer Protocol，超文本传输协议)是Web应用程序客户端和服务器之间进行“交谈”的语言。

HTTP操作基于请求-响应模式，这种模式通常从客户端发起请求开始。同时，请求-响应模式通常也被称作拉(pull)模式：当客户端需要访问服务器上的资源时，它有目的地发起一个到服务器的连接，使用HTTP协议定义的“语言”请求所需的信息；服务器对请求进行处理并返回客户端所请求的资源，然后立即关闭该连接。当客户端每次需要获取一个新资源，都将重复这样的过程。

由此可见，整个HTTP操作是一个同步的过程：向服务器发送请求后，客户端将*等待；在服务器进行响应之前，它什么都不做。即便是使用Ajax技术，这种操作模式使用和遵守的仍是HTTP协议和客户端驱动的请求-响应模式。客户端始终是主动的一方，由它决定何时连接服务器。但在实时通信中，服务器应是主动的一方，可以在任何时刻向客户端发送信息，不需要客户端显式地进行请求。因此在有些情形下，HTTP并不是非常有效。

2. 轮询

当我们需要服务器自身就能成为主动向客户端发送信息的一方时，首先想到的方案应该是“轮询”。“轮询”通常指通过客户端进行周期性的连接，定期检查服务器上是否有一些相关的更新，仍然是通过HTTP的拉(pull)模式。

优点：

• 实现简单
• 适用于任何情形以及所有的服务器和浏览器

缺点：

• 频繁的连接与断开连接
• 连接数量将与客户端数量成比例增加

总之，尽管轮询实现起来比较消耗资源，但如果应用于不需要频繁更新的情形，它是一个不错的选择。

3. 推送

既然使用HTTP拉(pull)模式的应用程序效率并不是很高，自然就需要推(push)模式(服务器推送)了。

1）WebSocket

WebSocket标准包含了一套开发API，该API正由W3C(World Wide Web Consortium，万维网联盟)进行定义；此外，其通信协议正由IETF(Internet Engineering Task Force，Internet工程工作小组)负责制定。

基本上，WebSocket允许建立持久连接，这样的连接在客户端需要时发起，并一直保持开放。因此，客户端和服务器之间创建的是一条双向通道。通过这样的双向通道，通信的任何一方随时都可以向另一方发送信息。

缺点：

• 浏览器未实现WebSocket的所有功能
• 服务器也需要支持WebSocket

但毫无疑问，WebSocket技术可用来实现未来的实时推送服务。

2）Server-Sent Events

Server-Sent Events也被称作API Event Source，是W3联盟正制定的第二个标准，但目前该标准还处于候选推荐状态。它是一个相对简单的Javascript API，不需要修改底层协议，实现和使用起来比WebSocket标准要简单。

与WebSocket相比，Server-Sent Events将创建一个从服务器到客户端的单向通道，但是由客户端打开此通道。换言之，客户端订阅来自服务器的一个可用事件源，当数据通过该通道发送时，客户端接受通知。

所有通信都执行在HTTP之上。和一些更传统的连接方式相比，仅有的差别是响应中使用了Content-Type text/event-stream，这表明该连接将保持开放，因为它将用来从服务器发送连续的事件流或消息。

优点：

• 几乎目前所有的浏览器都支持该标准（除了IE和一些特定的移动浏览器）

缺点：

• 必须对使用的Content-Type进行解析
• 建立的是服务器到客户端的单向通道，如果客户端需要向服务器发送数据，它必须建立一个不同的连接才能完成，这将涉及比WebSocket更多的资源开销

4. 基于HTTP的推送

1）长轮询

这种推送技术和上文所述的轮询非常类似，但为了提高通信的效率和即时性，它也进行了某些改进。

在这种情况下，客户端同样对更新进行轮询，但与轮询不同的是：如果没有待接受的数据，连接将不会自动关闭，并且以后将再次发起。在长轮询中，连接将一直保持开放状态，直到服务器有事件要通知。

关闭由客户端发起的连接仅有两个方面的原因：

a. 服务器通过连接向客户端发送数据

b. 由于连接空闲产生了超时错误

这两种情况下，一条新的连接将立即建立，此时将再次等待更新。

此连接专门用于从服务器接收数据，如果客户端需要向上发送数据，它将以并行的方式打开一个专门用于从服务器接收数据的HTTP接连。

优点：

• 更新客户端时的延迟比较低
• 打开和关闭的连接数量减少，资源占用率比轮询低
• 不需要使用特殊的浏览器，HTTP提供的功能足矣

缺点：

• 资源消耗比其它只打开一个连接的技术要高一些
• 通知之间可能存在一些延迟

2）forever frame

forever frame巧妙利用了HTML的<IFRAME>标签来建立永久开放的连接。在某种程度上，这和Server-Sent Events非常类似。

forever frame需要客户端页面有一个<IFRAME>标签，标签源中的URL用来指定正在监听的服务器。服务器将保持此连接永久开放，并调用客户端上定义的脚本函数，通过此连接发送更新。在某种程度上，我们可能会说该技术主要取决于接收时在客户端执行的流脚本(streaming script)。

优点：

• 资源利用率非常高
• 实时效果非常好

缺点：

• 使用复杂
• 内存占用高
• 当客户端向服务器发送数据时还需要使用其它连接

5. 我们需要的不仅是推送

在异步、多用户以及实时应用的环境中，推送只是不可或缺的一部分。为了开发出这些总能令人赏心悦目的系统，还需要更多的功能和特性：

• 管理连接的用户：服务器必须知道哪些用户连接到服务，哪些用户已经断开连接，此外还需要对客户端数量不确定的所有因素进行控制。
• 管理订阅：服务器必须能够对订阅进行管理，或对接收特定类型消息的用户进行分组。
• 接收和处理操作：服务器不仅能实时地将信息发送给客户端，也能动态接收和处理信息。
• 对信息的提交进行监控：单独提供与消息排队、信息提交管理有关的一些机制，从而确保所有客户端都能被更新。
• 能够为多个客户端提供灵活易用的API