WebIM通信实现

最新推荐文章于 2024-04-08 10:45:11 发布

原创最新推荐文章于 2024-04-08 10:45:11 发布 · 6.1k 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#服务器 #xmlhttprequest #comet #javascript #ajax

程序设计专栏收录该内容

6 篇文章

订阅专栏

本文讨论了Web-based IM信息通信的特点，分析了客户端“拉”模式和服务器“推”模式的实现方案及其优缺点，包括Comet技术和基于插件的解决方案。

关于Web-based IM通信模式的思考

摘要：

本文从Instant Messaging 出发，讨论了Web_based IM信息通信的特殊性，并在此基础上详细分析了现有的实现方案及其各自优缺点。

引言：

Instant Messaging（读成I-M），是一种使人们能在网上识别在线用户并与他们实时交换消息的技术，现主要用于网络即时聊天软件和特殊设备的网络实时监控。该技术普遍采用C/S架构，基于TCP/UDP协议，通过服务器协作，利用防火墙穿透（代理）或基于UDP的NAT穿透技术，保持客户端之间的持续长连接，实现客户端之间信息的实时交互。但是，该类模式下的软件系统要求下载安装专用的客户端程序，导致系统部署成本高昂，系统维护困难。同时，为保证即时通信的顺利完成，一般还要求客户端防火墙开放特定端口，引起系统安全问题。因此，这种模式的IM技术在网络环境下的广泛使用还存在一些局限性。

Web-based IM，是基于HTTP协议，系统采用B/S模式，客户端通过访问特定的网页而实现的及时通信技术。这种即时通信技术以网页为载体，避免下载安装庞大的客户端程序，系统功能在服务器端统一维护，既减少了系统部署费用，也降低了维护难度。因此，Web-based IM技术将在基于Web的远程监控、网站客服等方面有重大的意义。

然而，Web-based IM在技术实现上存在难以逾越的困难：首先，Web-based IM采用HTTP作为主要的通信协议，因此，HTTP的非连接、无状态特性将导致通信状态管理非常困难；其次，HTTP访问的单向性只允许客户端（Web浏览器）主动去联系服务器，而服务端却无法主动联系特定的客户端，更不用谈多个客户端之间的互访。所以，要实现Web环境下的实时通信，必须首先要解决这个问题，即充分利用HTTP的特性，在技术实现上做出适当的调整，以适应即时通信的需要。本文将在前人的基础上，从客户端“拉”和服务器“推”的角度，总结归纳基于Web的即时通信方案，并进一步分析比较各自的优劣点。

Web IM通信实现方式

1. 客户端“拉”（Client_pull）模式

传统的HTTP请求模式为：客户端主动向服务器发送信息更新请求，服务器响应请求，客户端接收完响应之后显示更新信息，这也称为客户端“拉”。为实现客户端信息（准）实时更新，一般采用客户端轮询的方案，即实时信息通过网络发送到服务器，保存到服务器内存甚至服务器实时数据库中，客户端根据实际情况，每隔一定时间就自动向服务器重新请求页面数据，以保证客户端内容的实时性。然而，传统的做法是客户端页面整体刷新，导致大量无用信息的重复下载，不但浪费客户端、服务器以及网络资源，而且这种同步的请求方式还将致使客户端页面长时间处于等待响应阶段，而无法继续操作，严重影响客户端体验效果。因此，随着 AJAX技术的成熟，人们常使用XMLHttpRequest对象，采用异步方式访问服务器定时获取更新信息。

2. 服务器“推”（Server-push）模式

服务器“推”模式，即服务器在信息变化之后主动发送新的信息到客户端，客户端接收之后自动进行更新。但是，由于HTTP无状态的特性，服务器响应完毕客户端请求之后，二者之间的通信在默认情况下会自动断开，加上NAT、客户端防火墙等因素的影响，服务器随时向客户端发送更新信息的条件还很不成熟，除非二者之间保持实时的连接。要实现客户端与服务器的实时连接，目前存在以下两种方案值得考虑。

1)基于客户端套接字的服务器推技术

