1、引言

當前IM的站場上依舊硝煙彌漫，QQ, MSN, Google Talk, ICQ, Yahoo!還都在爭奪著市場的份額。今天我所要說的，是跳出商業利益趨勢之短利，而從長遠的角度考慮IM的發展趨勢。

目前各大IM各自為政，在互相學習中提供著越來越豐富的功能。在他們瘋狂的瓜分著internet用戶市場的時候，我們普通的用戶成了他們商業競爭的受害 人。恕不見，因為自己的朋友有著不同的IM，為了與他們通訊，我們只好自己申請成為那個IM的用戶。結果，每個人一開機，就有著少則3－4個IM同時叮叮 咚咚的啟動，多則6－7個。

雖然也有著多合一的IM客戶端，但是一來有些功能由于這種整合客戶端所限，我們無法使用；二來，我們依舊需要管理著越來越多的帳戶和密碼。不少人因為犯懶，而多個帳戶使用一個密碼，結果導致一個密碼被人知道后，其他的密碼也被人家猜到了，而使信息泄密。



如何讓用戶面對一個簡單的界面，用最少的用戶名密碼對完成所必須的IM通訊呢？

現今的世界，唯有開放，方能生存。

我的想法是各個IM服務器之間互連，不要再那么封閉了。IM服務器遵循某種標準的IM通訊協議，然后就像email服務器那樣，雖然IM服務器不同，IM的服務不同，但是他們之間可以共享最基本的消息通訊。

這樣QQ的用戶可以添加MSN的好友，并且可以與MSN的好友交流，而不必非注冊一個MSN帳戶。各個IM服務提供商，由IM孤島，變成了IM接入點，所 有的IM孤島互聯，組成一個IM的服務器網絡，或者世界。成為任何一個IM的用戶，都可以與這個IM世界里的任何服務器的任何用戶交流，而無須非在對方的 IM服務器上注冊用戶。

其實這種思想在Email身上有很好的體現。雖然大家的email服務器不同，注冊的服務不同。但是我們依舊可以和不同的email服務器上用戶通訊，而不必非得在對方的email服務器上注冊一個用戶。

如果從email的視角看今天的IM的話，那么稱今天的IM為IM孤島(IM Island)，一點都不為過。未來是互聯而開放的世界，任何孤島都會被打破，互聯是一種必然的趨勢。

其實抽象一下IM，雖然IM的功能五花八門，但是我們90%以上的時間就是在使用下面這幾個公共的特性：

• 文字消息交流 (包括表情和圖片)
• 語音、視頻交流
• 群(組)交流
• 好友管理(包括好友組管理，好友的添加刪除，以及好友信息或者blog頁面)
• 游戲娛樂平臺
• email提醒
• 各種消息
  

因此，針對這些公共的部分，依據現有協議，總結出一個通用的IM協議其實是可能的。

以這個通用的協議為基礎，所有加入IM World的IM服務器，必須遵守這個通用IM協議，并采用這個協議互相通訊。就可以完成IM世界里面基本交流無障礙。當然，IM服務商，會除這個通用協 議中要求的這些特性外，提供更多額外的服務給用戶，以吸引用戶使用自己的IM作為IM World的接入點。

互聯導致IM用戶群的整合，對于任何的IM服務商，都是用戶群的擴大，由于共同制定和完善通用IM標準，也會使標準更加完善，通訊更穩定。

這是考驗一個公司和決策人氣魄和膽識的時候。不同的公司和決策人會作出不同的反應。

到底是給自己的用戶加上沉重的枷鎖，關起門來不讓他們跑掉？還是擺出自信和開放的姿態，敞開大門，歡迎其他的IM與自己的消息互通？

并不是所有的人都能夠真正的把目光放長遠，能夠作出開放的姿態的。但是，趨勢是一定的，已經有一些小范圍的消息互通，但是還不足夠。讓我們拭目以待，看看誰是這個敢吃螃蟹的人，讓這個世界的IM成功的互聯起來。

我下面就說兩種互通的例子，第一個是一個開放的IM服務器和一個封閉的IM服務器，目前以QQ為例，通過QQ Bridge，或者叫做QQ網關，進行互通的例子。第二個，是讓IM服務器分布式，類似于email和dns那樣，im服務器同聯盟服務器通訊，使得不同 的IM用戶可以互相通訊。

2、可以添加QQ好友，并且可以與QQ好友通訊的IM服務器

2.1 背景



