關于xmpp協(xié)議可以參考：http://www.jabbercn.org

什么是OpenFire

Openfire 采用Java開發(fā)，開源的實時協(xié)作（RTC）服務器基于XMPP（Jabber）協(xié)議。

　　您可以使用它輕易的構建高效率的即時通信服務器。Openfire安裝和使用都非常簡單，并利用Web進行管理。單臺服務器可支持上萬并發(fā)用戶。

由于是采用開放的XMPP協(xié)議，您可以使用各種支持XMPP協(xié)議的IM客戶端軟件登陸服務。

XMPP（Jabber）協(xié)議

1、 介紹

XMPP是一種基于XML的協(xié)議，它繼承了在XML環(huán)境中靈活的發(fā)展性。因此，基于XMPP的應用具有超強的可擴展性。經過擴展以后的XMPP可以通過發(fā)送擴展的信息來處理用戶的需求，以及在XMPP的頂端建立如內容發(fā)布系統(tǒng)和基于地址的服務等應用程 序。而且，XMPP包含了針對服務器端的軟件協(xié)議，使之能與另一個進行通話，這使得開發(fā)者更容易建立客戶應用程序或給一個配好系統(tǒng)添加功能。

2、 定義：

XMPP（可擴展消息處理現(xiàn)場協(xié)議）是基于可擴展標記語言（XML）的協(xié)議，它用于即時消息（IM）以及在線現(xiàn)場探測。它在促進服務器之間的準即時操作。這個協(xié)議可能最終允許因特網用戶向因特網上的其他任何人發(fā)送即時消息，即使其操作系統(tǒng)和瀏覽器不同。

XMPP的前身是Jabber， 一個開源形式組織產生的網絡即時通信協(xié)議。XMPP目前被IETF國際標準組織完成了標準化工作。標準化的核心結果分為兩部分；

核心的XML流傳輸協(xié)議

基于XML FreeEIM流傳輸?shù)募磿r通訊擴展應用

XMPP的核心XML流傳輸協(xié)議的定義使得XMPP能夠在一個比以往網絡通信協(xié)議更規(guī)范的平臺上。借助于XML易于解析和閱讀的特性，使得XMPP的協(xié)議能夠非常漂亮。

XMPP的即時通訊擴展應用部分是根據(jù)IETF在這之前對即時通訊的一個抽象定義的，與其他業(yè)已得到廣泛使用的即時通訊協(xié)議，諸如AIM，QQ等有功能完整，完善等先進性。

在IETF 中，把IM協(xié)議劃分為四種協(xié)議，即時信息和出席協(xié)議(Instant Messaging and Presence Protocol, IMPP)、出席和即時信息協(xié)議(Presence and Instant Messaging Protocol, PRIM)、針對即時信息和出席擴展的會話發(fā)起協(xié)議(Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions, SIMPLE)，以及可擴展的消息出席協(xié)議(XMPP)。最初研發(fā)IMPP 也是為了創(chuàng)建一種標準化的協(xié)議，但是今天，IMPP 已經發(fā)展成為基本協(xié)議單元，定義所有即時通信協(xié)議應該支持的核心功能集。

3、 XMPP協(xié)議的優(yōu)點

a. XMPP 協(xié)議是公開的，由JSF開源社區(qū)組織開發(fā)的。XMPP 協(xié)議并不屬于任何的機構和個人，而是屬于整個社區(qū)，這一點從根本上保證了其開放性。

b. XMPP 協(xié)議具有良好的擴展性。在XMPP 中，即時消息和到場信息都是基于XML 的結構化信息，這些信息以XML 節(jié)(XML Stanza)的形式在通信實體間交換。XMPP 發(fā)揮了XML 結構化數(shù)據(jù)的通用傳輸層的作用，它將出席和上下文敏感信息嵌入到XML 結構化數(shù)據(jù)中，從而使數(shù)據(jù)以極高的效率傳送給最合適的資源。基于XML 建立起來的應用具有良好的語義完整性和擴展性。

c. 分布式的網絡架構。XMPP 協(xié)議都是基于Client/Server 架構，但是XMPP協(xié)議本身并沒有這樣的限制。網絡的架構和電子郵件十分相似，但沒有結合任何特定的網絡架構，適用范圍非常廣泛。

d. XMPP 具有很好的彈性。XMPP 除了可用在即時通信的應用程序，還能用在網絡管理、內容供稿、協(xié)同工具、檔案共享、游戲、遠端系統(tǒng)監(jiān)控等。