要实现客户端与服务器的实时连接，传统的方式是采用在客户端页面中嵌入ActiveX、Flash、Applet之类的插件，插件基于TCP/UDP协议，通过套接字方式，实现客户端与服务器的持久连接，保证二者信道的持续通畅，以达到服务器在获取新信息之后可以主动发送到客户端，进行更新。一般而言，在不考虑通信信息的完整性的情况下，为减轻服务器的负载，服务器可以基于UDP协议向客户端发送更新信息。由于UDP是一种不可靠的协议，所以如果需要考虑通信信息的一致性等，则必须使用具有信息完整性验证的TCP协议进行通信。

2)Comet技术

近年来，由于Ajax技术的发展和推广，一种基于HTTP长连接、无需在浏览器端下载安装插件服务器“推”技术，即Comet技术，成为新宠。其实现模型有以下两种：基于 AJAX 的长轮询（long-polling）方式和基于 Iframe 及 htmlfile 的流（streaming）方式。

长轮询的基本思想就是服务器不立即响应客户端请求，直到服务器接收到针对该客户端的新的信息的时候才响应客户端的请求。客户端一收到服务器的响应就马上发送下一个请求,这样就保证了客户端总是处于请求等待响应的状态,从而使得服务器处于“主动”的地位，当其有数据要发送时可以准确无误地找到客户端,这就类似于一个持久的TCP连接,如图所示

如果在双方规定的时间内，在两个方向上都没有反应（如客户端没有需要更新的信息，而连接即将超时的情况），则服务器可以用一个没有数据的空响应来进行响应。这个响应将立即触发一个新的客户端请求，这样就可以保证在网络连接不正常的情况下双方都可以在一个合理的时间内知道。为了避免传统HTTP请求导致页面整体刷新的情况，客户端请求一般采用AJAX技术，利用XMLHttpRequest对象向服务器发送异步请求以更新数据。

流（streaming）方式的基本思想是：在 HTML 页面里嵌入一个隐蔵帧，然后将这个隐藏帧的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。然而，iframe服务器端并不返回直接显示在页面的数据，而是返回对客户端 Javascript 函数的调用，如“<script type="text/javascript">js_func(“data from server ”)</script>”。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递；客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。

从上图可以看到，每次数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接，服务器端可以设置一个超时时间，超时后通知客户端重新建立连接，并关闭原来的连接）。

实现方式比较

采用纯粹的HTTP+AJAX技术实现网页的实时通信，技术简单，成本低，但是存在一些不足：第一，所有客户端的更新消息通过服务器进行“被动”地中转，客户端通过对服务器进行轮询，实现客户与客户之间的消息交互，因此客户端获取的信息是“伪实时”的。第二，轮询的时间间隔的设定异常困难：如果时间间隔过短，就会产生大量的无用请求，加重网络的负担；如果时间间隔过长，又不能保证客户端及时获取更新信息。由此可见，该方案的成功实现必须解决低响应等待时间和低网络带宽之间的矛盾问题。倘若服务器仅在数据发生变化之后，才向客户端发送更新信息，那么这一切问题都能得到妥善处理。

Comet技术可以解决低响应等待时间和低网络带宽之间的矛盾问题，并且在信息实时性方面有所改善，但是仍然存在一些问题需要注意：首先，该模式会仍然导致部分无用信息的下载；其次，对于某些对信息实时性要求很高的应用，它也表现出心有余而力不足；再者，基于HTTP1.1规范，同一客户端不能同时使用超过2个的HTTP长连接；最后，由于Web 服务器会为每个连接创建一个线程，如果在大型的商业应用中使用 Comet，服务器端需要维护大量并发的长连接，因此在这种应用背景下，服务器端需要考虑负载均衡和集群技术，或是在服务器端为长连接作一些改进。

基于插件的解决方案利用Socket连接服务器的确可以保证客户端信息的实时更新，但一些因素值得考虑：首先，部分页面插件需要客户端下载安装（如ActiveX），因此在特定客户端环境下可能因为插件安装失败而导致实时通信无法使用；其次，页面插件使用套接字接口，需要服务器开放一个通信端口，在实现过程中甚至可能需要程序员解决防火墙穿透问题；再次，页面插件在接收到服务器返回的信息之后，可能无法通过脚本语言（如JavaScript）去更新HTML页面（如Applet）；最后，客户端连接数量增多会加重网络负担和服务器负载，直接影响客户端并发访问数量。