在這個圖中，800001 - 800002是QQ用戶，他們使用自己的計算機，分別連接QQ不同的服務器。而Universal IM服務器則是另一個IM服務商，我們虛構一個名字叫做Universal IM，簡稱(UIM)。屬于這個IM服務商的有biyao@guimenzong.com， luxueqi@dazhufeng.qingyunmen.com, zhangxiaofan@xiaozhufeng.qingyunmen.com這3個用戶。

QQ Bridge 服務器，實際上是一個虛擬的多個QQ客戶端的服務器，當前他有兩個QQ帳戶，一個是900001，另一個是900002。

當我們忽略掉QQ Bridge服務器的時候，這就是典型的兩個IM服務商，他們擁有自己的用戶群，而這些用戶群中的用戶不可以跨群訪問。也就是說800001永遠無法和 luxueqi@dazhufeng.qingyunmen.com取得聯系，無論是加好友還是發消息都不行。

這就是我們目前大部分IM的現狀。

我的想法是，在UIM服務器和QQ服務器中間建立起一個橋梁。由于QQ的思想并不開放，所以，我們將這個QQ Bridge服務器放在靠近UIM的位置，并且將其視為UIM服務器的一個子模塊。當然，如果QQ是開放的，那么這個QQ Bridge就要改名為QQ-UIM Gateway了，并且獨立出來，做QQ服務器和UIM服務器的消息路由。

暫且，我們先將其視為UIM的一個模塊（畢竟這符合QQ當前的封閉策略）。

首先，UIM管理人員，申請若干個合法的QQ帳戶，在此例子中，是900001, 900002。

2.2 通訊過程

背景清楚后，通訊過程就比較好理解了。假設zhangxiaofan（張小凡）這個用戶有一個好友小白，那個好友的QQ號是800003。如果沒有QQ Bridge，那么張小凡就必須申請一個QQ號，然后在QQ中添加QQ好友800003，然后方可和小白通訊。

可是當我們有QQ Bridge后，情況就發生了變化。

張小凡直接在自己UIM帳戶zhangxiaofan@xiaozhufeng.qingyunmen.com里面添加好友，指定好友IM為QQ，IM 號為800003。然后UIM服務器就把這個QQ好友添加到張小凡的UIM帳戶里了。

那么UIM服務器在后臺是如何做這個添加的呢？

首先，UIM服務器隨機的選擇一個實現申請好的QQ號，比如900001，然后QQ Bridge會通過900001，向QQ服務器申請將800003加為好友。由于在QQ服務器眼里，QQ Bridge實際上是一個QQ客戶端，所以，就按照正常手續征詢對方同意，當對方同意后，這個好友就倍加到900001這個QQ的好友列表中了。

在UIM服務器中記載了，zhangxiaofan@xiaozhufeng.qingyunmen.com這個帳戶有一個QQ好友：800003，而QQ Bridge服務器記載了，他使用的是服務器QQ號900001來和800003進行通訊。

• 遠程好友: QQ:800003
• 本地QQ: 900001
• 本地帳戶: zhangxiaofan@xiaozhufeng.qingyunmen.com

下面張小凡要找小白聊天，于是他雙擊他好友列表中的小白這個好友，敲了一段文字"hello"。

這個hello會最先被送到UIM服務器，UIM服務器的dispatcher會發現這個消息不是本地的，而是QQ服務器的，于是轉發消息到QQ Bridge服務器，QQ Bridge服務器一看，目的地是QQ:800003，而源是zhangxiaofan@xiaozhufeng.qingyunmen.com，于是， QQ Bridge就用QQ:900001這個帳戶向800003這個帳戶發送消息。

對于800003而言，他只是看到自己收到了一個從900001這個號碼發來的消息，而意識不到，這個實際上是一個UIM服務器的帳戶。

小白回消息，"I got it"。這個消息會先發送到QQ服務器，QQ一看目的地是900001，于是消息就被分發到900001身上，QQ Bridge就收到了這條回復。然后對比本地表后發現，遠程好友是：QQ:800003的，本地QQ是900001的，應該發送給張小凡。于是QQ Bridge和UIM服務器聯系，UIM服務器將這個消息傳遞到張小凡的計算機上。

通過這個描述，大家可能會發現，QQ Bridget非常像網絡中的NAT，網絡地址轉換。而這里，實際上是IM協議轉換，非常類似的機制。

通過這種形式，QQ用戶和UIM用戶可以無縫銜接，他們之間的通訊是透明的，他們意識不到，特別是QQ的用戶，自己通訊的對方是另一種協議。

2.3 缺陷

這是一個類NAT的東西，也就面臨和NAT一樣的問題，就是QQ的好友無法添加UIM的好友，除非做靜態映射。也就是說，添加好友的行為，一定是UIM用戶添加QQ用戶，而無法是QQ用戶添加UIM用戶。這個其實也是由于QQ不開放的原因。

