android openfire 和 xmpp

標籤：

關於xmpp協議可以參考：http://www.jabbercn.org

什麼是OpenFire

Openfire 採用Java開發，開源的即時協作（RTC）伺服器基於XMPP（Jabber）協議。 

　　您可以使用它輕易的構建高效率的即時通訊伺服器。Openfire安裝和使用都非常簡單，並利用Web進行管理。單台伺服器可支援上萬並發使用者。 

由於是採用開放的XMPP協議，您可以使用各種支援XMPP協議的IM用戶端軟體登陸服務。 

XMPP（Jabber）協議

1、 介紹

XMPP是一種基於XML的協議，它繼承了在XML環境中靈活的發展性。因此，基於XMPP的應用具有超強的可擴充性。經過擴充以後的XMPP可以通過發送擴充的資訊來處理使用者的需求，以及在XMPP的頂端建立如內容發布系統和基於地址的服務等應用程 序。而且，XMPP包含了針對伺服器端的軟體協議，使之能與另一個進行通話，這使得開發人員更容易建立客戶應用程式或給一個配好系統添加功能。 

2、 定義：

XMPP（可擴充訊息處理現場協議）是基於可延伸標記語言 (XML)（XML）的協議，它用於立即訊息（IM）以及線上現場探測。它在促進伺服器之間的准即時操作。這個協議可能最終允許網際網路使用者向網際網路上的其他任何人傳送立即訊息，即使其作業系統和瀏覽器不同。 

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

核心的XML流傳輸協議 

基於XML FreeEIM流傳輸的即時通訊擴充應用 

XMPP的核心XML流傳輸協議的定義使得XMPP能夠在一個比以往網路通訊協定更規範的平台上。藉助於XML易於解析和閱讀的特性，使得XMPP的協議能夠非常漂亮。 

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

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

3、 XMPP協議的優點 

a. XMPP 協議是公開的，由JSF開源社區組織開發的。XMPP 協議並不屬於任何的機構和個人，而是屬於整個社區，這一點從根本上保證了其開放性。 

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

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

d. XMPP 具有很好的彈性。XMPP 除了可用在即時通訊的應用程式，還能用在網路管理、內容供稿、協同工具、檔案共用、遊戲、遠端系統監控等。 

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

4、 XMPP協議的組成 

主要的XMPP 協議範本及當今應用很廣的XMPP 擴充： 

l RFC 3920 XMPP（新的RFC6120）：核心。定義了XMPP 協議架構下應用的網路架構，引入了XML Stream（XML 流）與XML Stanza（XML 節），並規定XMPP 協議在通訊過程中使用的XML 標籤。使用XML 標籤從根本上說是協議開放性與擴充性的需要。此外，在通訊的安全方面，把TLS 安全傳輸機制與SASL 認證機制引入到核心，與XMPP 進行無縫的串連，為協議的安全性、可靠性奠定了基礎。Core 文檔還規定了錯誤的定義及處理、XML 的使用規範、JID（Jabber Identifier，Jabber 標識符）的定義、命名規範等等。所以這是所有基於XMPP 協議的應用都必需支援的文檔。 

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

l XEP-0030 服務搜尋。一個強大的用來測定XMPP 網路中的其它實體所支援特性的協議。 

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

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

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

l XEP-0124 HTTP 綁定。將XMPP 綁定到HTTP 而不是TCP，主要用於不能夠持久的維持與伺服器TCP 串連的裝置。 

l XEP-0166 Jingle。規定了多媒體通訊協商的整體架構。 

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協議網路架構 

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

(1) 點串連到伺服器； 

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

(3) 點指定目標地址，讓伺服器告知目標狀態； 

(4) 務器尋找、串連並進行相互認證； 

(5) 點之間進行互動； 

6、 XMPP用戶端 

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

1. 通過 TCP 通訊端與XMPP 伺服器進行通訊； 

2. 解析組織好的 XML 資訊包； 

3. 理解訊息資料類型。 

XMPP 將複雜性從用戶端轉移到伺服器端。這使得用戶端編寫變得非常容易，更新系統功能也同樣變得容易。XMPP 用戶端與服務端通過XML 在TCP 通訊端的5222 連接埠進行通訊，而不需要用戶端之間直接進行通訊。 

基本的XMPP 用戶端必須實現以下標準協議（XEP-0211）： 

RFC3920 核心協議Core 

RFC3921 立即訊息和出席協議Instant Messaging and Presence 

XEP-0030 服務發現Service Discovery 

XEP-0115 實體能力Entity Capabilities 

7、 XMPP伺服器 

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

1、監聽用戶端串連，並直接與用戶端應用程式通訊； 

2、與其他 XMPP 伺服器通訊； 

XMPP開原始伺服器一般被設計成模組化，由各個不同的程式碼封裝構成，這些程式碼封裝分別處理Session管理、使用者和伺服器之間的通訊、伺服器之間的通訊、DNS（Domain Name System）轉換、儲存使用者的個人資訊和朋友名單、保留使用者在下線時收到的資訊、使用者註冊、使用者的身份和許可權認證、根據使用者的要求過濾資訊和系統記錄等。另外，伺服器可以通過附加服務來進行擴充，如完整的安全性原則，允許伺服器組件的串連或用戶端選擇，通向其他訊息系統的網關。 