e. 安全性。XMPP在Client-to-Server通信，和Server-to-Server通信中都使用TLS (Transport Layer Security)協(xié)議作為通信通道的加密方法，保證通信的安全。任何XMPP服務器可以獨立于公眾XMPP網絡（例如在企業(yè)內部網絡中），而使用SASL及TLS等技術更加增強了通信的安全性。如下圖所示：

4、 XMPP協(xié)議的組成

主要的XMPP 協(xié)議范本及當今應用很廣的XMPP 擴展：

l RFC 3920 XMPP（新的RFC6120）：核心。定義了XMPP 協(xié)議框架下應用的網絡架構，引入了XML Stream（XML 流）與XML Stanza（XML 節(jié)），并規(guī)定XMPP 協(xié)議在通信過程中使用的XML 標簽。使用XML 標簽從根本上說是協(xié)議開放性與擴展性的需要。此外，在通信的安全方面，把TLS 安全傳輸機制與SASL 認證機制引入到內核，與XMPP 進行無縫的連接，為協(xié)議的安全性、可靠性奠定了基礎。Core 文檔還規(guī)定了錯誤的定義及處理、XML 的使用規(guī)范、JID（Jabber Identifier，Jabber 標識符）的定義、命名規(guī)范等等。所以這是所有基于XMPP 協(xié)議的應用都必需支持的文檔。

l RFC 3921：用戶成功登陸到服務器之后，發(fā)布更新自己的在線好友管理、發(fā)送即時聊天消息等業(yè)務。所有的這些業(yè)務都是通過三種基本的XML 節(jié)來完成的：IQ Stanza（IQ 節(jié)）, Presence Stanza（Presence 節(jié)）, Message Stanza（Message 節(jié)）。RFC3921 還對阻塞策略進行了定義，定義是多種阻塞方式。可以說，RFC3921 是RFC3920 的充分補充。兩個文檔結合起來，就形成了一個基本的即時通信協(xié)議平臺，在這個平臺上可以開發(fā)出各種各樣的應用。

l XEP-0030 服務搜索。一個強大的用來測定XMPP 網絡中的其它實體所支持特性的協(xié)議。

l XEP-0115 實體性能。XEP-0030 的一個通過即時出席的定制，可以實時改變交變廣告功能。

l XEP-0045 多人聊天。一組定義參與和管理多用戶聊天室的協(xié)議，類似于Internet 的Relay Chat，具有很高的安全性。

l XEP-0096 文件傳輸。定義了從一個XMPP 實體到另一個的文件傳輸。

l XEP-0124 HTTP 綁定。將XMPP 綁定到HTTP 而不是TCP，主要用于不能夠持久的維持與服務器TCP 連接的設備。

l XEP-0166 Jingle。規(guī)定了多媒體通信協(xié)商的整體架構。

l XEP-0167 Jingle Audio Content Description Format。定義了從一個XMPP 實體到另一個的語音傳輸過程。

l XEP-0176 Jingle ICE（Interactive Connectivity Establishment）Transport。ICE傳輸機制，文件解決了如何讓防火墻或是NAT（Network Address Translation）保護下的實體建立連接的問題。

l XEP-0177 Jingle Raw UDP Transport。純UDP 傳輸機制，文件講述了如何在沒有防火墻且在同一網絡下建立連接的。

l XEP-0180 Jingle Video Content Description Format。定義了從一個XMPP 實體到另一個的視頻傳輸過程。

l XEP-0181 Jingle DTMF（Dual Tone Multi-Frequency）。

l XEP-0183 Jingle Telepathy Transport Method。

5、 XMPP協(xié)議網絡架構

XMPP是一個典型的C/S架構，而不是像大多數(shù)即時通訊軟件一樣，使用P2P客戶端到客戶端的架構，也就是說在大多數(shù)情況下，當兩個客戶端進行通訊時，他們的消息都是通過服務器傳遞的(也有例外，例如在兩個客戶端傳輸文件時)．采用這種架構，主要是為了簡化客戶端，將大多數(shù)工作放在服務器端進行，這樣，客戶端的工作就比較簡單，而且，當增加功能時，多數(shù)是在服務器端進行．XMPP服務的框架結構如下圖所示．XMPP中定義了三個角色，XMPP客戶端，XMPP服務器、網關．通信能夠在這三者的任意兩個之間雙向發(fā)生．服務器同時承擔了客戶端信息記錄、連接管理和信息的路由功能．網關承擔著與異構即時通信系統(tǒng)的互聯(lián)互通，異構系統(tǒng)可以包括SMS(短信)、MSN、ICQ等．基本的網絡形式是單客戶端通過TCP／IP連接到單服務器，然后在之上傳輸XML，工作原理是：