靜態映射可以這樣完成。比如張小凡之前曾經有一個QQ號800004，現在他遷移到UIM服務器了，他可以在UIM服務器上注冊自己的QQ帳戶。這樣，所 有800004的好友，自動的加入他UIM的好友。以后，凡是張小凡向QQ好友發消息，那么本地QQ號就不再是原來的900001了，而是張小凡注冊的 QQ帳戶800004。因此，任何想添加張小凡QQ的人，只要添加800004，那么就自然會出現在張小凡的UIM好友列表里。

通過注冊自己已有的QQ號來綁定UIM帳號。即方便了遷移，也方便了QQ添加遷移到UIM用戶為好友。


3 UIM服務器聯盟

UIM是單一的服務器么？就像QQ, MSN, Google Talk那樣由一個大公司來運作，集中管理？

我們可以這樣子，其實也可以分布式。就像email服務器那樣。下面我就舉一個分布式的例子。

3.1 各自為政

假設UIM服務器是可以免費下載的，任何人如果愿意都可以架設UIM服務器，而且由于UIM之間的協議是標準化的，任何人也可以實現自己的兼容UIM服務器。

那么現在，鬼王宗、青云門的大竹峰和小竹峰都建立了自己的IM服務器方便自己的門人通訊。就如下圖所示。



鬼王宗的服務器是： uim.guiwangzong.com
大竹峰：uim.dazhufeng.qingyunmen.com
小竹峰：uim.xiaozhufeng.qingyunmen.com

在小竹峰下有幾個用戶，其中兩個，一個是田靈兒(tianlinger)，另一個是張小凡(zhangxiaofan)。

如果張小凡想和田靈兒通訊，很簡單，就和今天的QQ一樣。由于他們都連入了同一個服務器，通過服務器就可以互相通訊了(綠線)，甚至可以直接點對點通訊（黃線）。

3.2 結盟

在初期，各自為政似乎還基本滿足。但隨著日子的發展，張小凡通過七脈會武結識了陸雪琪師姐。可是小凡沒有大竹峰的帳戶，小凡始終無法與陸雪琪取得聯系。

雖然他們都有自己的IM帳戶，但是由于大竹峰和小竹峰的服務器并不交換信息，所以除非張小凡跑到大竹峰去，否則無法和陸雪琪交流。

這種需求不是個例，而是具有普遍性的。田靈兒也還想著和龍首峰的齊昊師兄談天說地呢。共同的利益，促使了結盟的出現。

如下圖所示：



于是有一個叫做Universal IM Union(宇宙IM聯盟)出現了。凡是符合UIM服務器間協議標準的服務器都可以加入聯盟。而聯盟有一個union.uim.com的服務器，負責管理注冊、注銷和查詢UIM服務器。

現在大竹峰和小竹峰的服務器都加入了這個宇宙IM聯盟。

這樣當大竹峰的服務器需要轉發消息到小竹峰的時候，他可以查詢union.uim.com，從而得知小竹峰的服務器的位置，反之亦然。服務器互相之間可達了，那么剩下的就是按照標準通訊協議交換消息了。

3.3 通訊

這回張小凡想和同樣加入了宇宙IM聯盟的鬼王宗服務器用戶碧遙聯系，他會發送消息到biyao@guiwangzong.com。

如下圖所示：



小竹峰的服務器一看消息目的地，發現是guiwangzong.com，而不是本地。于是小竹峰的服務器就到union.uim.com上查詢，鬼王宗的服務器在哪里。

union查詢后，告訴小竹峰的服務器，鬼王宗的服務器在uim.guiwangzong.com。

然后小竹峰的服務器就將張小凡的消息，直接發給uim.guiwangzong.com。

鬼王宗的服務器收到后，一對比，發現目的地是本地帳戶碧遙的，于是就將這個信息轉發到碧遙的計算機上。

碧遙回復消息也是同樣的一個流程。

大家可以注意到，其實union.uim.com實際上是一個dynamic dns。聯盟之負責記錄各個im服務器的域和服務器的地址。而不負責轉發消息。所有的消息交換是由各個UIM服務器之間完成的，聯盟服務器不參與信息交換，僅僅起到一個目錄查詢的作用。

其中可以優化的是，如果所有UIM服務器遵循同樣的標準的話，那么張小凡在第一個消息后，就可以從小竹峰的服務器上得知鬼王宗服務器的地址，甚至碧遙計算 機的地址，于是直接向鬼王宗服務器或者碧遙的計算機發送消息，和當前的IM點對點交流是一樣的。避免了中間的流程，降低了延時。
?
4、尾聲

