XMPP的優點和不足
3月份剛換了工作，入職之後新東家讓我負責IM SDK的維護和重構工作。想起8年前曾經也搞過一段時間IM，當時是基於XMPP協議做的二次開發。時間又過了將近十年，時代在發展，技術在進步，如今可以考慮重新研究一下xmpp協議，畢竟這是唯一開源的IM協議，它山之石可以攻玉。
XMPP的特點
閒言少敘，書歸正傳，我們先來看看xmpp的一些基本特點。
xmpp官方對xmpp的定義是：“XMPP是一種可擴展的消息和狀態協議，是一組用於即時消息、狀態、多方聊天、語音和視頻通話、協作、輕量級中間件、內容聯合和XML數據的通用路由的開放技術。”。首先它是一個即時通訊協議，同時也是一種技術，是可擴展的，可以支持文本，語音，視頻，多方聊天等等。它的數據載體是XML——這可能是它最被詬病的一點，尤其是移動端用戶，我就是其中之一。具體原因我們後面會詳述。作爲一款開源的協議，它有如下特點：
-
開放——XMPP協議是免費的、開放的、公共的，並且易於理解；此外，多種實現以客戶機、服務器、服務器組件和代碼庫的形式存在，比如openfire(server), smack(client)，以及更多，感興趣的讀者可以訪問xmpp官網瞭解更多實現：[XMPP]（https://xmpp.org)。
-
標準-IETF已將核心XML流協議正式化爲一種經批准的即時消息和呈現技術。XMPP規範在2004年發佈爲RFC 3920和 RFC 3921，XMPP標準基金會繼續發佈許多XMPP擴展協議。2011年，對核心RFC進行了修訂，形成了最新的規範（RFC 6120、RFC 6121和RFC 7622）。
-
經驗證的——第一個Jabber/XMPP技術是由Jeremie Miller在1998年開發的，現在已經相當穩定；數百名開發人員正在開發這些技術，現在有成千上萬的XMPP服務器在互聯網上運行，數百萬人使用XMPP通過公共服務（如Google Talk和XMPP在全球各組織的部署）進行即時消息傳遞。
-
去中心化——XMPP網絡的架構類似於電子郵件；因此，任何人都可以運行自己的XMPP服務器，使個人和組織能夠控制他們的通信體驗。
-
安全——任何XMPP服務器都可以與公共網絡（例如，在公司內部網上）隔離，並且使用SASL和TLS的健壯安全性已經內置到核心XMPP規範中。此外，XMPP開發人員社區正積極致力於端到端加密，以進一步提高安全標準。
-
可擴展——利用XML的強大功能，任何人都可以在覈心協議的基礎上構建自定義功能；爲了保持互操作性，XEP系列中發佈了通用擴展，但並不是必須的，如果需要，組織可以維護自己的私有擴展。
-
靈活-除了IM之外，XMPP應用程序還包括網絡管理、內容聯合、協作工具、文件共享、遊戲、遠程系統監控、web服務、輕量級中間件、雲計算等。可以看出，XMPP這些年也有了很大的發展，從傳統的IM協議，已經燕延伸到了雲計算領域。
-
多樣性——許多公司和開源項目使用XMPP來構建和部署實時應用程序和服務。這些公司和開源項目爲XMPP的發展多做出了貢獻，這其中可能就包括你我。
以上列舉了很多XMPP的好處，下面，我們再來看看XMPP的有哪些短處呢？
-
XML低效
這在前邊兒已經簡單提過了，應該是XMPP最爲人詬病的一點。XMPP裏所有的報文都是XML, 在XMPP裏稱爲Stanza, XML可讀性可擴展性都很好, 但數據冗餘較大, 相同大小的報文能承載的有效數據量較少。這一點使其尤其不適應移動端應用。那麼不用XML用什麼呢? 其實有很多選擇, 基於文本的有JSON, 基於二進制的有protobuf, MQTT等. 如果希望保密, 可以定義私有的PDU。protobuf是google提供的一個開源序列化框架, 類似於XML/JSON這樣的數據表示語言, 但是基於二進制, 因此protobuf比XML/JSON都高效短小得多. 雖然是二進制數據格式, 但protobuf仍然具有非常好的擴展性和兼容性。 -
f登錄步驟太多
XMPP的標準登錄流程有如下交互:
TCP連接
1.1 SRV lookup
1.2 DNS to IP address
1.3 建立TCP連接 - 3步握手建立連接
Open Stream
2.1 Client要求open stream
2.2 Server返回stream響應
2.3 Server返回stream:features
TLS協商
3.1 Client開始starttls
3.2 Server返回proceed
3.3 建立TLS連接 - 4步握手(client hello, server hello, client key exchange, finish)
3.4 重走步驟2裏的3步
SASL
4.1 Client發送認證信息
4.2 Server返回認證成功
4.3 重走步驟2裏的3步
Resource binding
5.1 Client發送要求resource binding
5.2 Server返回綁定成功
Create session
6.1 Client發送要求創建session
6.2 Server返回成功
登錄步驟之所以這麼多, 一個原因是XMPP先構建於TCP之上, 然後再建立TLS連接, 而不是直接構建於TLS-over-TCP之上, 另一個原因是爲了保證XML streaming的邏輯完整性。
如果使用自有協議, 一個最精簡的登錄過程可以只需要1.1, 1.2, 1.3, 3.3, 4.1, 4.2, 可以大大減少登錄步驟, 差不多可以減少15次左右的TCP交互, 假設一次TCP的RTT爲200ms, 那麼就可以差不多節省3秒, 實際應用中手機網絡更差的話, 需要的時間可能會更多. 尤其是手機經常斷網或前後臺切換的話, 快速登錄或快速resume就非常有必要了。 -
每次登錄後請求roster list
如果你的roster list超過幾百人, 對應的XML就會比較大, 每次登錄後都要獲取完整roster list的話會非常影響性能。 -
複雜的presence
XMPP是有Presence的, TCP長連接的狀態決定了Client是否在線, 爲了避免假連接, 頻繁掉線重連干擾用戶體驗等, 需要維護好TCP的長連接, 定時heartbeat, 要有斷網重連機制(用戶無感知)等等。
另外, XMPP裏的Presence業務邏輯也比較複雜, 包括RFC 6121裏的Basic Presence, 還有MUC presence, Temp Presence等, 爲了實現Presence, Client和Server都增加了非常多的複雜度。對於mobile-first的IM產品, 都是假設用戶時刻available的, 對於用戶來說最重要的是聊天列表, 傳統IM的Presence並不重要, 譬如微信就沒有Presence。 -
後臺數據交互消耗電量
手機app進入後臺後, 如果有機會保持TCP長連接, 這時與Server之間的數據交互仍然保持不變的話, 大量的數據交互會很快消耗手機電量。
以上對XMPP做了簡單的概述。XMPP因爲自身的開放，保準，可擴展，靈活等特性，吸引了不少的用戶，也使自身一直得到了持續的發展。但是因爲協議本身以及數據載體（XML）的限制，使其在性能和效率方面不是盡如人意，在移動端尤其明顯。大家可以根據自身的需要做取捨，選擇XMPP或者其它方案，或者對XMPP進行裁剪，優化，畢竟，它是開放的，這是它的最大優勢。