了解完需求，開始做方案設計，最開始面臨的選擇之一，需要使用什麼樣的基礎協議。im系統也是一樣，市面上可以被用來開發im通訊系統的協議還是比較多。這裡我先一一枚舉下：
sip：
私有rpc：
一般採用tcp協議，高層的協議需要自己定義，包括公用的協議頭部分和資料部分，
優點：是能根據業務場景進行協議定製，做到節省流量，減少互動次數。
xmpp:
優點：業界使用很廣的協議，有大量的開源實現，能幫助快速的開發高質量的應用。
缺點：這個協議因為是基於xml的，所以對於流量損耗和網路頻寬的要求還是比較高，所以他一直被用於pc電腦的上im應用上面。
symcml:
乙個簡單、通用的可以用於工業界方面的資料同步協議。使用了該款協議的有foxmail，
優點：對於多裝置同時使用，能給與很好的支援。
缺點：協議本身就比較複雜，互動流程比較多，使用者流量消耗比較大。不過基於該協議思想改進後的效果還是很好的，如wechat，foxmail
mqtt:
ibm提出一種輕量級的，適合於低頻寬、不可靠連線、嵌入式裝置、cpu、記憶體資源緊張，適用於各種受限的環境的傳輸協議。最早使用於心臟起搏器的質量狀態監控上。
優點：有明確定義服務質量，對於不同的質量有不同互動流程要求。
包體流量占用小，對於每個位元組都有精確的定義。
有大量的開源實現，能幫助快速的開發高質量的應用。
缺點：協議本身不是基於im業務設計的，一款基於二進位制的協議，對於位元組定義缺乏可擴充套件性，有時需要你在產品需求和標準協議實現上做出一些權衡。
比如：publish應答不能帶payload，如果想通過應答獲得該條訊息的系統時間，得想其他的辦法。
總結：
IM 協議選擇 MQTT（mosquitto）
以前大多數im都使用私有協議,後來發展出開放的xmpp,使用xml通訊,不用說消耗網路資源太大了。我本來想使用protobuf自定義一套私有協議，但想到工作量還是太大，然後發現現在mqtt協議很熱門，特別是物聯網使用比較多，不過也可以用來做im訊息推送伺服器。暫時還用不著改mosquitto 直接安...
IM通訊相關協議調研
目前常用的傳輸層協議中有tcp與udp 早期的im因為服務端資源 伺服器硬體 網路頻寬等 比較昂貴且沒有更好的辦法來分擔效能負載，所以很多時候會考慮使用udp，這其中主要是早期的qq為代表。目前基於tcp且可用於即時通訊的應用層協議有http，xmpp，websocket協議。http僅支援客戶端向...
初窺IM通訊協議
s c1 c1每次想和c2通訊，先向s遞乙個申請，然後s同意，把資訊轉交c2,以後每次通訊都這樣 c2s c1 c1第一次想和c2通訊，向s遞乙個申請，s同意，告訴c1,c2,然後 c1和 c2之間建立了一條連線，可以直接通訊，無需經過s.c2第 一種，對伺服器的效能要求比較高，要求伺服器可以同時處...