【文章內(nèi)容簡介】 體交換信息 ，接收實體必須發(fā)起一個反向的握手 (應答流 )。 ◆ XML 節(jié)是實體通過 XML 流傳輸?shù)慕Y構化信息單元 ， 在 XML 流中以深度為 1 的子標記開頭 ， 并以深度為 1 的子標記結束 ， 這些標記為 message/、 presence/和 8 iq/。 XML 節(jié)是一個實體通過 XML 流向另一個實體發(fā)送的結構化信息中的一個離散的語義單位。一個 XML 直接存在于根元素 stream/的下一級 (在 XML 流中以深度為 1 的子標記開頭 ， 并以深度為 1 的子標記結束 )， 并且如果這樣就能夠滿足 [XML]內(nèi)容的 production 43， 那么它被認為是均衡的 。 任何 XML 節(jié)都是從一個 XML 流的下一級的某個打開標簽 (如 presence)開始 ， 到相應的關閉標簽 (如 /presence)。一個 XML 節(jié)可以包含子元素 (相關的屬性 ， 元素 ， 和 XML 字符數(shù)據(jù)等 ) 以表達完整的信息 。 在這里定義的 XML 節(jié)僅限于 message/， presence/， 和 iq/ 元素；為 TLS 握手、 SASL 握手、服務器回撥的需要而發(fā)送的 XML 元素 ， 不被認為是一個 XML 節(jié)。 XML 節(jié)也可通過包含其他子元素來傳送結構化信息 ， 是實際需要交換的信息所在地 。 設想一個客戶端和服務器會話的例子。為了連接一個服 務器 ， 一個客戶端必須發(fā)送一個打開標簽 stream給服務器 ， 初始化一個 XML 流 ， 也可選擇在這之前發(fā)送一段文本聲明 XML 版本和支持的字符集 ； 也可看字符編碼。視本地化策略和提供的服務而定 ， 服務器應該回復一個 XML 流給客戶端 ， 同樣的 ， 也可選擇在這之前發(fā)送一段文本聲明。一旦客戶端完成了 SASL 握手 ， 客戶端可以通過流發(fā)送不限量的 XML 節(jié)給網(wǎng)絡中的任何接收者。當客戶端想關閉這個流 ， 它只需要簡單的發(fā)送一個關閉標簽 /stream給服務器 (或者作為另一個選擇 ， 可能由服務器關閉這個流 )。 如果會話中發(fā)生錯誤 ， 任何一方均可 用 ERROR 子元素予以應答。這些情況包括：數(shù)據(jù)格式不符合 XML 的形式定義、連接超時、尋址錯誤、非授權錯誤等。 然后 ， 客戶端和服務器都應該徹底地終止這個連接 (通常是一個 TCP 連接 )。 ◆ 流認證是在 XML 流中有關協(xié)商傳輸層安全協(xié)議、簡單認證與安全層協(xié)議和服務器回撥認證協(xié)議完成通信認證、加密等目的的數(shù)據(jù)交互 ， 是 XMPP 安全機制的重要組成部分。 XMPP 為 XML 流扮演通用 “ 傳輸層 ” 的角色。 XML 流中包含傳輸?shù)恼J證信息和現(xiàn)場消息 ， XMPP 能使數(shù)據(jù)高效路由至最合適的請求源 ， 并最大限度地簡化客戶機上的實現(xiàn) ， 使跨應用實時交流 信息成為可能 [11]。 為了防止會話被篡改和偷聽 ， XMPP 協(xié)議采用認證和加密的方法作為其安全機制 ， 其中認證采用 SASL[7](Simple Authentication and Security Layer)認證和回撥(Dialback)認證 ， 加密利用 TLS(Transport Layer Security)協(xié)議。另外它還設計了端到端數(shù)據(jù)加密機制作為可選的數(shù)據(jù)加密策略 ， 保證數(shù)據(jù)的可靠傳輸。 XMPP 的協(xié)議棧結構如圖 3 所示。 9 客戶端在連接服務器時 ， 如果服務器要求 ， 客戶端必須完成 TLS 協(xié)商連接才 可以繼續(xù)。協(xié)商過程如下： (1)客戶端、服務器都打開 Stream； (2)接著服務器發(fā)送 STARTTLS 擴展標簽給客戶端 (包含所支持的認證機制和任何其他流特性 )； (3)客戶端發(fā)送 STARTTLS 命令給服務器 ， 并等待進一步指示； (4)服務器回復 proceed/標簽通知客戶端可以繼續(xù)進行； (5)客戶端和服務器嘗試通過已有的 TCP 連接完成 TLS 協(xié)商； (6)如果認證成功 ， 客戶端初始化一個新的流給服務器 ， 否則服務器關閉 TCP 連接。 當 TLS 協(xié)商成功后 ， 服務器回復新的 stream給客戶端 ， 其中包含服務器 支持的認證機制列表?？蛻舳嗽诹斜碇羞x擇需要的認證機制 ， 通過 auth命令通知服務器 ， 接下來雙方就可以進行 SASL 認證了。其過程如下所示： (1)初始化通信過程 ， 客戶端和服務器都打開 Stream； (2)服務器向客戶端提供安全機制列表； (3)客戶端選擇所使用的認證機制； (4)服務器發(fā)送一次詢問信息 ， 其內(nèi)容包括服務器的部分認證參數(shù)； (5)客戶端回應服務器的詢問 ， 提交授權標識； (6)服務器通知客戶端認證成功或失敗。 XMPP 的地址空間 (1)概覽 [13] 一個實體可以是任何一個被認為是一 個網(wǎng)絡端點的東西 (例如網(wǎng)絡上的一個 ID)， 而且它是通過 XMPP 進行通信的。所有這些實體都有一個具有唯一性的地址 ， 并符合 RCF 圖 3 XMPP 協(xié)議棧結構 10 2396 [URI]規(guī)范要求的格式。由于歷史原因 ， 一個 XMPP 實體的地址被稱為 Jabber Identifier 或 JID。一個合法的 JID 包括一組排列好的元素 ， 包括域名 (domain identifier)，節(jié)點名 (node identifier)， 和資源名 (resource identifier)。 JID 的語法定義 ， 使用 [ABNF]中的 Augmented BackusNaur 格式。 (IPv4 地址和 IPv6地址規(guī)則在 RCF3920 的 附錄 B 中的 [IPv6]中定義；確定節(jié)點規(guī)則的合法字符順序由RCF3920 的 附錄 A 的 [STRINGPREP]的 Nodeprep 部分來定義；確定資源規(guī)則的合法字符順序由 RCF3920 的 附錄 B 的 [STRINGPREP]的 Resourceprep 部分來定義；子域名規(guī)則參考 [IDNA] 中關于國際域名標簽的描述 )。 所有 JID 都是基于上述的結構。類似 user@host/resource 這種結構 ， 最常用來標識一個即時消息用戶 ， 這個用戶所連接的服務器 ， 以及這個用戶用于連接的資源 (比如特定類型的客戶端軟件 )。不過 ， 節(jié)點類型不是客戶端也是有可能的 ， 比如一個用來提供多用戶聊天服務的特定的聊天室 ， 地址可以是 room@service(這里 “room”是聊天室的名字而“service”是多用戶聊天服務的主機名 )， 而加入了這個聊天室的某個特定的用戶的地址則是 room@service/nick(這里 “nick”是用戶在聊天室的昵稱 )。許多其他的 JID 類型都是可能的 (例如 domain/resource可 能是一個服務器端的腳本或服務 )。 一個 JID 的每個合法部分 (節(jié)點名 ， 域名 ， 資源名 )的長度不能超過 1023 字節(jié)。也就是整體長度 (包括 39。@39。 和 39。/39。)不能超過 3071 字節(jié)。 (2)域名 域名是一個主要的 ID 并且是 JID 中唯一必需的元素 (一個純粹的域名也是一個合法的 JID)。它通常代表網(wǎng)絡的網(wǎng)關或者 “ 主 ” 服務器 ， 其他實體通過連接它來實現(xiàn) XML 轉發(fā)和數(shù)據(jù)管理功能。然而 ， 由一個域名標識引用的實體 ， 并非總是一個服務器 ， 它也可能是一個服務器的子域地址 ， 提供額外的功能 (比如多用戶聊天服務 ， 用戶目錄 ， 或一個 到外部消息系統(tǒng)的網(wǎng)關 )。 每個服務器或者服務的域名 ， 可以是一個 IP 地址 ， 但應該是一個完全合法的域名 。一個域名 ID 必須是 [IANA]里定義的 “ 國際化域名 ” ， 并且按 RCF3920 的 [STRINGPREP]中 [NAMEPREP]profile 進行成功的字符轉換。在比較兩個域名 ID 之前 ， 服務器 和 客戶jid = [ node @ ] domain [ / resource ] domain = fqdn / addressliteral fqdn = (subdomain 1*(. subdomain)) subdomain = (internationalized domain label) addressliteral = IPv4address / IPv6address 11 端應該首先按照 Nameprep profile(定義在 [IANA]中 )來轉換每個域名的字符。 XMPP 的三個頂級元素 XMPP 定義了三種核心的 XML 節(jié)： message/、 presence/、 iq/(info/query)， 即三個頂級元素 [14]。這三個頂級元素 (XMPP 節(jié) )擁有五個共同的屬性： (1)to：表示該節(jié)的預期接收者的 JID； (2)from：表示發(fā)送者的 JID； (3)id：可選屬性 ， 用于發(fā)送實體跟蹤它所收發(fā)的節(jié)； (4)type：表示該節(jié)的目的或上下文的詳細信息 ， 依據(jù)節(jié)的類型是消息、在線性信息、還是請求 /響應信息不同 ， 取值有很大不同； (5)xml:lang：如果一個節(jié)包含用于顯示給人 (human user)看的 XML 字符數(shù)據(jù) ， 這個節(jié)應該擁有一個 xml:lang 屬性 ， 用于指明所 含 XML 字符數(shù)據(jù)的默認語言。 與 XML 流類似 ， 在 XML 節(jié)傳輸期間 ， 如果產(chǎn)生語義或應用上的錯誤 ， 任何一方都可以使用 ERROR 元素通知對方。 ◆ Message message/節(jié)是 XMPP 中的數(shù)據(jù)推送機制 ， 一般是從一個客戶端到另外一個客戶端 ，跟 Email 系統(tǒng)的消息傳遞有點相似。不過 ， 跟 Email 系統(tǒng)不同的是 ， 這種消息傳遞是非常實時的。因為 ， 通過在線性探測機制 ， 發(fā)送的一方總是能夠知道接收方是否在線并是否做好接收的準備。 在發(fā)送的時候 ， 所有的 message 節(jié)都帶有 to 屬性 ， 服務器會根據(jù)這一屬性路由其收到的 message 消息。 XMPP 中定義了五種類型的消息 ， 分別 是： normal、 chat、 groupchat、error、 headline。 另外 ， message/節(jié)可以包含以下幾個子元素 ， 分別是 ： error、 subject、 body、 thread。 在消息體中一個簡單 message 包的示例 如下頁代碼 ： ◆ Presence message from=?qhg@ ? to=?/home? id=?messageid1? threadthreadid_01/thread subjectThe message?s subject/subject bodyThe text in the message body/body /message 12 presence/節(jié)是 XMPP 中的數(shù)據(jù)廣播機制 ， 由服務器接收并向所有相關目的方進行廣播 ， 這種機制又有點類似訂閱 /發(fā)布類型的消息傳 遞。目前主要用于實現(xiàn) IM 當中的聯(lián)系人管理功能。 presence 節(jié)的 type 屬性是可選的 ， 如果省略 ， 則用來通知服務器發(fā)送者已經(jīng)在線并且可以進行通信。 presence 節(jié)中可以包含 show/、 status/、 priority/等子元素 。 Presence 包的簡單示例： ◆ iq/(Info/Query) iq/(info/query)節(jié)是 XMPP 中的數(shù)據(jù)請求與答復 (request/response)機制 ， 比較類似HTTP 的工作機制。通 過這一語義單元 ， 一個實體可以向另一實體發(fā)出請求 ， 以及接收對方的應答。 XMPP 協(xié)議針對 IQ 節(jié)制定了以下規(guī)則： (1)對于 IQ 節(jié)來說 ， id 屬性是必需的； (2)對于 IQ 節(jié)來說 ， type 屬性是必需的 ， 它的取值 如下表 1： 表 1 IQ 元素的四種狀態(tài) (3)一個接收到 get 或 set 類型的 IQ 請求的實體必須回復一個 result 或 error 類型的IQ 應答 (這個應答必須保留相關請求的 id 屬性 )； (4)一個接收到 result 或 error 類型的 IQ 節(jié)的實體不能再發(fā)送更多的 result 或 error值 描述 get 這個節(jié)是一個對信息或需求的請求 set 這個節(jié)提供需要的數(shù)據(jù) ， 設置新的值或取代現(xiàn)有的值 result 這個節(jié)是對一個成功的 get 或 set 請求的應答 error 在處理或傳遞以前發(fā)送的請求時發(fā)生了錯誤 presence from=?qhg@ ? to=? ? type=?available? statusI?m bored out of my mind， talk to me/status priority10/priority showchat/show /presence 13 類型的 IQ 應答。 IQ 元素可以用于不同的目的 ， 它們之間通過不同的命名空間來加以區(qū)分。在 XMPP協(xié)議中有許多命名空間 ， 比較常用的命名