關于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的應用具有超強的可擴展性。經(jīng)過擴展以后的XMPP可以通過發(fā)送擴展的信息來處理用戶的需求，以及在XMPP的頂端建立如內容發(fā)布系統(tǒng)和基于地址的服務等應用程 序。而且，XMPP包含了針對服務器端的軟件協(xié)議，使之能與另一個進行通話，這使得開發(fā)者更容易建立客戶應用程序或給一個配好系統(tǒng)添加功能。

2、 定義：

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

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

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

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

XMPP的核心XML流傳輸協(xié)議的定義使得XMPP能夠在一個比以往網(wǎng)絡通信協(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 已經(jīng)發(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ù)以極高的效率傳送給最合適的資源?；赬ML 建立起來的應用具有良好的語義完整性和擴展性。

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

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

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

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

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

l RFC 3920 XMPP（新的RFC6120）：核心。定義了XMPP 協(xié)議框架下應用的網(wǎng)絡架構，引入了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 網(wǎng)絡中的其它實體所支持特性的協(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 傳輸機制，文件講述了如何在沒有防火墻且在同一網(wǎng)絡下建立連接的。

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é)議網(wǎng)絡架構

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

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

RFC3920 核心協(xié)議Core

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

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

8、 XMPP網(wǎng)關

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

9、 XMPP地址格式

一個實體在XMPP網(wǎng)絡結構中被稱為一個接點，它有唯一的標示符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主機名已經(jīng)被解析，通信不能（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特性。

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