感謝大家的提醒。沒想到我的這些想法剛好和Jabber的思路不謀而合，這著實讓我興奮了一會兒，仔細的閱讀了Jabber的簡單介紹后，有一種相見恨晚的感覺。

“Jabber是一個開放的、基于XML的協議。它的用途在即時通訊及表示信息方面。”

“Jabber的關鍵特色是，分布式的即時通訊系統，以及使用XML串流。”

“Jabber網絡是基于服務器的（即客戶端之間彼此不直接交談），但是也是分布式的。不像AOL即時通或MSN Messenger等服務，Jabber沒有中央官方服務器。”

“Jabber系統有一個獨特的網關（也稱作傳送器）功能，該功能允許用戶可以使用其他協議，如AOL、ICQ、MSN、Yahoo、短信或者電子郵件。和Trillian或Gaim等其他多協議客戶端不同的是，Jabber在服務器級別提供這個功能，任何Jabber用戶都可以注冊一個這樣的網關來登錄其他網絡。也就是說任何支持Jabber協議的客戶端都可以訪問一個存在的網關，來與其他網絡上的用戶聯系。”

Jabber具有如下特點：

開放— Jabber協定是自由、開放、公開的，并且易于了解。而且在客戶端、服務器、元件、源碼庫等方面，都已經各自有多種實作。

標準— 因特網工程工作小組（IETF）已經將Jabber的核心XML串流協定以XMPP之名，正式列為認可的即時通訊及Presence技術。而XMPP的技術規格已被出版為RFC 3920及RFC 3921。

證實可用— 第一個Jabber技術是Jeremie Miller在1998年開發的，現在已經相當穩定；數以百計的開發者為Jabber技術而努力。今日的因特網上有數以萬計的Jabber服務器運作著，并有數以百萬計的人們使用Jabber即時傳訊軟件。

分布式— Jabber網絡的架構和電子郵件十分相像；因此任何人都可以運行自己的Jabber服務器，使個人及組織能夠掌控他們的即時傳訊體驗。

安全— 任何Jabber服務器可以獨立于公眾Jabber網絡（例如在企業內部網絡中），而使用SASL及TLS等技術的可靠安全性，已內建于核心XMPP技術規格中。

可擴展— XML命名空間的威力可使任何人在核心協定的基礎上建造客制化的功能；為了維持通透性，常見的擴充套件由Jabber軟件基金會管理。

彈性佳— Jabber除了可用在即時通訊的應用程序，還能用在網絡管理、內容供稿、協同工具、檔案共享、游戲、遠端系統監控等。

多樣性— 用Jabber協定來建造及布署即時應用程序及服務的公司及開放源碼計劃分布在各種領域；用Jabber技術開發軟件，資源及支援的來源是多樣的，使得使你不會陷于被“綁架”的困境。

－－ 摘自《維基大百科全書：中文》
第一個案例和Jabber中的網關很相似，用以融合其他多種協議，不單單是其他IM協議，也可以是SMS或者Email。第二個案例則和Jabber整體的思想很接近，是基于服務器的IM，而不是基于集中管理的IM，這種非集中管理的方式，是認證域最小化，有助于安全性的提升，另外也給服務器的區域組織提供了更好的靈活性。這也更證明了我的思路的方向是對的。開放、互聯是必然趨勢，分布式服務器機制更靈活的對IM網絡進行組織，并且更好的提升了局部安全性，因為縮小了信任域。

而此時另一個名字又出現在眼前 － Google。此前一直不理解為什么Google Talk采用Jabber協議，也沒有主動去了解Jabber協議具體內容，僅當其為一個普通的IM協議而已。而 如今，在了解了Jabber的思路后，再對我比前面的分布與互通的想法，再一次感嘆Google的大氣和眼光之長遠。開放的、標準化的、分布式服務器的、基于XML的、 可以支持其它協議聯通能力的、具有良好擴展能力的Jabber，確實是一個很好的選擇。雖然在今天Google Talk尚顯幼稚，但是從底層的Jabber已經可以小窺其野心和它未來的良好的潛力。期待著未來有一日，Google能夠成功的推動各大IM的互聯，結束當今IM的信息孤島的局面。祝Google與Jabber越做越好。

推薦讀物：

維基大百科全書：
http://en.wikipedia.org/wiki/Jabber
http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol

于XMPP通訊協議相關的RFC：
RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922, Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923, End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

Jabber 官方網站：
http://www.jabber.org/
http://www.jabber.org/jeps/

轉載于:https://www.cnblogs.com/dancefire/archive/2006/09/06/1985884.html

總結

以上是生活随笔為你收集整理的关于下一代IM服务器的一点想法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。