以前大多數im都使用私有協議, 後來發展出開放的xmpp, 使用xml通訊, 不用說消耗網路資源太大了。
我本來想使用protobuf自定義一套私有協議，但想到工作量還是太大，然後發現現在mqtt協議很熱門，特別是物聯網使用比較多，不過也可以用來做im訊息推送伺服器。
暫時還用不著改mosquitto**，直接安裝可執行程式就行。
mac下:
brew install mosquitto
mosquitto
brew info mosquitto
發現可執行檔案在usr/local/cellar/mosquitto/1.4.14_2/sbin/mosquitto
brew安裝的mosquitto不支援websocket，要想支援需要自己編譯。
qos level 0：至多一次
qos level 1：至少一次，有可能重複
也就是說伺服器給你重試**，直到伺服器收到客戶端的確認訊息。
確保至少向客戶端傳送一次資訊，不過也可傳送多次；在接收資料報時，需要客戶端返回確認訊息（ack 包）。這種方式常用於傳遞確保交付的資訊，但開發人員必須確保其系統可以處理重複的資料報。
這個可以用在普通文字聊天， 接收方離線後，伺服器自動快取訊息，等接收方上線時伺服器馬上把訊息推送給他，就算是接收方重複收包也沒關係因為可以通過訊息裡包含的時間來過濾掉。這個級別的訊息伺服器得注意限制傳送方的訊息大小和數量，免得伺服器記憶體被爆掉。
qos level 2：只有一次，確保訊息只到達一次
伺服器保證你肯定能收到一次，而且只有一次。
這個用在訊息重要性比較嚴格的場合。im在一般情況下用不著，或者在使用者發生金錢消費有關的情況下可以使用？
可以參考：利用訊息佇列mqtt，打造一款屬於自己的im社交軟體
一文讀懂mqtt協議
主題的設計應該是系統的核心，（可參考mqtt part 5 主題和最佳實踐，順便可以看看這個blog的mqtt文章。）
每個主題必須包含至少乙個位元組，並且它還可以包含空格。 另外，主題是區分大小寫的，這使得myhome/temperature和myhome/temperature是兩個單獨的主題。除此之外，單獨的正斜線也是有效的主題。
主題是utf8字串，太長的主題會占用較多的網路資源，我想真正專案中對於網路流量比較敏感時應該對主題名字做優化，使用超短的字元，比如每層都只用乙個字元來表示。為了提高可讀性，平常**都使用有意義的長字元，內部使用定義message type的方式把每層對映到1個位元組，這樣保持可讀性又大大縮短主題名字的長度，減小占用網路流量。
只取ascii表128來對映層名，去除33個控制字元和mqtt的保留字元：/, #, +以外，還有92個字元可以使用，可以再去掉一些符號比如空格、正斜桿，星號等，應該還是可以滿足需求了，如果不夠就再加乙個字元唄。
當然對於動態名比如使用者id之類的還是得用原本字串而不能使用對映。
mosquitto-auth-plug
mosquitto鑑權外掛程式的開發與說明（一）
談如何選擇IM通訊系統協議
了解完需求，開始做方案設計，最開始面臨的選擇之一，需要使用什麼樣的基礎協議。im系統也是一樣，市面上可以被用來開發im通訊系統的協議還是比較多。這裡我先一一枚舉下 sip 私有rpc 一般採用tcp協議，高層的協議需要自己定義，包括公用的協議頭部分和資料部分，優點 是能根據業務場景進行協議定製，做到...
IM同步協議
同步協議的設計就是業務契約的設計，本質就是client和server雙方就同步的資訊範圍達成一致。同乙個事物，存在不同的演化路線。從事物最初狀態開始，不同的演化路線導致同一時間點事物狀態不一樣。給所有不同演化路線上的事物狀態同一時間點確定乙個共同狀態的過程，就叫同步。im同步是給im使用者進行的資訊...
IM通訊相關協議調研
目前常用的傳輸層協議中有tcp與udp 早期的im因為服務端資源 伺服器硬體 網路頻寬等 比較昂貴且沒有更好的辦法來分擔效能負載，所以很多時候會考慮使用udp，這其中主要是早期的qq為代表。目前基於tcp且可用於即時通訊的應用層協議有http，xmpp，websocket協議。http僅支援客戶端向...