基本的XMPP 伺服器必須實現以下標準協議 

RFC3920 核心協議Core 

RFC3921 立即訊息和出席協議Instant Messaging and Presence 

XEP-0030 服務發現Service Discovery 

8、 XMPP網關 

XMPP 突出的特點是可以和其他即時通訊系統交換資訊和使用者線上狀況。由於協議不同，XMPP 和其他系統交換資訊必須通過協議的轉換來實現，目前幾種主流即時通訊協定都沒有公開，所以XMPP 伺服器本身並沒有實現和其他協議的轉換，但它的架構允許轉換的實現。實現這個特殊功能的服務端在XMPP 架構裡叫做網關(gateway)。目前，XMPP 實現了和AIM、ICQ、IRC、MSN Massager、RSS0.9 和Yahoo Massager 的協議轉換。由於網關的存在，XMPP 架構事實上相容所有其他即時通訊網路，這無疑大大提高了XMPP 的靈活性和可擴充性。 

9、 XMPP地址格式 

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

(1) 名(domain identifier)； 

(2) 點(node identifier)； 

(3) 源(resource identifier)． 

它的格式是[email protected]/resource，[email protected]，類似電子郵件的地址格式．domain用來表示接點不同的裝置或位置，這個是可選的，例如a在Server1上註冊了一個使用者，使用者名稱為doom，那麼a的JID就是[email protected]，在發送訊息時，指明[email protected]就可以了，resource可以不用指定，但a在登入到這個Server時，fl的JID可能是[email protected]、exodus(如果a用Exodus軟體登入)，也可能是[email protected]/psi(如果a用psi軟體登入)．資源只用來識別屬於使用者的位置或裝置等，一個使用者可以同時以多種資源與同一個XMPP伺服器串連。 

10、 XMPP訊息格式 

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

<Message>

用於在兩個jabber使用者之間發送資訊。Jsm(jabber會話管理器)負責滿足所有的訊息，不管目標使用者的狀態如何。如果使用者線上jsm立即提交;否則jsm就儲存。 

To : 標識訊息的接收方。 

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

Text: 此元素包含了要提交給目標使用者的資訊。 

結構如下所示: 

<message to= ‘[email protected]/contact’ type =’chat’> 

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

</message> 

<Presence>

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

<presence> 

From =‘lily @ jabber.com/contact’ 

To = ‘yaoman @ jabber.com/contact‘ 

<status> Online </status> 

</presence> 

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

Probe: 用於向接受訊息方法發送特殊的請求 

subscribe: 當接受方狀態改變時，自動向發送方發送presence資訊。 

< IQ >

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

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

Get :擷取當前域值。 

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

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

Error: 查詢和響應中出現的錯誤。 

結構如下所示: 

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

XMPP通訊協定

一、 Stream

<!-- #################### 通訊內容採用壓縮技術，以及通訊的相關協議 ####################### -->

<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協議[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協議遵循以下規則：

A、 一個遵守本協議的初始化實體必須（MUST）在初始化流的頭資訊中包含一個‘version‘屬性並把值設為“1.0”。 

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

C、 當一個遵守本協議的接收實體接收了一個初始化流（它的頭資訊中包含一個‘version‘屬性並且值設為“1.0”），在發送應答流的的頭資訊（其中包含版本戳記）之後，它必鬚髮送（MUST）<starttls/>元素（名字空間為 ‘urn:ietf:params:xml:ns:xmpp-tls‘）以及其他它支援的流特性。 

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

E、 TLS握手期間,一個實體不能（MUST NOT）在流的根項目中發送任何空格符號作為元素的分隔字元（在下面的TLS樣本中的任何空格符都僅僅是為了便於閱讀）；這個禁令用來協助確保安全層位元組精度。 

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

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

H、 認證必須（MUST）檢查初始化實體(比如一個使用者)提供的主機名稱；而不是通過DNS系統解析出來的主機名稱；例如，如果使用者指定一個主機名稱"example.com"而一個DNS SRV [SRV]查詢返回"im.example.com"，認證必須（MUST）檢查"example.com".如果任何種類的XMPP實體（例如用戶端或伺服器）的JID出現在一個認證裡，它必須（MUST）表現為一個別名實體裡面的UTF8字串，存在於subjectAltName之中。如何使用 [ASN.1] 物件識別碼 "id-on-xmppAddr" 定義在本文的第五章第一節第一小節。 

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

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

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

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

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

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

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

A. 初始化實體開啟一個TCP串連，發送一個開啟的XML流頭資訊（其‘version‘屬性設定為"1.0"）給接收實體以初始化一個流。 

B. 接收實體開啟一個TCP串連，發送一個XML流頭資訊（其‘version‘屬性設定為"1.0"）給初始化實體作為應答。 

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

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

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

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

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

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

android openfire 和 xmpp