目前IM有四種協議:即時信息和空間協議(IMPP)、空間和即時信息協議(PRIM)、針對即時通信和空間平衡擴充的進程開始協議SIP(SIMPLE)以及XMPP。PRIM與XMPP、 SIMPLE相似,但已經再也不使用了。 html
在這四種協議中,XMPP是最靈活的。XMPP是一種基於XML的協議,它繼承了在XML環境中靈活的發展性。所以,基於XMPP的應用具備超強的可擴展性。通過擴展之後的XMPP能夠經過發送擴展的信息來處理用戶的需求,以及在XMPP的頂端創建如內容發佈系統和基於地址的服務等應用程序。並且,XMPP包含了針對服務器端的軟件協議,使之能與另外一個進行通話,這使得開發者更容易創建客戶應用程序或給一個配好系統添加功能。 java
採用XMPP協議的即時通訊應用,當數google吧,Google Talk是基於XMPP協議,並且它還容許其它IM自由使用XMPP協議。如此一來,任何IM供應商在遵循XMPP協議的前提下,均可以隨時與Google Talk實現免費鏈接. 編程
XMPP的前身是Jabber,一個開源形式組織產生的網絡即時通訊協議。XMPP目前被IETF國際標準組織完成了標準化工做。標準化的核心結果分爲兩部分:核心的XML流傳輸協議、基於XML流傳輸的即時通信擴展應用 安全
XMPP的核心XML流傳輸協議的定義使得XMPP可以在一個比以往網絡通訊協議更規範的平臺上。藉助於XML易於解析和閱讀的特性,使得XMPP的協議可以很是漂亮。 服務器
XMPP的即時通信擴展應用部分是根據IETF在這以前對即時通信的一個抽象定義的,與其餘業已獲得普遍使用的即時通信協議,諸如AIM,QQ等有功能完整,完善等先進性。 網絡
XMPP中定義了三個角色,客戶端,服務器,網關。通訊可以在這三者的任意兩個之間雙向發生。服務器同時承擔了客戶端信息記錄,鏈接管理和信息的路由功能。網關承擔着與異構即時通訊系統的互聯互通,異構系統能夠包括SMS(短信),MSN,ICQ等。基本的網絡形式是單客戶端經過TCP/IP鏈接到單服務器,而後在之上傳輸XML。 架構
傳輸的是與即時通信相關的指令。在之前這些命令要麼用2進制的形式發送(好比QQ),要麼用純文本指令加空格加參數加換行苻的方式發送(好比MSN)。而 XMPP傳輸的即時通信指令的邏輯與以往相仿,只是協議的形式變成了XML格式的純文本。這不但使得解析容易了,人也容易閱讀了,方便了開發和查錯。而 XMPP的核心部分就是一個在網絡上分片段發送XML的流協議。這個流協議是XMPP的即時通信指令的傳遞基礎,也是一個很是重要的能夠被進一步利用的網絡基礎協議。因此能夠說,XMPP用TCP傳的是XML流。 併發
開放—XMPP協議是自由、開放、公開的,而且易於瞭解。並且在客戶端、服務器、組件、源碼庫等方面,都已經各自有多種實現。 分佈式
標準—互聯網工程工做小組(IETF)已經將Jabber的核心XML流協議以XMPP之名,正式列爲承認的實時通訊及Presence技術。而XMPP的技術規格已被定義在RFC 3920及RFC 3921。任何IM供應商在遵循XMPP協議下,均可與Google Talk實現鏈接。 工具
證明可用—第一個Jabber(如今XMPP)技術是Jeremie Miller在1998年開發的,如今已經至關穩定;數以百計的開發者爲XMPP技術而努力。今日的互聯網上有數以萬計的XMPP服務器運做著,並有數以百萬計的人們使用XMPP實時傳訊軟件。
分佈式—XMPP網絡的架構和電子郵件十分相像;XMPP核心協議通訊方式是先建立一個stream,XMPP以TCP傳遞XML數據流,沒有中央主服務器。任何人均可以運行本身的XMPP服務器,使我的及組織可以掌控他們的實時傳訊體驗。
安全—任何XMPP協議的服務器能夠獨立於公衆XMPP網絡(例如在企業內部網絡中),而使用SASL及TLS等技術的可靠安全性,已自帶於核心XMPP技術規格中。
可擴展—XML命名空間的威力可以使任何人在覈心協議的基礎上建造客製化的功能;爲了維持通透性,常見的擴展由XMPP Standards Foundation。
彈性佳—XMPP除了可用在實時通訊的應用程序,還能用在網絡管理、內容供稿、協同工具、文件共享、遊戲、遠程系統監控等。
多樣性—用XMPP協議來建造及佈署實時應用程序及服務的公司及開放源代碼計劃分佈在各類領域;用XMPP技術開發軟件,資源及支持的來源是多樣的,使得使你不會陷於被「綁架」的困境。
數據負載過重:隨着一般超過70%的XMPP協議的服務器的數據流量的存在和近60%的被重複轉發,XMPP協議目前擁有一個大型架空中存在的數據提供給多個收件人。新的議定書正在研究,以減輕這一問題。
沒有二進制數據:XMPP協議的方式被編碼爲一個單一的長的XML文件,所以沒法提供修改二進制數據。所以,文件傳輸協議同樣使用外部的HTTP。若是不可避免,XMPP協議還提供了帶編碼的文件傳輸的全部數據使用的Base64。至於其餘二進制數據加密會話(encrypted conversations)或圖形圖標(graphic icons)以嵌入式使用相同的方法。
vCard是一種現存的、普遍使用的,用戶我的信息存儲的標準,有點像是電子名片。基礎的功能是存儲和獲取用戶的電子身份,該信息是用XML表示的,數據的存儲取決於全部現存的Jabber服務器的實現。
客戶機/服務器通訊模式、分佈式網絡、簡單的客戶端、XML的數據格式。
雖然如今即時通訊軟件有不少,可是它們之間不能互聯互通也阻礙了及時通訊用戶的繼續擴展。所以,在現階段的各類即便通訊服務,沒有統一的標準,沒法實現互聯互通的局面下,而XMPP(Extensible Message and presence Protocol)協議的出現,實現了整個及時通訊服務協議的互通。有了這個協議以後,使用任何一個組織或者我的提供的即便通訊服務,都可以無障礙的與其餘的及時通訊服務的用戶進行交流。例如google 公司2005年推出的Google talk就是一款基於XMPP協議的即便通訊軟件。
該協議的前身是Jabber,咱們採起XMPP協議主來實現IM主要是考慮XMPP協議是以XML爲基礎的,它繼承了在XML環境中靈活的發展性。這代表XMPP是可擴展的,因此XMPP信息不只能夠是簡單的文本,並且能夠攜帶複雜的數據和各類格式的文件,也就是說XMPP協議不只能夠用在人與人之間的交流,並且能夠實現軟件與軟件或軟件與人之間的交流,目前支持XMPP協議的即時通信工具備Gtalk、FaceBook IM、Twitter、網易POPO等等通信工具,具備很是好的發展情景。
XMPP的基礎部分已經在2002-2004年獲得了互聯網工程任務組(IETF)的批准,這意味着XMPP在未來就像咱們認爲理所固然的Internet協議TCP/IP、HTTP、FTP、SMTP、POP同樣成爲Internet標準;這意味着之後咱們就像使用Web、使用Email和使用FTP同樣開放地使用IM。甚至若干年後人們會理所固然地認爲163的郵箱能夠給Hotmail發郵件同樣,QQ用戶也能夠添加Gtalk用戶,人們會逐漸忘卻當年軍閥割據紛亂的歷史。這是一種革命性的進步!不支持XMPP的IM將會像IBM的 Token-Ring同樣孤芳自賞或者像DEC NET協議同樣被人遺忘。遙想當年DEC NET和IBM Token-Ring也是多麼意氣風發羽扇綸巾啊!
IMPP:IMPP主要定義必要的協議和數據格式,用來構建一個具備空間接收、發佈能力的即時信息系統。到目前爲止,這個組織已經出版了三個草案RFC,但主要的有兩個:一個是針對站點空間和即時通信模型的(RFC 2778);另外一個是針對即時通信/空間協議需求條件的(RFC2779)。RFC2778是一個資料性質的草案,定義了全部presence和IM服務的原理。RFC2779定義了IMPP的最小需求條件。另外,這個草案還就presence服務定義了一些條款,如運行的命令、信息的格式,以及 presence服務器如何把presence的狀態變化通知給客戶。
SIMPLE:SIMPLE是目前爲止制定的較爲完善的一個。SIMPLE和XMPP兩個協議,都符合RFC2778和RFC2779 。SIMPLE計劃利用SIP來發送presence信息。SIP是IETF中爲終端制定的協議。SIP通常考慮用在創建語音通話中,一旦鏈接之後,依靠如實時協議(RTP)來進行實際上的語音發送。但SIP不只僅能被用在語音中,也能夠用於視頻。SIMPLE被定義爲創建一個IM進程的方法。 SIMPLE在2002年夏季獲得額外的信任,目前,微軟和IBM都致力於在它們的即時通信系統中實現這個協議。 SIMPLE小組致力於進程模式的操做,這將提高運行效率,使基於SIP的機制可以進行會議和三方電話交談控制,也考慮到能和將來提供的許多新特性實現兼容並提高表現能力。有了進程模式,SIMPLE使用SIP來創建一次進程,再利用SDP(進程描述協議)來實際傳輸IM數據。
Openfire 採用Java開發,開源的實時協做(RTC)服務器基於XMPP(Jabber)協議。您可使用它輕易的構建高效率的即時通訊服務器. Openfire安裝和使用都很是簡單,並利用Web進行管理。單臺服務器可支持上萬併發用戶。因爲是採用開放的XMPP協議,您可使用各類支持XMPP協議的IM客戶端軟件登錄服務.
A、Openfire爲Java開源項目
B、採用開放的XMPP協議
C、 有多種針對不通系統的版本
D、使用Socket通信
E、 單臺服務器可支持上萬併發用戶,搭建分佈式雲服務器可輕鬆提供大量併發用戶。
F、 Socket長鏈接
G、服務器穩定小
H、提供接口,可本身開發插件
Smack是一個開源,易於使用的XMPP(jabber)客戶端類庫。Smack API, 是一個 Java 的XMPP Client Library,也是由Jive Software開發。 優勢:編程簡單。 缺點:API並不是爲大量併發用戶設計,每一個客戶要1個線程,佔用資源大,1臺機器只能模擬有限(數千個)客戶.smack是一個用 java 寫的XMPP客戶端代碼庫, 是 spark 的核心.
A: Smack是一個簡單的,功能強大的類庫。給用戶發送信息只需三行代碼即可完成。
B: 不會強迫你向其餘類庫那樣,在信息包層面進行編碼。它提供了更加智能化的類好比Chat和Groups,能使你的工做更富效率。
C: 不須要你熟悉XMPP XML格式,甚至是XML格式。
D: 易於實現機-機對話。
E: Apace License下的開源軟件。你能夠把它用於你的商業或非商業應用程序。
開源界老是有許多有趣的東東,這三個合起來就是一個完整的XMPP IM 實現。包括服務器端——Openfire,,XMPP 傳輸協議的實現——Smack(記住,XMPP是一個協議,協議是須要實現的,Smack起到的就是這樣的一個做用)。三者都是基於Java 語言的實現。
Spark 提供了客戶端一個基本的實現,並提出了一個很好的插件架構,這對於開發者來講不能不說是一個福音。我強烈建議基於插件方式來實現你新增長的功能,而不是去改它的源代碼,這樣有利於你項目架構,把原始項目的影響降到最低。
Openfire 是基於XMPP 協議的IM 的服務器端的一個實現,雖然當兩個用戶鏈接後,能夠經過點對點的方式來發送消息,可是用戶仍是須要鏈接到服務器來獲取一些鏈接信息和通訊信息的,因此服務器端是必需要實現的。Openfire 也提供了一些基本功能,但真的很基本的!慶幸的是,它也提供插件的擴展,像Spark 同樣,一樣強烈建議使用插件擴展的方式來增長新的功能,而不是修改人家的源代碼。
Smack 是一個XMPP 協議的Java 實現,提供一套可擴展的API,不過有些時候,你仍是不得不使用本身定製發送的XML 文件內容的方式來實現本身的功能
下圖展現了三者之間的關係:
http://www.vsharing.com/k/KM/2010-9/637014.html
http://www.cnblogs.com/luxiaofeng54/archive/2011/03/14/1984026.html
http://blog.csdn.net/shimiso/article/details/8816558