XMPP 核心協議 xmpp.org/rfcs/rfc392…
XMPP 要點.
第壹步: 打開 stream
Client: 客戶端發送打開 stream 的片段到服務器, 請求壹個新的 session.
這裏 “example.com” 是客戶端試圖連接的服務器的域名.
Server: Server 返回 XML stream, 以stream:freatures 開頭, 包含要求 TLS 或者 SASL 協商談判之壹, 或者2個都要求.
第二步: 加密和認證.
2.1 如果服務器需要 TLS 交涉.
Client: 客戶端發送 STARTTLS 到服務器.
Server: 服務器返回消息顯示 TLS 已被允許:
或者 TLS失敗了:
在失敗的情況下, 服務器會關閉 TCP 連接.
Client: 如果 TLS 已被服務器正確處理, 客戶端發送請求壹個新的 session:
Server: 服務器響應壹個 XML stream, 指示是否需要 SASL 交涉.
2.2 SASL 交涉
Client 客戶端需要選擇壹個服務器上有效的認證方式來攜帶SASL交涉數據, 上面的情況, “DIGEST-MD5“, “PLAIN” 和 “EXTERNAL” 是壹些可選項.
“PLAIN” 認證模式是三者之中最簡單的了. 它是這樣工作的:
Client: 客戶端按照自己選擇的認證模式發送壹個將用戶名和密碼以base64編碼的 stream. 用戶名和密碼按這種格式組織:
例如我想以用戶名為“ mbed@ceit.org ”登錄, 密碼是“mirror”. 那麽, 在進行base64編碼之前, 用戶名和密碼按照上面的格式組織為壹個新的字符串,“\0mbed\0mirror”, 再進行base64編碼, 得到字符串“AG1iZWQAbWlycm9y”.
然後, 客戶端發送下列 stream 到服務器.
Server: 如果服務器接受了認證信息, 服務器會發回 帶 “success” 標簽的 stream.
或者:
Server: 如果密碼和用戶名不匹配, 或者上面的base64編碼有錯誤, 服務器發回錯誤信息的 stream.
“DIGEST-MD5” 認證模式的具體方法可以在這裏找到: www.ietf.org/rfc/rfc2831… .
第三步: 資源綁定(可選)
Client: 客戶端要求服務器綁定壹個資源(可以理解為客戶端的類型, 比如電腦, 手機, Web應用等):
或者
Client: 客戶端自己綁定壹個資源:
Server: 服務器發回另外壹個片段, 如果“type” 標簽的內容是“result”, 說明綁定是成功的, 否則說明綁定失敗.
第四步: 請求壹個新的session
在 SASL 交涉完成之後或者可選資源綁定之後, 客戶端必須建立壹個 session 來開始即時消息發送和接收.
Client: 客戶端向服務器發送請求:
Server: 服務器發回壹個 片段表明 session 是否成功創建.
創建成功的消息類似於:
如果服務器未能創建 session, 服務器將會回復壹個如下消息或者其他類型的錯誤消息.
第五步: 客戶端和服務器交換 XMPP 片段
如果以上步驟均成功完成, 那麽客戶端就可以發送 XMPP 片段到服務器和接收 XML stream了.
客戶端可以發送 片段來向服務器請求 roster 或者其他信息. 並可以使用 片段來改變客戶端的 presence 狀態(比如在線, 離開等)
即時消息和其他的負載可以通過發送 片段來完成.
第六步: 關閉 stream
最後, 如果客戶端想要結束聊天和關閉 XMPP session, 客戶端需要發送壹個關閉 stream的片段到服務器.
然後, 服務器將會改變客戶端的 presence 狀態為 “Offline” , 並且關閉 和客戶端的 TCP 連接.