(1) 點連接到服務器；

(2) 務器利用本地目錄系統(tǒng)中的證書對其認證；

(3) 點指定目標地址，讓服務器告知目標狀態(tài)；

(4) 務器查找、連接并進行相互認證；

(5) 點之間進行交互；

6、 XMPP客戶端

XMPP 系統(tǒng)的一個設計標準是必須支持簡單的客戶端。事實上，XMPP 系統(tǒng)架構對客戶端只有很少的幾個限制。一個XMPP 客戶端必須支持的功能有：

1. 通過 TCP 套接字與XMPP 服務器進行通信；

2. 解析組織好的 XML 信息包；

3. 理解消息數(shù)據(jù)類型。

XMPP 將復雜性從客戶端轉移到服務器端。這使得客戶端編寫變得非常容易，更新系統(tǒng)功能也同樣變得容易。XMPP 客戶端與服務端通過XML 在TCP 套接字的5222 端口進行通信，而不需要客戶端之間直接進行通信。

基本的XMPP 客戶端必須實現(xiàn)以下標準協(xié)議（XEP-0211）：

RFC3920 核心協(xié)議Core

RFC3921 即時消息和出席協(xié)議Instant Messaging and Presence

XEP-0030 服務發(fā)現(xiàn)Service Discovery

XEP-0115 實體能力Entity Capabilities

7、 XMPP服務器

XMPP 服務器遵循兩個主要法則：

1、監(jiān)聽客戶端連接，并直接與客戶端應用程序通信；

2、與其他 XMPP 服務器通信；

XMPP開源服務器一般被設計成模塊化，由各個不同的代碼包構成，這些代碼包分別處理Session管理、用戶和服務器之間的通信、服務器之間的通信、DNS（Domain Name System）轉換、存儲用戶的個人信息和朋友名單、保留用戶在下線時收到的信息、用戶注冊、用戶的身份和權限認證、根據(jù)用戶的要求過濾信息和系統(tǒng)記錄等。另外，服務器可以通過附加服務來進行擴展，如完整的安全策略，允許服務器組件的連接或客戶端選擇，通向其他消息系統(tǒng)的網關。

基本的XMPP 服務器必須實現(xiàn)以下標準協(xié)議

RFC3920 核心協(xié)議Core

RFC3921 即時消息和出席協(xié)議Instant Messaging and Presence

XEP-0030 服務發(fā)現(xiàn)Service Discovery

8、 XMPP網關

XMPP 突出的特點是可以和其他即時通信系統(tǒng)交換信息和用戶在線狀況。由于協(xié)議不同，XMPP 和其他系統(tǒng)交換信息必須通過協(xié)議的轉換來實現(xiàn)，目前幾種主流即時通信協(xié)議都沒有公開，所以XMPP 服務器本身并沒有實現(xiàn)和其他協(xié)議的轉換，但它的架構允許轉換的實現(xiàn)。實現(xiàn)這個特殊功能的服務端在XMPP 架構里叫做網關(gateway)。目前，XMPP 實現(xiàn)了和AIM、ICQ、IRC、MSN Massager、RSS0.9 和Yahoo Massager 的協(xié)議轉換。由于網關的存在，XMPP 架構事實上兼容所有其他即時通信網絡，這無疑大大提高了XMPP 的靈活性和可擴展性。

9、 XMPP地址格式

一個實體在XMPP網絡結構中被稱為一個接點，它有唯一的標示符jabber identifier(JID)，即實體地址，用來表示一個Jabber用戶，但是也可以表示其他內容，例如一個聊天室．一個有效的JID包括一系列元素：

(1) 名(domain identifier)；

(2) 點(node identifier)；

(3) 源(resource identifier)．

它的格式是node@domain/resource，node@domain，類似電子郵件的地址格式．domain用來表示接點不同的設備或位置，這個是可選的，例如a在Server1上注冊了一個用戶，用戶名為doom，那么a的JID就是doom@serverl，在發(fā)送消息時，指明doom@serverl就可以了，resource可以不用指定，但a在登錄到這個Server時，fl的JID可能是doom@serverl、exodus(如果a用Exodus軟件登錄)，也可能是doom@serverl/psi(如果a用psi軟件登錄)．資源只用來識別屬于用戶的位置或設備等，一個用戶可以同時以多種資源與同一個XMPP服務器連接。

