我們先以聊天室為例來講， 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拿好友數據。這種處理方法也可以引入到其他應用業務中。建議不要每次都粗暴地跨進程獲取類似好友數據。
