1、MQTT的安全
由於MQTT運行於TCP層之上並以明文方式傳輸，這就相當於HTTP的明文傳輸，使用Wireshark可以完全看到MQTT發送的所有消息，消息指令一覽無遺，如圖1所示。
Wireshark抓取MQTT數據包
這樣可能會產生以下風險：
設備可能會被盜用；
客戶端和服務端的靜態數據可能是可訪問的（可能會被修改）；
協議行為可能有副作用（如計時器攻擊）；
拒絕服務攻擊；
通信可能會被攔截、修改、重定向或者泄露；
虛假控制報文注入。
作為傳輸協議，MQTT僅關注消息傳輸，提供合適的安全功能是開發者的責任。安全功能可以從三個層次來考慮——應用層、傳輸層、網絡層。
應用層：在應用層上，MQTT提供了客戶標識（Client Identifier）以及用戶名和密碼，可以在應用層驗證設備。
傳輸層：類似於HTTPS，MQTT基於TCP連接，也可以加上一層TLS，傳輸層使用TLS加密是確保安全的一個好手段，可以防止中間人攻擊。客戶端證書不但可以作為設備的身份憑證，還可以用來驗證設備。
網絡層：如果有條件的話，可以通過拉專線或者使用VPN來連接設備與MQTT代理，以提高網絡傳輸的安全性。
（1）認證
MQTT支持兩種層次的認證：
應用層：MQTT支持客戶標識、用戶名和密碼認證；
傳輸層：傳輸層可以使用TLS，除了加密通訊，還可以使用X509證書來認證設備。
（2）客戶標識
MQTT客戶端可以發送最多65535個字符作為客戶標識（Client Identifier），一般來說可以使用嵌入式芯片的MAC地址或者芯片序列號。雖然使用客戶標識來認證可能不可靠，但是在某些封閉環境或許已經足夠了。
（3）用戶名和密碼
MQTT協議支持通過CONNECT消息的username和password字段發送用戶名和密碼。
用戶名及密碼的認證使用起來非常方便，不過由於它們是以明文形式傳輸，所以使用抓包工具就可以輕易的獲取。
一般來說，使用客戶標識、用戶名和密碼已經足夠了，比如支持MQTT協議連接的OneNET雲平台，就是使用了這三個字段作為認證。如果感覺還不夠安全，還可以在傳輸層進行認證。
（4）在傳輸層認證
在傳輸層認證是這樣的：MQTT代理在TLS握手成功之后可以繼續發送客戶端的X509證書來認證設備，如果設備不合法便可以中斷連接。使用X509認證的好處是，在傳輸層就可以驗證設備的合法性，在發送CONNECT消息之前便可以阻隔非法設備的連接，以節省后續不必要的資源浪費。而且，MQTT協議運行在使用TLS時，除了提供身份認證，還可以確保消息的完整性和保密性。
（5）選擇用戶數據格式
MQTT協議只實現了傳送消息的格式，並沒有限制用戶協議需要按照一定的風格，因此在MQTT協議之上，我們需要定義一套自己的通信協議。比如說，發布者向設備發布一條打開消息，設備可以回復一個消息並攜帶返回碼，這樣的消息格式是使用二進制、字符串還是JSON格式呢？下面就簡單做個選型參考。
1）十六進制/二進制
MQTT原本就是基於二進制實現的，所以用戶協議使用二進制實現是一個不錯的選擇。雖然失去了直觀的可讀性，但可以將流量控制在非常小。其實對於單片機開發者來說十六進制並不陌生，因為單片機寄存器都是以位來操作的，芯片間通信也會使用十六進制/二進制。而對於沒有單片機開發經驗的工程師來說，十六進制/二進制可能就太原始了。
2）字符串
對單片機開發者來說，字符串也是一個選擇。比如通過串口傳輸的AT指令就是基於字符串通信的。使用字符串方便了人閱讀，但是對高級語言開發者來說，字符串依舊不是最佳選擇，恐怕鍵值對（Key-Value）才是最優形式。
3）JSON
JSON中文全稱是JavaScript對象標記語言，在這門語言中，一切都是對象。因此，任何支持的類型都可以通過JSON來表示，例如字符串、數字、對象、數組等。其語法規則是：
對象表示為鍵值對；
數據由逗號分隔；
花括號保存對象；
方括號保存數組。
JSON層次結構簡潔清晰，易於閱讀和編寫，同時也易於機器解析和生成，有效提升網絡傳輸效率。
對於單片機開發者，主流的微控制器軟件開發工具Keil有提供JSON庫，可以用於STC、STM32等微控制器開發，所以在微控制器上解析JSON不需要自己寫一個JSON解析器或者移植了。
如果實在懶得使用JSON庫生成或解析，也可以直接使用C語言中的sprintf生成JSON字符串，比如：
sprintf(buf, "{\"String\":\"%s\", \"Value\":%d}", "Hello World!", 12345);
這樣就可以生成一個{“String”:”Hello World!”, “Value”:12345}JSON字符串了。
（6）XML
MQTT協議只負責通信部分，用戶協議可以自己選擇，當然也可以選擇復雜又冗長的XML格式。可是既然要選擇MQTT+XML，為什么不考慮換為XMPP呢？
綜上所述，MQTT+JSON是目前最優方案。協議簡潔清晰、易於閱讀、解析和生成等，也考慮了服務器端開發者和設備端開發者的開發成本。
2、有關MQTT的雲平台和工具
（1）支持MQTT的雲平台
目前，百度、阿里、騰訊的雲平台都逐漸有了物聯網開發套件：騰訊QQ物聯平台內測中，阿里雲物聯網套件公測中，兩者都需要進行申請試用，而百度雲物聯網套件已經支持MQTT並且可以免費試用一段時間。除了BAT三大家，下面再介紹一些其他支持MQTT的物聯網雲平台。
OneNET雲平台：OneNET是由中國移動打造的PaaS物聯網開放平台。平台能夠幫助開發者輕松實現設備接入與設備連接，快速完成產品開發部署，為智能硬件、智能家居產品提供完善的物聯網解決方案。OneNET雲平台已經於2014年10月正式上線。
雲巴：雲巴（Cloud Bus）是一個跨平台的雙向實時通信系統，為物聯網、App和Web提供實時通信服務。雲巴基於MQTT，支持Socket.IO協議，支持RESTful API。
（2）MQTT服務器
如果不想使用雲平台，只是純粹地玩一下MQTT，或者只想在內網對設備進行監控，那么可以自己本地部署一個MQTT服務器。下面介紹幾款MQTT服務器：
Apache-Apollo：一個代理服務器，在ActiveMQ基礎上發展而來，可以支持STOMP、AMQP、MQTT、Openwire、SSL和WebSockets等多種協議，並且Apollo提供后台管理頁面，方便開發者管理和調試。
EMQ：EMQ 2.0，號稱百萬級開源MQTT消息服務器，基於Erlang/OTP語言平台開發，支持大規模連接和分布式集群，發布訂閱模式的開源MQTT消息服務器。
HiveMQ：一個企業級的MQTT代理，主要用於企業和新興的機器到機器M2M通訊和內部傳輸，最大程度的滿足可伸縮性、易管理和安全特性，提供免費的個人版。HiveMQ提供了開源的插件開發包。
Mosquitto：一款實現了消息推送協議MQTT v3.1的開源消息代理軟件，提供輕量級的、支持可發布/可訂閱的消息推送模式。
（3）MQTT調試工具
知道了各大平台的MQTT，同時自己也可以在內網部署MQTT服務器，那接下來沒有調試工具怎么行呢，難道要用自己喜歡的語言編寫一個？當然不需要。MQTT調試工具可以考慮使用HiveMQ的MQTT客戶端——HiveMQ Websockets Client，這是一款基於WebSocket的瀏覽器MQTT客戶端，支持主題訂閱和發布。
（4）MQTT與其他協議
目前各大平台都開始支持MQTT協議，MQTT相比其他協議有什么優勢呢？物聯網設備能不能用其他的協議呢？下面是MQTT與其他部分協議的比較，給大家作為參考。
1）MQTT與TCP Socket
雖然MQTT運行於TCP層之上，看起來這兩者之間根本沒有比較性，但筆者覺得還是有必要敘述一番，因為大多數從事硬件或嵌入式開發的工程師，都是直接在TCP層上通信的。從事嵌入式開發工作的人都應該知道LwIP，LwIP是一套用於嵌入式系統的開放源代碼TCP/IP協議棧，LwIP在保證嵌入式產品擁有完整的TCP/IP功能的同時，又能保證協議棧對處理器資源的有限消耗，其運行一般僅需要幾十KB的RAM和40KB左右的ROM。
也就是說，只要是嵌入式產品使用了LwIP，就支持TCP/IP協議棧，進而可以使用MQTT協議。
由於TCP協議有粘包和分包問題，所以傳輸數據時需要自定義協議，如果傳輸的數據報超過MSS（最大報文段長度），一定要給協議定義一個消息長度字段，確保接收端能通過緩沖完整收取消息。一個簡單的協議定義：消息頭部+消息長度+消息正文。
當然，使用MQTT協議則不需要考慮這個問題，這些MQTT都已經處理好了，MQTT最長可以一次性發送256MB數據，不用考慮粘包分包的問題。
總之，TCP和MQTT本身並不矛盾，只不過基於Socket開發需要處理更多的事情，而且大多數嵌入式開發模塊本身也只會提供Socket接口供廠家自定義協議。
2）MQTT與HTTP
HTTP最初的目的是提供一種發布和接收HTML頁面的方法，主要用於Web。HTTP是典型的C/S通訊模式：請求從客戶端發出，服務端只能被動接收，一條連接只能發送一次請求，獲取響應后就斷開連接。該協議最早是為了適用Web瀏覽器的上網瀏覽場景而設計的，目前在PC、手機、Pad等終端上都應用廣泛。由於這樣的通信特點，HTTP技術在物聯網設備中很難實現設備的反向控制，不過非要實現也不是不行，下面看一下Web端的例子。
目前，在微博等SNS網站上有海量用戶公開發布的內容，當發布者發布消息，數據傳到服務器更新時，就需要給關注者盡可能的實時更新內容。Web網站基於HTTP協議，使用HTTP協議探測服務器上是否有內容更新，就必須頻繁地讓客戶端請求服務器進行確認。在瀏覽器中要實現這種效果，可以使用Comet技術，Comet是基於HTTP長連接的“服務器推”技術，主要有兩種實現模型：基於AJAX的長輪詢（long-polling）方式和基於Iframe及htmlfile的流（streaming）方式。這兩種技術模型在這里不詳細展開，有興趣的讀者可以查閱相關資料。
如果要實現設備的反向控制，可能就要用到前面提到的Comet技術。由於需要不斷的請求服務器，會導致通信開銷非常大，加上HTTP冗長的報文頭，在節省流量上實在沒有優勢。
當然，如果只是單純地讓設備定時上報數據而不做控制，也是可以使用HTTP協議的。
3）MQTT與XMPP
最有可能與MQTT競爭的是XMPP協議。XMPP（可擴展通訊與表示協議）是一項用於實時通訊的開放技術，它使用可擴展標記語言（XML）作為交換信息的基本格式。其優點是協議成熟、強大、可擴展性強。目前主要應用於許多聊天系統中，在消息推送領域，MQTT和XMPP互相競爭。下面列舉MQTT與XMPP各自的特性：
XMPP協議基於繁重的XML，報文體積大且交互繁瑣；而MQTT協議固定報頭只有兩個字節，報文體積小、編解碼容易；
XMPP基於JID的點對點消息傳輸；MQTT協議基於主題(Topic)發布\訂閱模式，消息路由更為靈活；
XMPP協議采用XML承載報文，二進制必須進行Base64編碼或其他方式處理；MQTT協議未定義報文內容格式，可以承載JSON、二進制等不同類型報文，開發者可以針對性的定義報文格式；
MQTT協議支持消息收發確認和QoS保證，有更好的消息可靠性保證；而XMPP主協議並未定義類似機制；
在嵌入式設備開發中大多使用的是C語言開發，C語言解析XML是非常困難的。MQTT基於二進制實現且未定義報文內容格式，可以很好的兼顧嵌入式C語言開發者；而XMPP基於XML，開發者需要配合協議格式，不能靈活開發。
綜上所述，在嵌入式設備中，由於需要一個靈巧簡潔，對設備開發者和服務端開發者都友好的協議，MQTT比XMPP更具有優勢。
4）MQTT與CoAP
CoAP也是一個能與MQTT競爭的協議。其模仿HTTP的REST模型，服務端以URI方式創建資源，客戶端可以通過GET、PUT、POST、DELETE方式訪問這些資源，並且協議風格也和HTTP極為相似，例如一個設備有溫度數據，那么這個溫度可以被描述為：
CoAP://:/sensors/temperature
其中為設備的IP，為端口。
不過，如果使用CoAP可能會讓物聯網后台的情況變得復雜，比如MQTT可以實現一個最簡單的IoT架構：Device + MQTT服務器 + APP，手機端或Web端可以直接從MQTT服務器訂閱想要的主題。而CoAP可能需要這樣的架構：CoAP + Web + DataBase + App，使用CoAP必須經過DataBase才能轉給第三方。
至於CoAP和MQTT孰優孰劣，這里不作定論。不過目前來說，CoAP資料還是略少。而且，MQTT除了可以應用於物聯網領域，在手機消息推送、在線聊天等領域都可以有所作為。
（5）小結
經過以上的比較，我們可以得出如下結論：MQTT基於異步發布/訂閱的實現解耦了消息發布者和訂閱者，基於二進制的實現節省了存儲空間及流量，同時MQTT擁有更好的消息處理機制，可以替代TCP Socket一部分應用場景。相對於HTTP和XMPP，MQTT可以選擇用戶數據格式，解析復雜度低，同時MQTT也可用於手機推送等領域。手機作為與人連接的入口，正好建立了人與物的連接，可謂一箭雙雕。當然，其他協議也可以作為一個輔助的存在，HTTP可以為只需定時上傳數據的設備服務，CoAP則更適用於非常受限的移動通信網絡，表3直觀地展示了上文提到的幾種協議之間的優劣異同。
轉自：https://blog.csdn.net/anxianfeng55555/article/details/80908795#comments_10800174