物聯網（internet of things，iot）最近**率越來越高。雖然http是網頁的事實標準，不過機器之間（machine-to-machine，m2m）的大規模溝通需要不同的模式：之前的請求/回答（request/response）模式不再合適，取而代之的是發布/訂閱（publish/subscribe）模式。這就是輕量級、可擴充套件的mqtt（message queuing telemetry transport）可以施展拳腳的舞台
因為是m2m，需要考慮：
（1）machine，或者叫裝置，比如溫度感測器，硬體能力很弱，協議要考慮盡量小的資源消耗，比如計算能力和儲存等
（2）m2m可能是無線連線，網路不穩定，頻寬也比較小
mqtt是基於二進位制訊息的發布/訂閱程式設計模式的訊息協議，最早由ibm提出的，如今已經成為oasis規範。由於規範很簡單，非常適合需要低功耗和網路頻寬有限的iot場景，比如：
mqtt協議的架構，用乙個示例說明。比如有1個溫度感測器（1個machine），2個小的顯示屏（2個machine)，顯示屏要顯示溫度感測器的溫度值。
顯示器需要先通過mqtt協議subscribe（訂閱）乙個比如叫temperature的topic（主題）：
當溫度感測器publish（發布）溫度資料，顯示器就可以收到了:
協議裡還有2個主要的角色：
client，客戶端
broker，伺服器端
它們是通過tcp/ip協議連線的。
因為mqtt是協議，所以不能拿來直接用的，就好比http協議一樣。需要找實現這個協議的庫或者伺服器來執行。
emqtt
mosquitto
協議詳解
協議規範：mqtt v3.1 protocol specification (
qos在mqtt中有（摘自mq 遙測傳輸 (mqtt) v3.1 協議規範）：
「至多一次」，訊息發布完全依賴底層 tcp/ip 網路。會發生訊息丟失或重複。這一級別可用於如下情況，環境感測器資料，丟失一次讀記錄無所謂，因為不久後還會有第二次傳送。
「至少一次」，確保訊息到達，但訊息重複可能會發生。
「只有一次」，確保訊息到達一次。這一級別可用於如下情況，在計費系統中，訊息重複或丟失會導致不正確的結果。
接收離線訊息的客戶端
客戶端訂閱設定qos=1
客戶端連線屬性clean: false，作用是斷開連線重連的時候伺服器端幫助恢復session，不需要再次訂閱
收到訊息的順序是亂的，為什麼會這樣，其實很好理解，為了小型受限裝置以及網路不穩定的情況，訊息是不好保證順序的。
解決辦法是傳送的訊息帶時間戳，接收後再做排序。
另外，擔心客戶端沒有做client.end()而非正常退出，那麼再次連線是否能恢復session，測試了一下，注釋client.end()，沒有問題，正常收到多條離線訊息。
ssh連線
協議實現
問題：server怎麼處理終端的重複訂閱？
MQTT協議 MQTT協議解析
協議就是通訊雙方的乙個約定，即，表示第1位傳輸的什麼 第2位傳輸的什麼 在mqtt協議中，乙個mqtt資料報由 固定頭 fixed header 可變頭 variable header 訊息體 payload 三部分構成。mqtt 資料報結構 固定頭存在於所有mqtt資料報中，其結構如下 bit76...
MQTT 協議解析
wireshark安裝包 網路抓包工具 qmqtt原始碼 mqtt客戶端原始碼 qt版本 官網 英文版協議說明文件 中文版協議說明文件 1.1幀結構 fixed header,present in all mqtt control packets variable header,present in...
Mqtt協議基本介紹
mqtt協議基本介紹 簡介mqtt message queuing telemetry transport，訊息佇列遙測傳輸協議 是一種基於發布 訂閱 publish subscribe 模式的 輕量級 通訊協議，該協議構建於tcp ip協議上，由ibm在1999年發布。mqtt最大優點在於，可以以...