我们先以聊天室为例来讲，web聊天室的实现方法有多种，包括：基于ajax技术的实现，基于Comet（Pushlet）技术的实现，基于XMPP协议的实现，以及基于flash的XmlSocket和远程共享对象的实现。
（1）基于ajax技术的实现。
ajax（异步JavaScript和XML，Asynchronous javascript and xml），它的作用就是可以实现页面与服务器端的无刷新交互。用ajax来实现web聊天室的基本原理是：在页面上每隔一段时间就通过ajax从服务器中 获取数据，然后更新页面显示。这种方法简单明了，缺点是实时性不高。
（2） 基于Comet技术的实现。
Comet 是一种新的 Web 应用架构。基于这种架构开发的应用中，服务器端会主动以异步的方式向客户端程序推送数据，而不需要客户端显式的发出请求。Comet 架构非常适合事件驱动的 Web 应用，以及对交互性和实时性要求较高的应用，如股票交易行情分析、聊天室和 Web 版在线游戏等。
Pushlet是一种comet实现（Pushlet 是开源的Comet 框架）：在Servlet机制下，数据从服务器的Java对象直接推送（push）到客户端的页面，而无需任何Java applet或者插件的帮助。它使server端可以周期性地更新client的web页面，这与传统的request/response方式不同。
Pushlet基于HTTP流，这种技术常常用在多媒体视频、通讯应用中，比如QuickTime。与装载HTTP页面之后马上关闭HTTP连接的做法相 反，Pushlet采用HTTP流方式将新数据源源不断地推送到client，再此期间HTTP连接一直保持打开。有关如何在Java中实现这种 Keep-alive的长连接请参看Sun提供的《HTTP Persistent Connection》和W3C的《HTTP1.1规范》。
（3）基于XMPP协议的实现
XMPP（可扩展消息处理现场协议）是基于XML的协议，是专为及时通信系统设计的通信协议，用于即时消息以及在线现场探测。它在促进服务器之间的准即时 操作。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。XMPP的前身是Jabber，一个开源形式组 织产生的网络即时通信协议。著名的开源聊天系统服务器Openfire就是基于XMPP协议的Jabber服务器。
可以通过Flash或ajax与Jabber服务器进行交互，实现webIM的功能，
（4）基于flash的XmlSocket的实现
Flash Media Server是一个很强大的流媒体服务器，它基于rtmp协议，提供了强壮的流媒体交互功能。在FMS中，提供一种远程共享对象（SharedObject） 的机制，客户端可以创建并连接到服务器端的远程共享对象。可以有很多个客户端连接到同一个远程共享对象中，任何一个客户端对共享对象进行了修改，服务器都 会将共享对象的修改信息发送给所有其他连接到这个共享对象的客户端。这种远程共享对象的机制可以很方面地实现以下功能：· 远程控制幻灯片放映 · 文字聊天 · 网络对战 · 远程选择和播放歌曲 · 现场拍卖 · 客户服务应用程序。
远程共享对象很适合用于实现web聊天室中的群聊功能。为每一个群都建立一个远程共享对象，这样的话，任何用户在群上发信息，就可以通过服务器自动发送到所有的群成员。
用远程共享对象来实现单聊是不实际的。对应单聊的实现，我们需要借助socket。客户端通过socket服务器与其他客户端进行私聊。聊天信息通过socket服务器进行转发。
这种方式是效率最高的web聊天室实现方式。
即时通讯系统架构
简单地介绍一下大型商业应用的IM系统的架构。设计这种架构比较重要的一点是低耦合，把整个系统设计成多个相互分离的子系统。我把整个系统分成下面几个部分：（1）状态消息系统 （2）好友系统 （3）P2P系统 （4）其他扩展业务系统
先看状态消息系统
（1）connd
client接入服务器，可以支持UDP，也可以支持TCP，一般建议优先选择TCP。connd可以布置多台，client接入时，可以用简单的DNS轮询的方式实现负载均衡。connd功能是维护连接和转发消息包。
（2）pconnd
proxy connd, 代理接入服务器，是connd的扩展，除了有connd的功能外，支持服务器的接入，比如web server。
（3）msgd
消息处理服务器，主要功能是用户状态管理，消息转发(包括合理性验证)以及离线消息保存。
说一个用户登录成功后，对所有好友的状态通知过程。我设计的系统中，把用户状态也简单看成类似文本聊天消息。下面用户U的上线过程，他有好友F1, F2。
（1） connd收到U上线消息，将消息发给U所在的msgd。
（2） msgd获取U的好友，F1, F2；如果F1, F2和U不在同一个msgd上，msgd将消息通过connd转给F1, F2所在的msgd。
（3） 最终的msgd把上线通知通过connd发给F1, F2。
msgd的U是通过什么方式获取最新的好友呢？ 这个问题我要着重描述一下。
用户的好友数据都在另外一个子系统中：好友子系统。 msgd通过TCP的方式（为什么用TCP呢？）主动从好友系统获龋同时，msgd也缓存一份好友数据。msgd获取用户好友时，如果cache是最新的，直接从cache取，否则要从好友子系统那边龋现在重点问题出来了，如何确定用户的好友是最新的？这类问题我们要根据不同的业务不同的特点灵活采用不同的方法。请看一种高效的处理方式：
（1） 好友子系统为每个用户的好友算个hash值（可以用MD5）。
（2） client获取好友时，同时也拿到这个hash值；发和好友相关的消息时，把hash值带给msgd。
（3） msgd第一次从好友子系统获取某个用户好友时，也获取这个hash值；像要转发状态消息，获取好友时，把client带过来的hash1和自身的hash2比较一下。。。
像IM这种业务特点是，对好友数据的写很少，读很多，相对于读的消耗，写基本可以忽略的。用上面的方法，基本上每次两者的hash值是相等的，直接从cache拿好友数据。这种处理方法也可以引入到其他应用业务中。建议不要每次都粗暴地跨进程获取类似好友数据。
