基于Web的IM实现思考

基于Web的IM实现思考

 

原文地址:http://www.cnblogs.com/zhuweisky/archive/2006/05/09/395259.html

 

如今绝大多数IM软件都是基于桌面的，通常使用Tcp/Udp，并且都实现了防火墙穿透(代理)和基于Udp的NAT穿透的P2P技术。创建一个基于Web的IM是否可行(我们这里不考虑在浏览器中嵌入类似ActiveX控件的伪B/S，因为它实际上还是一个C/S，我们要讨论的是纯的Web方式)？答案无疑是肯定的，但是有些限制，这是因为：

(1)基于Web的IM不可避免的采用Http作为主要的通信协议，而Htpp的非连接、无状态特性使得状态管理比较困难。当然，使用Http的好处是能轻易的穿过防火墙。(大多数网关都默认开放http的80端口)

(2)单向性。只有客户端(Web浏览器)主动去联系服务器，而服务端无法主动联系特定的客户。

 

这些Web特性将会导致哪些限制了？

(1)客户与客户之间无法实现直接的P2P。因为基于Web时，一个客户无法直接“找到”另一个客户，就更别提NAT穿透了。

(2)客户与客户之间的消息交互是“伪实时”的，所有的消息都必须通过服务器进行“被动”地中转。比如，当客户A要把某个聊天消息Msg发送给B时，它首先将msg提交给服务器，因为服务器无法主动找到B，所以服务器需要暂存这个Msg(比如放入数据库)，等到B来请求时，才能将这个Msg转发。这就是“被动”的含义了。

 

即使有这么多限制，我们仍然可以实现一个像模像样的基于Web的IM，这只是需要一些简单的技术/技巧。

(1)客户端使用Ajax技术实现页面局部刷新。如果每当有新消息来临或状态通知来临时，都需要整个页面刷新，这个WebIM一定不及格。

(2)客户端使用定时器不断的询问服务器是否有新的通知。比如是否有别人发给我的Msg、某个好友的状态是否发生的变化等，如果有，则向服务器提取这些信息。

(3)文件传输功能，仍然可以实现，同文字聊天消息一样。发送方先将文件上载到服务器，接收方通过轮询发现有传送给自己的文件时，则下载文件。

(4)视频聊天功能，仍然可以实现。首先是视频的捕捉、编码、解码，这可能需要在浏览器中嵌入类似ActiveX的控件。其次是视频数据的传递，可以采用与文件传输类似的方式。无疑，这种方式是非常的丑陋。

(5)群功能。简单思考一下，会发现这个实现起来比较简单。

 

尽管，通过种种技巧，我们可以实现一个基于Web的IM，但是它还能当之无愧的称为“即时通讯”吗？从前面的分析我们可以看到，所有的P2P通信都是“伪”即时的，并且如此实现的IM的服务端在用户量稍微大一点的时候的负载可想而知(特别是视频聊天功能，服务器需要暂存多大的数据量？)。

所以，据我所认识的来推断，基于纯Web的IM现在还没有办法做成产品(你自己写个玩玩当然没问题)。当然，也许在我的认识之外可能有更好的解决方案，如果你知道这样的解决方案，请一定要留言告诉我。

我想，有一点是真的，那就是B/S永远也无法吞并C/S的所有领地，有很多应用一定还是非C/S不可的。