10、 XMPP消息格式

XMPP中定義了3個頂層XML元素: Message、Presence、IQ，下面針對這三種元素進行介紹。

<Message>

用于在兩個jabber用戶之間發(fā)送信息。Jsm(jabber會話管理器)負責滿足所有的消息，不管目標用戶的狀態(tài)如何。如果用戶在線jsm立即提交;否則jsm就存儲。

To : 標識消息的接收方。

from : 指發(fā)送方的名字或標示(id)

Text: 此元素包含了要提交給目標用戶的信息。

結構如下所示:

<message to= ‘lily@jabber.org/contact’ type =’chat’>

<body> 你好，在忙嗎</body>

</message>

<Presence>

用來表明用戶的狀態(tài)，如：online、away、dnd(請勿打擾)等。當用戶離線或改變自己的狀態(tài)時，就會在stream的上下文中插入一個Presence元素，來表明自身的狀態(tài)．結構如下所示：

<presence>

From =‘lily @ jabber.com/contact’

To = ‘yaoman @ jabber.com/contact'

<status> Online </status>

</presence>

<presence>元素可以取下面幾種值:

Probe: 用于向接受消息方法發(fā)送特殊的請求

subscribe: 當接受方狀態(tài)改變時，自動向發(fā)送方發(fā)送presence信息。

< IQ >

一種請求／響應機制，從一個實體從發(fā)送請求，另外一個實體接受請求，并進行響應．例如，client在stream的上下文中插入一個元素，向Server請求得到自己的好友列表，Server返回一個，里面是請求的結果．

<iq > 主要的屬性是type。包括:

Get :獲取當前域值。

Set :設置或替換get查詢的值。

Result :說明成功的響應了先前的查詢。

Error: 查詢和響應中出現(xiàn)的錯誤。

結構如下所示:

<iq from =‘lily @ jabber.com/contact’id=’1364564666’ Type=’result’>

XMPP通信協(xié)議

一、 Stream

<!-- #################### 通信內容采用壓縮技術，以及通信的相關協(xié)議 ####################### -->

<stream:stream xmlns:stream="http://etherx.jabber.org/streams"

        xmlns="jabber:client" from="127.0.0.1" id="e38900bc" xml:lang="en"

        version="1.0">

<!--

xmlns 表示通信客戶端

from 客戶端的地址（來源）

id

lang 通信語言

-->        

<stream:features>

    <!-- 開始tls協(xié)議[TLS]的頻道加密方法 -->

    <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls>

    <!-- 加密技術、安全證書 -->

    <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">

        <mechanism>DIGEST-MD5</mechanism>

        <mechanism>PLAIN</mechanism>

        <mechanism>ANONYMOUS</mechanism>

        <mechanism>CRAM-MD5</mechanism>

    </mechanisms>

    <!-- 采用壓縮技術 -->

    <compression xmlns="http://jabber.org/features/compress">

        <method>zlib</method>

    </compression>

    <!-- 權限 -->

    <auth xmlns="http://jabber.org/features/iq-auth" />

    <!-- 注冊 -->

    <register xmlns="http://jabber.org/features/iq-register" />

</stream:features>

關于TSL 參考：http://www.jabbercn.org/RFC3920

1、TSL協(xié)議遵循以下規(guī)則：

A、 一個遵守本協(xié)議的初始化實體必須（MUST）在初始化流的頭信息中包含一個'version'屬性并把值設為“1.0”。

B、 如果TLS握手發(fā)生在兩個服務器之間，除非服務器聲稱的DNS主機名已經被解析，通信不能（MUST NOT）繼續(xù)進行。

C、 當一個遵守本協(xié)議的接收實體接收了一個初始化流（它的頭信息中包含一個'version'屬性并且值設為“1.0”），在發(fā)送應答流的的頭信息（其中包含版本標記）之后，它必須發(fā)送（MUST）<starttls/>元素（名字空間為 'urn:ietf:params:xml:ns:xmpp-tls'）以及其他它支持的流特性。

D、 如果初始化實體選擇使用TLS,TLS握手必須在SASL握手之前完成；這個順序用于幫助保護SASL握手時發(fā)送的認證信息的安全，同時可以在必要的時候在TLS握手之前為SASL外部機制提供證書。

