海鑫智聖：物聯網漫談之MQTT協議

什麼是MQTT協議

　　MQTT（消息隊列遙測傳輸協議）是IBM在1999年專門針對物聯網等應用場景來制訂的輕量級雙向消息傳輸協議，它主要是爲了解決物聯網上使用到的設備的互相通訊的問題，以及這些設備與後端應用系統之間通訊的問題。

爲何須要MQTT（或相似）協議

　　隨着智能硬件和移動互聯網技術的快速發展，傳統的互聯網協議愈來愈難以知足物聯網的須要，體如今：移動網絡代價昂貴，帶寬低、可靠性差；在嵌入設備中運行，處理器和內存資源有限；海量在線設備產生龐大數據，給雲端帶來很大的網絡開銷和處理壓力。

MQTT如何工做

　　MQTT包括客戶端、代理（broker）兩部分，以智能家居系統爲例，末端智能電器與手機爲客戶端，雲中心爲代理。客戶端首先向代理髮起請求，代理收到後對客戶端認證，認證經過後在客戶端與代理之間創建一個TCP長鏈接通道，客戶端經過該通道訂閱若干關注的主題（Topic），同時在自身狀態變化時，向相應的主題發佈消息，代理將該消息發給正在訂閱該主題的全部客戶端，以下圖。與HTTP不一樣，MQTT是一種多對多的通訊協議，設備直接不直接相連，而是經過一個代理實現互相通訊。它是一種自然的異步協議，能夠很好地將請求端與響應端解耦。

MQTT協議有什麼好處

　　MQTT針對物聯網場景優化設計，考慮了網絡的可達性，消息的連通性，能耗等方面。具體來說：

　　一是它自己是特別輕量級的，使用一個8位的系統、30K的空間，就能夠運行MQTT的客戶端。

　　二是它針對不穩定網絡而設計，一般意義上的傳輸協議都是基於穩定網絡的傳輸的，會專門爲了這種穩定的網絡去作一些優化。MQTT正好相反，協議較多地考慮了網絡的不肯定性，它自己還很是精簡，最小的傳輸字節只有兩個，使得在較惡劣的網絡條件下仍然有較好的消息可達率。

　　三是它的消息的交互模式跟傳統意義上不太同樣，它採用了發佈和訂閱的模式。當數據源發佈一條消息的時候，能夠有多個訂閱端同時能收到這個消息，這對於不少設備互聯的物聯網場景比較靈活。

　　四是有消息發佈服務質量（QoS）機制，用戶可根據應用場景須要，選擇「至多一次」、「至少一次」或「只有一次」的傳輸質量，在效率與質量之間進行權衡。

　　五是客戶端異常中斷的通知機制（Last-Will-And-Testament）。當一個設備連不上的時候，服務器端有一個專門的機制能立刻知道這個設備出了什麼情況，從而能夠很是快的反饋，對某一個結點作出一些補償。

MQTT取得了哪些成功實踐

　　1.物聯網雲

　　Evothings:國外物聯網生態平臺，提供全套的軟硬件開發工具，幫助開發者構建智能硬件原型、開發消息推送服務。

　　Yeelink:國內最大的物聯網雲平臺之一，爲用戶和智能硬件開發者提供傳感器雲服務，並經過實時數據處理, 實現可靠的狀態監控。

　　2.實時消息推送

　　Facebook是較早大規模採用MQTT 協議的互聯網巨頭，其在移動客戶端中使用MQTT來更新通知、消息和書籤等。

　　雲吧等平臺藉助MQTT 協議提供實時消息服務，實時推送消息到任意設備、快速的給上百萬用戶發送消息，實現單臺設備一對一推送，實時展現在線用戶、使用狀況。目前在爲幾萬開發者、上億終端提供推送服務。國內搜狐等企業也使用了MQTT做爲Android手機客戶端與服務器端推送消息的協議。

MQTT還有哪些問題

　　1.在網絡變化頻繁或者不太穩定的2G/3G網絡環境下表現不佳。

　　客戶端在每次TCP斷開或斷網後，會即刻發起TCP重連，鏈接成功後依次發送CONNECT命令、訂閱SUBSCRIBLE命令，當網絡頻繁切換或者不太穩定時，上述機制必定程度上加劇已經不堪的弱網絡負擔。一些參考資源指出在業務層面進行重連策略、等待超時等調整可優化該問題。此外，CoAP等其餘基於UDP傳輸的物聯網協議對這類網絡具備更好的適應性。

　　2.針對沒有TCP/IP支持的終端環境MQTT沒法應用。

　　能夠採用MQTT-SN（MQTT For Sensor Networks）協議進行補充，它是爲了很是受限相似傳感器設計的，可以基於IEEE 802.15.4等無線局域網發送UDP數據包，再經過MQTT-SN網關與MQTT broker創建鏈接。流程架構大體以下：

MQTT推薦資源

　　Mosca：基於Nodejs實現的一款功能較完善的broker

　　Paho: C/C++、Python、Java等語言的MQTT 客戶端庫

　　mosquitto：一款功能完善的開源原生broker