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
posted @ 2015-09-21 12:57  消失3003  阅读(746)  评论(2编辑  收藏  举报