E、 TLS握手期間,一個實體不能（MUST NOT）在流的根元素中發(fā)送任何空格符號作為元素的分隔符（在下面的TLS示例中的任何空格符都僅僅是為了便于閱讀）；這個禁令用來幫助確保安全層字節(jié)精度。

F、 接收實體必須（MUST）在發(fā)送<proceed/> 元素的關閉符號">" 之后立刻開始TLS協(xié)商。初始化實體必須（MUST）在從接收實體接收到<proceed/> 元素的關閉符號">" 之后立刻開始TLS協(xié)商。

G、 初始化實體必須（MUST）驗證接收實體出示的證書；關于證書驗證流程參見Certificate Validation ( 第十四章第二節(jié))。

H、 證書必須（MUST）檢查初始化實體(比如一個用戶)提供的主機名；而不是通過DNS系統(tǒng)解析出來的主機名；例如，如果用戶指定一個主機名"example.com"而一個DNS SRV [SRV]查詢返回"im.example.com"，證書必須（MUST）檢查"example.com".如果任何種類的XMPP實體（例如客戶端或服務器）的JID出現(xiàn)在一個證書里，它必須（MUST）表現(xiàn)為一個別名實體里面的UTF8字符串，存在于subjectAltName之中。如何使用 [ASN.1] 對象標識符 "id-on-xmppAddr" 定義在本文的第五章第一節(jié)第一小節(jié)。

I、 如果 TLS 握手成功了，接收實體必須（MUST） 丟棄TLS 生效之前從初始化實體得到的任何不可靠的信息

J、 如果 TLS 握手成功了，初始化實體必須（MUST） 丟棄TLS 生效之前從接收實體得到的任何不可靠的信息

K、 如果 TLS 握手成功了，接收實體不能(MUST NOT)在流重新開始的時候通過提供其他的流特性來向初始化實體提供 STARTTLS 擴展

L、 如果 TLS 握手成功了，初始化實體必須(MUST)繼續(xù)進行SASL握手

M、 如果 TLS 握手失敗了，接收實體必須（MUST）終止XML流和相應的TCP連接。

N、 關于必須（MUST）支持的機制，參照 Mandatory-to-Implement Technologies (第十四章第七節(jié)) 。

2、當一個初始化實體用TLS保護一個和接收實體之間的流，其步驟如下:

A. 初始化實體打開一個TCP連接，發(fā)送一個打開的XML流頭信息（其'version'屬性設置為"1.0"）給接收實體以初始化一個流。

B. 接收實體打開一個TCP連接，發(fā)送一個XML流頭信息（其'version'屬性設置為"1.0"）給初始化實體作為應答。

C. 接收實體向初始化實體提議STARTTLS范圍（包括其他支持的流特性），如果TLS對于和接收實體交互是必需的，它應該（SHOULD）在<starttls/>元素中包含子元素<required/>

D. 初始化實體發(fā)出STARTTLS命令(例如, 一個符合'urn:ietf:params:xml:ns:xmpp-tls'名字空間的 <starttls/> 元素) 以通知接收實體它希望開始一個TLS握手來保護流。

E. 接收實體必須（MUST）以'urn:ietf:params:xml:ns:xmpp-tls'名字空間中的<proceed/>元素或<failure/>元素應答。如果失敗，接收實體必須（MUST）終止XML流和相應的TCP連接。如果繼續(xù)進行，接收實體必須（MUST）嘗試通過TCP連接完成TLS握手并且在TLS握手完成之前不能（MUST NOT）發(fā)送任何其他XML數(shù)據(jù)。

F. 初始化實體和接收實體嘗試完成TLS握手。（要符合[TLS]規(guī)范）

G. 如果 TLS 握手不成功, 接收實體必須（MUST）終止 TCP 連接. 如果 TLS 握手成功, 初始化實體必須（MUST）發(fā)送給接收實體一個打開的XML流頭信息來初始化一個新的流（先發(fā)送一個關閉標簽</stream>是不必要的,因為接收實體和初始化實體必須(MUST)確保原來的流在TLS握手成功之后被關閉） 。

H. 在從初始化實體收到新的流頭信息之后，接收實體必須（MUST）發(fā)送一個新的XML流頭信息給初始化實體作為應答，其中應包含可用的特性但不包含STATRTTLS特性。

版權所有，歡迎轉載，轉載請注明出處，謝謝