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

什么是OpenFire

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

　　您可以使用它輕易的構(gòu)建高效率的即時(shí)通信服務(wù)器。Openfire安裝和使用都非常簡(jiǎn)單，并利用Web進(jìn)行管理。單臺(tái)服務(wù)器可支持上萬(wàn)并發(fā)用戶。

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

XMPP（Jabber）協(xié)議

1、 介紹

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

2、 定義：

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

XMPP的前身是Jabber， 一個(gè)開(kāi)源形式組織產(chǎn)生的網(wǎng)絡(luò)即時(shí)通信協(xié)議。XMPP目前被IETF國(guó)際標(biāo)準(zhǔn)組織完成了標(biāo)準(zhǔn)化工作。標(biāo)準(zhǔn)化的核心結(jié)果分為兩部分；

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

基于XML FreeEIM流傳輸?shù)募磿r(shí)通訊擴(kuò)展應(yīng)用

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

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

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

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

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

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

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

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

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

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

主要的XMPP 協(xié)議范本及當(dāng)今應(yīng)用很廣的XMPP 擴(kuò)展：

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

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

l XEP-0030 服務(wù)搜索。一個(gè)強(qiáng)大的用來(lái)測(cè)定XMPP 網(wǎng)絡(luò)中的其它實(shí)體所支持特性的協(xié)議。

l XEP-0115 實(shí)體性能。XEP-0030 的一個(gè)通過(guò)即時(shí)出席的定制，可以實(shí)時(shí)改變交變廣告功能。

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

l XEP-0096 文件傳輸。定義了從一個(gè)XMPP 實(shí)體到另一個(gè)的文件傳輸。

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

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

l XEP-0167 Jingle Audio Content Description Format。定義了從一個(gè)XMPP 實(shí)體到另一個(gè)的語(yǔ)音傳輸過(guò)程。

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

l XEP-0177 Jingle Raw UDP Transport。純UDP 傳輸機(jī)制，文件講述了如何在沒(méi)有防火墻且在同一網(wǎng)絡(luò)下建立連接的。

l XEP-0180 Jingle Video Content Description Format。定義了從一個(gè)XMPP 實(shí)體到另一個(gè)的視頻傳輸過(guò)程。

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

l XEP-0183 Jingle Telepathy Transport Method。

5、 XMPP協(xié)議網(wǎng)絡(luò)架構(gòu)

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

(1) 點(diǎn)連接到服務(wù)器；

(2) 務(wù)器利用本地目錄系統(tǒng)中的證書對(duì)其認(rèn)證；

(3) 點(diǎn)指定目標(biāo)地址，讓服務(wù)器告知目標(biāo)狀態(tài)；

(4) 務(wù)器查找、連接并進(jìn)行相互認(rèn)證；

(5) 點(diǎn)之間進(jìn)行交互；

6、 XMPP客戶端

XMPP 系統(tǒng)的一個(gè)設(shè)計(jì)標(biāo)準(zhǔn)是必須支持簡(jiǎn)單的客戶端。事實(shí)上，XMPP 系統(tǒng)架構(gòu)對(duì)客戶端只有很少的幾個(gè)限制。一個(gè)XMPP 客戶端必須支持的功能有：

1. 通過(guò) TCP 套接字與XMPP 服務(wù)器進(jìn)行通信；

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

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

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

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

RFC3920 核心協(xié)議Core

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

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

XEP-0115 實(shí)體能力Entity Capabilities

7、 XMPP服務(wù)器

XMPP 服務(wù)器遵循兩個(gè)主要法則：

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

2、與其他 XMPP 服務(wù)器通信；

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

基本的XMPP 服務(wù)器必須實(shí)現(xiàn)以下標(biāo)準(zhǔn)協(xié)議

RFC3920 核心協(xié)議Core

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

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

8、 XMPP網(wǎng)關(guān)

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

9、 XMPP地址格式

一個(gè)實(shí)體在XMPP網(wǎng)絡(luò)結(jié)構(gòu)中被稱為一個(gè)接點(diǎn)，它有唯一的標(biāo)示符jabber identifier(JID)，即實(shí)體地址，用來(lái)表示一個(gè)Jabber用戶，但是也可以表示其他內(nèi)容，例如一個(gè)聊天室．一個(gè)有效的JID包括一系列元素：

(1) 名(domain identifier)；

(2) 點(diǎn)(node identifier)；

(3) 源(resource identifier)．

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

10、 XMPP消息格式

XMPP中定義了3個(gè)頂層X(jué)ML元素: Message、Presence、IQ，下面針對(duì)這三種元素進(jìn)行介紹。

<Message>

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

To : 標(biāo)識(shí)消息的接收方。

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

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

結(jié)構(gòu)如下所示:

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

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

</message>

<Presence>

用來(lái)表明用戶的狀態(tài)，如：online、away、dnd(請(qǐng)勿打擾)等。當(dāng)用戶離線或改變自己的狀態(tài)時(shí)，就會(huì)在stream的上下文中插入一個(gè)Presence元素，來(lái)表明自身的狀態(tài)．結(jié)構(gòu)如下所示：

<presence>

From =‘lily @ jabber.com/contact’

To = ‘yaoman @ jabber.com/contact'

<status> Online </status>

</presence>

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

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

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

< IQ >

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

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

Get :獲取當(dāng)前域值。

Set :設(shè)置或替換get查詢的值。

Result :說(shuō)明成功的響應(yīng)了先前的查詢。

Error: 查詢和響應(yīng)中出現(xiàn)的錯(cuò)誤。

結(jié)構(gòu)如下所示:

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

XMPP通信協(xié)議

一、 Stream

<!-- #################### 通信內(nèi)容采用壓縮技術(shù)，以及通信的相關(guān)協(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 客戶端的地址（來(lái)源）

id

lang 通信語(yǔ)言

-->        

<stream:features>

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

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

    <!-- 加密技術(shù)、安全證書 -->

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

        <mechanism>DIGEST-MD5</mechanism>

        <mechanism>PLAIN</mechanism>

        <mechanism>ANONYMOUS</mechanism>

        <mechanism>CRAM-MD5</mechanism>

    </mechanisms>

    <!-- 采用壓縮技術(shù) -->

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

        <method>zlib</method>

    </compression>

    <!-- 權(quán)限 -->

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

    <!-- 注冊(cè) -->

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

</stream:features>

關(guān)于TSL 參考：http://www.jabbercn.org/RFC3920

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、當(dāng)一個(gè)初始化實(shí)體用TLS保護(hù)一個(gè)和接收實(shí)體之間的流，其步驟如下:

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

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

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

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

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

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

G. 如果 TLS 握手不成功, 接收實(shí)體必須（MUST）終止 TCP 連接. 如果 TLS 握手成功, 初始化實(shí)體必須（MUST）發(fā)送給接收實(shí)體一個(gè)打開(kāi)的XML流頭信息來(lái)初始化一個(gè)新的流（先發(fā)送一個(gè)關(guān)閉標(biāo)簽</stream>是不必要的,因?yàn)榻邮諏?shí)體和初始化實(shí)體必須(MUST)確保原來(lái)的流在TLS握手成功之后被關(guān)閉） 。

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

版權(quán)所有，歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)注明出處，謝謝