正文 物聯網是新一代信息技術的重要組成部分，也是“信息化”時代的重要發展階段。其英文名稱是：“Internet of things（IoT）”。 顧名思義，物聯網就是物物相連的互聯網。 其一，物聯網的核心和基礎仍然是互聯網，是在互聯網基礎上的延伸和擴展的網絡； 其二，其用戶端延伸和擴展到了任何物品與物品之間，進行信息交換和通信，也就是物物相息。 物聯網通過智能感知、識別技術與普適計算等通信感知技術，廣泛應用于網絡的融合中，也因此被稱為 繼計算機、互聯網之后世界信息產業發展的第三次浪潮。而在物聯網的應用上，對于信息傳輸，MQTT是一種再合適不過的協議工具了。一、MQTT簡介 MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議），是一種基于 發布/訂閱（publish/subscribe）模式的輕量級協議，該協議構建于TCP/IP協議之上，MQTT最大優點在于， 可以以極少的代碼和有限的帶寬，為連接遠程設備提供實時可靠的消息服務。作為一種低開銷、低帶寬占用的 即時通訊協議，使其在物聯網、小型設備、移動應用等方面有較廣泛的應用。MQTT是一個基于客戶端-服務器的消息發布/訂閱傳輸協議。MQTT協議是輕量、簡單、開放和易于實現的， 這些特點使它適用范圍非常廣泛。在很多情況下，包括受限的環境中，如：機器與機器（M2M）通信和 物聯網（IoT）。其在，通過衛星鏈路通信傳感器、偶爾撥號的醫療設備、智能家居、及一些小型化設備中 已廣泛使用。　　二、特性 MQTT協議工作在低帶寬、不可靠的網絡的遠程傳感器和控制設備通訊而設計的協議，它具有以下主要的幾項特性： （1）使用發布/訂閱消息模式，提供一對多的消息發布，解除應用程序耦合。 （2）對負載內容屏蔽的消息傳輸。 （3）使用TCP/IP提供網絡連接。 主流的MQTT是基于TCP連接進行數據推送的，但是同樣有基于UDP的版本，叫做MQTT-SN。這兩種版本由于 基于不同的連接方式，優缺點自然也就各有不同了。 （4）有三種消息發布服務質量：“至多一次”，消息發布完全依賴底層TCP/IP網絡。會發生消息丟失或重復。 這一級別可用于如下情況，環境傳感器數據，丟失一次讀記錄無所謂，因為不久后還會有第二次發送。 這一種方式主要普通APP的推送，倘若你的智能設備在消息推送時未聯網，推送過去沒收到，再次聯網也 就收不到了。 “至少一次”，確保消息到達，但消息重復可能會發生。 “只有一次”，確保消息到達一次。在一些要求比較嚴格的計費系統中，可以使用此級別。 在計費系統中，消息重復或丟失會導致不正確的結果。這種最高質量的消息發布服務還可以用于即時 通訊類的APP的推送，確保用戶收到且只會收到一次。 （5）小型傳輸，開銷很小（固定長度的頭部是2字節），協議交換最小化，以降低網絡流量。 這就是為什么在介紹里說它非常適合“在物聯網領域，傳感器與服務器的通信，信息的收集”，要知道 嵌入式設備的運算能力和帶寬都相對薄弱，使用這種協議來傳遞消息再適合不過了。三、實現方式　 實現MQTT協議需要客戶端和服務器端通訊完成，在通訊過程中，MQTT協議中有三種身份： 發布者（Publish）、代理（Broker）（服務器）、訂閱者（Subscribe）。其中，消息的發布者和訂閱者 都是客戶端，消息代理是服務器，消息發布者可以同時是訂閱者。 MQTT傳輸的消息分為：主題（Topic）和負載（payload）兩部分： （1）Topic，可以理解為消息的類型，訂閱者訂閱（Subscribe）后，就會收到該主題的 消息內容（payload）； （2）payload，可以理解為消息的內容，是指訂閱者具體要使用的內容。四、MQTT的搭建（ubuntu） 1、apt-get安裝mqtt相關包 2、測試mosquitto是否正確運行 3、本機終端測試mqtt 打開一個終端，訂閱主題 mosquitto_sub -h 192.168.1.102 -t "mqtt" -v 【-h】指定要連接的MQTT服務器 【-t】向指定主題推送消息 【-m】指定消息內容五、MQTT權限配置 默認是允許匿名用戶登錄，對于正式上線的項目則是需要進行用戶認證（當然，用戶一般都會與數據庫映射， 不過在這里我們就會直接將用戶寫入配置文件中） 1、Mosquitto服務器的配置文件為/etc/mosquitto/mosquitto.conf，關于用戶認證的方式和讀取的配置 都在這個文件中進行六、MQTT實現（Java語言） 配置了MQTT的用戶權限控制，所以下面的用戶只能使用stonegeek登錄，否則項目會運行報錯，而且 我們在上面設置的訪問控制列表中只有mtopic主題，所以我們必須使用此主題，否則，訂閱者會收不到 已發布的主題內容（已經測試過了） Java語言實現的MQTT服務的發布/訂閱 1、添加Maven依賴<dependency><groupId>org.eclipse.paho</groupId><artifactId>org.eclipse.paho.client.mqttv3</artifactId><version>1.1.1</version></dependency> 2、ServerMQTT.class 3、ClientMQTT.class import java.util.concurrent.ScheduledExecutorService; import org.eclipse.paho.client.mqttv3.MqttClient; import org.eclipse.paho.client.mqttv3.MqttConnectOptions; import org.eclipse.paho.client.mqttv3.MqttException; import org.eclipse.paho.client.mqttv3.MqttTopic; import org.eclipse.paho.client.mqttv3.persist.MemoryPersistence;public class ClientMQTT {public static final String HOST = "tcp://192.168.1.102:1883";public static final String TOPIC = "mtopic";private static final String clientid = "client11";private MqttClient client;private MqttConnectOptions options;private String userName = "stonegeek";private String passWord = "123456";private ScheduledExecutorService scheduler;private void start() {try {// host為主機名，clientid即連接MQTT的客戶端ID， 一般以唯一標識符表示，MemoryPersistence設置clientid的保存形式，默認為以內存保存client = new MqttClient(HOST, clientid, new MemoryPersistence());// MQTT的連接設置options = new MqttConnectOptions();// 設置是否清空session,這里如果設置為false表示服務器會保留客戶端的連接記錄， 這里設置為true表示每次連接到服務器都以新的身份連接options.setCleanSession(true);// 設置連接的用戶名options.setUserName(userName);// 設置連接的密碼options.setPassword(passWord.toCharArray());// 設置超時時間 單位為秒options.setConnectionTimeout(10);// 設置會話心跳時間 單位為秒 服務器會每隔1.5*20秒的時間向客戶端發送個消息 判斷客戶端是否在線，但這個方法并沒有重連的機制options.setKeepAliveInterval(20);// 設置回調client.setCallback(new PushCallback());MqttTopic topic = client.getTopic(TOPIC);//setWill方法，如果項目中需要知道客戶端是否掉線可以調用該方法。設置最終端口的 通知消息options.setWill(topic, "close".getBytes(), 2, true);client.connect(options);//訂閱消息int[] Qos = {1};String[] topic1 = {TOPIC};client.subscribe(topic1, Qos);} catch (Exception e) {e.printStackTrace();}}public static void main(String[] args) throws MqttException {ClientMQTT client = new ClientMQTT();client.start();} }4、PushCallback.class import org.eclipse.paho.client.mqttv3.MqttCallback; import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken; import org.eclipse.paho.client.mqttv3.MqttMessage;/*** * * 發布消息的回調類 ** 必須實現MqttCallback的接口并實現對應的相關接口方法CallBack 類將實現 MqttCallBack。 * 每個客戶機標識都需要一個回調實例。在此示例中，構造函數傳遞客戶機標識以另存為實例數據。 * 在回調中，將它用來標識已經啟動了該回調的哪個實例。 * 必須在回調類中實現三個方法： ** public void messageArrived(MqttTopic topic, MqttMessage message)接收已經預訂的發布。 ** public void connectionLost(Throwable cause)在斷開連接時調用。 ** public void deliveryComplete(MqttDeliveryToken token)) * 接收到已經發布的 QoS 1 或 QoS 2 消息的傳遞令牌時調用。 * 由 MqttClient.connect 激活此回調。 */ public class PushCallback implements MqttCallback{public void connectionLost(Throwable cause) {// 連接丟失后，一般在這里面進行重連System.out.println("連接斷開，可以做重連");}public void deliveryComplete(IMqttDeliveryToken token) {System.out.println("deliveryComplete---------" + token.isComplete());}public void messageArrived(String topic, MqttMessage message) throws Exception {// subscribe后得到的消息會執行到這里面System.out.println("接收消息主題 : " + topic);System.out.println("接收消息Qos : " + message.getQos());System.out.println("接收消息內容 : " + new String(message.getPayload()));} }

IOT(7)---MQTT

MQTT是什么？ MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議），是一種基于 發布/訂閱（Publish/Subscribe）模式的輕量級通訊協議，該協議構建于TCP/IP協議上，由IBM 在1999年發布，目前最新版本為v3.1.1。 MQTT最大的優點在于可以以極少的代碼和有限的帶寬，為遠程設備提供實時可靠的消息服務。做為一種低開銷、 低帶寬占用的即時通訊協議，MQTT在物聯網、小型設備、移動應用等方面有廣泛的應用。當然，在物聯網開發中，MQTT不是唯一的選擇，與MQTT互相競爭的協議有XMPP和CoAP協議等MQTT是哪一層的協議？ TCP/IP參考模型可以分為四層：應用層、傳輸層、網絡層、鏈路層。 TCP和UDP位于傳輸層，應用層常見的協議有HTTP、FTP、SSH等。MQTT協議運行于TCP之上，屬于應用層協議， 因此只要是支持TCP/IP協議棧的地方，都可以使用MQTT。MQTT消息格式 每條MQTT命令消息的消息頭都包含一個固定的報頭，有些消息會攜帶一個可變報文頭和一個負荷。消息格式如下： 固定報文頭 | 可變報文頭 | 負荷 固定報文頭（Fixed Header） 可變報文頭（Variable Header） 有效負荷（Payload） Payload直譯為負荷，可能讓人摸不著頭腦，實際上可以理解為消息主體 （body）。當MQTT發送的消息類型是CONNECT（連接）、PUBLISH（發布）、 SUBSCRIBE（訂閱）、SUBACK（訂閱確認）、UNSUBSCRIBE（取消訂閱）時，則會帶有負荷。MQTT的主要特性 MQTT的消息類型（Message Type） 固定報文頭中的第一個字節包含連接標志（Connect Flags），連接標志用來區分MQTT的消息類型。MQTT協議 擁有14種不同的消息類型，可簡單分為連接及終止、發布和訂閱、QoS 2消息的機制以及各種確認ACK。消息質量（QoS） MQTT消息質量有三個等級，QoS 0，QoS 1和 QoS 2。 QoS 0：最多分發一次。消息的傳遞完全依賴底層的TCP/IP網絡，協議里沒有定義應答和重試，消息要么 只會到達服務端一次，要么根本沒有到達。 QoS 1：至少分發一次。服務器的消息接收由PUBACK消息進行確認，如果通信鏈路或發送設備異常，或者 指定時間內沒有收到確認消息，發送端會重發這條在消息頭中設置了DUP位的消息。 QoS 2：只分發一次。這是最高級別的消息傳遞，消息丟失和重復都是不可接受的，使用這個服務質量等級 會有額外的開銷。 通過下面的例子可以更深刻的理解上面三個傳輸質量等級。比如目前流行的共享單車智能鎖，智能鎖可以定時使用QoS level 0質量消息請求服務器，發送單車的 當前位置，如果服務器沒收到也沒關系，反正過一段時間又會再發送一次。之后用戶可以通過App查詢周圍 單車位置，找到單車后需要進行解鎖，這時候可以使用QoS level 1質量消息，手機App不斷的發送解鎖消息 給單車鎖，確保有一次消息能達到以解鎖單車。最后用戶用完單車后，需要提交付款表單，可以使用 QoS level 2質量消息，這樣確保只傳遞一次數據，否則用戶就會多付錢了。遺愿標志（Will Flag） 在可變報文頭的連接標志位字段（Connect Flags）里有三個Will標志位：Will Flag、Will QoS和 Will Retain Flag，這些Will字段用于監控客戶端與服務器之間的連接狀況。如果設置了Will Flag， 就必須設置Will QoS和Will Retain標志位，消息主體中也必須有Will Topic和Will Message字段。 服務器與客戶端通信時，當遇到異常或客戶端心跳超時的情況，MQTT服務器會替客戶端發布一個Will消息。 當然如果服務器收到來自客戶端的DISCONNECT消息，則不會觸發Will消息的發送。 因此，Will字段可以應用于設備掉線后需要通知用戶的場景。連接保活心跳機制（Keep Alive Timer） MQTT客戶端可以設置一個心跳間隔時間（Keep Alive Timer），表示在每個心跳間隔時間內發送一條消息。 如果在這個時間周期內，沒有業務數據相關的消息，客戶端會發一個PINGREQ消息，相應的，服務器會返回 一個PINGRESP消息進行確認。如果服務器在一個半（1.5）心跳間隔時間周期內沒有收到來自客戶端的消息， 就會斷開與客戶端的連接。心跳間隔時間最大值大約可以設置為18個小時，0值意味著客戶端不斷開。MQTT其他特點 異步發布/訂閱實現 發布/訂閱模式解耦了發布消息的客戶（發布者）與訂閱消息的客戶（訂閱者）之間的關系，這意味著發布者 和訂閱者之間并不需要直接建立聯系。 這個模式有以下好處： 發布者與訂閱者只需要知道同一個消息代理即可； 發布者和訂閱者不需要直接交互； 發布者和訂閱者不需要同時在線。 由于采用了發布/訂閱實現，MQTT可以雙向通信。也就是說MQTT支持服務端反向控制設備，設備可以訂閱 某個主題，然后發布者對該主題發布消息，設備收到消息后即可進行一系列操作。二進制格式實現 MQTT基于二進制實現而不是字符串，比如HTTP和XMPP都是基于字符串實現。由于HTTP和XMPP擁有冗長的 協議頭部，而MQTT固定報文頭僅有兩字節，所以相比其他協議，發送一條消息最省流量。MQTT的安全 由于MQTT運行于TCP層之上并以明文方式傳輸，這就相當于HTTP的明文傳輸，使用Wireshark可以完全 看到MQTT發送的所有消息，消息指令一覽無遺這樣可能會產生以下風險： 設備可能會被盜用； 客戶端和服務端的靜態數據可能是可訪問的（可能會被修改）； 協議行為可能有副作用（如計時器攻擊）； 拒絕服務攻擊； 通信可能會被攔截、修改、重定向或者泄露； 虛假控制報文注入。作為傳輸協議，MQTT僅關注消息傳輸，提供合適的安全功能是開發者的責任。安全功能可以從三個層次來 考慮——應用層、傳輸層、網絡層。應用層：在應用層上，MQTT提供了客戶標識（Client Identifier）以及用戶名和密碼，可以在應用層 驗證設備。傳輸層：類似于HTTPS，MQTT基于TCP連接，也可以加上一層TLS，傳輸層使用TLS加密是確保安全的一個 好手段，可以防止中間人攻擊。客戶端證書不但可以作為設備的身份憑證，還可以用來驗證設備。網絡層：如果有條件的話，可以通過拉專線或者使用VPN來連接設備與MQTT代理，以提高網絡傳輸的安全性。認證 MQTT支持兩種層次的認證： 應用層：MQTT支持客戶標識、用戶名和密碼認證； 傳輸層：傳輸層可以使用TLS，除了加密通訊，還可以使用X509證書來認證設備。客戶標識 MQTT客戶端可以發送最多65535個字符作為客戶標識（Client Identifier），一般來說可以使用嵌入式 芯片的MAC地址或者芯片序列號。用戶名和密碼 MQTT協議支持通過CONNECT消息的username和password字段發送用戶名和密碼。 用戶名及密碼的認證使用起來非常方便，不過由于它們是以明文形式傳輸，所以使用抓包工具就可以輕易的 獲取。 一般來說，使用客戶標識、用戶名和密碼已經足夠了，比如支持MQTT協議連接的OneNET云平臺，就是使用了 這三個字段作為認證。如果感覺還不夠安全，還可以在傳輸層進行認證。在傳輸層認證 在傳輸層認證是這樣的：MQTT代理在TLS握手成功之后可以繼續發送客戶端的X509證書來認證設備，如果 設備不合法便可以中斷連接。在傳輸層就可以驗證設備的合法性，在發送CONNECT消息之前便可以阻隔非法 設備的連接，以節省后續不必要的資源浪費。而且，MQTT協議運行在使用TLS時，除了提供身份認證， 還可以確保消息的完整性和保密性。選擇用戶數據格式MQTT協議只實現了傳送消息的格式，并沒有限制用戶協議需要按照一定的風格，因此在MQTT協議之上， 我們需要定義一套自己的通信協議。比如說，發布者向設備發布一條打開消息，設備可以回復一個消息 并攜帶返回碼，這樣的消息格式是使用二進制、字符串還是JSON格式呢？下面就簡單做個選型參考。十六進制/二進制 MQTT原本就是基于二進制實現的，所以用戶協議使用二進制實現是一個不錯的選擇。雖然失去了直觀的 可讀性，但可以將流量控制在非常小。其實對于單片機開發者來說十六進制并不陌生，因為單片機寄存器 都是以位來操作的，芯片間通信也會使用十六進制/二進制。而對于沒有單片機開發經驗的工程師來說， 十六進制/二進制可能就太原始了。字符串 對單片機開發者來說，字符串也是一個選擇。比如通過串口傳輸的AT指令就是基于字符串通信的。 使用字符串方便了人閱讀，但是對高級語言開發者來說，字符串依舊不是最佳選擇，恐怕鍵值對 （Key-Value）才是最優形式。JSON JSON中文全稱是JavaScript對象標記語言，在這門語言中，一切都是對象。因此，任何支持的類型都可以 通過JSON來表示，例如字符串、數字、對象、數組等。其語法規則是： 對象表示為鍵值對； 數據由逗號分隔； 花括號保存對象； 方括號保存數組。 JSON層次結構簡潔清晰，易于閱讀和編寫，同時也易于機器解析和生成，有效提升網絡傳輸效率。XML MQTT協議只負責通信部分，用戶協議可以自己選擇，當然也可以選擇復雜又冗長的XML格式。可是既然要 選擇MQTT+XML，為什么不考慮換為XMPP呢？小結 綜上所述，MQTT+JSON是目前最優方案。協議簡潔清晰、易于閱讀、解析和生成等，也考慮了服務器端開發者 和設備端開發者的開發成本。有關MQTT的云平臺和工具 支持MQTT的云平臺目前，百度、阿里、騰訊的云平臺都逐漸有了物聯網開發套件：騰訊QQ物聯平臺內測中，阿里云物聯網 套件公測中，兩者都需要進行申請試用，而百度云物聯網套件已經支持MQTT并且可以免費試用一段時間。 除了BAT三大家，下面再介紹一些其他支持MQTT的物聯網云平臺。OneNET云平臺：OneNET是由中國移動打造的PaaS物聯網開放平臺。平臺能夠幫助開發者輕松實現設備接入與 設備連接，快速完成產品開發部署，為智能硬件、智能家居產品提供完善的物聯網解決方案。OneNET云平臺 已經于2014年10月正式上線。云巴：云巴（Cloud Bus）是一個跨平臺的雙向實時通信系統，為物聯網、App和Web提供實時通信服務。 云巴基于MQTT，支持Socket.IO協議，支持RESTful API。MQTT服務器 如果不想使用云平臺，只是純粹地玩一下MQTT，或者只想在內網對設備進行監控，那么可以自己本地部署 一個MQTT服務器。下面介紹幾款MQTT服務器： Apache-Apollo：一個代理服務器，在ActiveMQ基礎上發展而來，可以支持STOMP、AMQP、 MQTT、Openwire、SSL和WebSockets等多種協議，并且Apollo提供后臺管理頁面，方便開發者管理和調試。 HiveMQ：一個企業級的MQTT代理，主要用于企業和新興的機器到機器M2M通訊和內部傳輸，最大程度的滿足 可伸縮性、易管理和安全特性，提供免費的個人版。HiveMQ提供了開源的插件開發包。 Mosquitto：一款實現了消息推送協議MQTT v3.1的開源消息代理軟件，提供輕量級的、支持可發布/可訂閱 的消息推送模式。MQTT與其他協議 目前各大平臺都開始支持MQTT協議，MQTT相比其他協議有什么優勢呢？物聯網設備能不能用其他的協議呢？MQTT與TCP Socket 由于TCP協議有粘包和分包問題，所以傳輸數據時需要自定義協議，如果傳輸的數據報超過MSS （最大報文段長度），一定要給協議定義一個消息長度字段，確保接收端能通過緩沖完整收取消息。 一個簡單的協議定義：消息頭部+消息長度+消息正文。 當然，使用MQTT協議則不需要考慮這個問題，這些MQTT都已經處理好了，MQTT最長可以一次性發送256MB 數據，不用考慮粘包分包的問題。 總之，TCP和MQTT本身并不矛盾，只不過基于Socket開發需要處理更多的事情，而且大多數嵌入式開發模塊 本身也只會提供Socket接口供廠家自定義協議。MQTT與HTTP HTTP最初的目的是提供一種發布和接收HTML頁面的方法，主要用于Web。HTTP是典型的C/S通訊模式：請求從 客戶端發出，服務端只能被動接收，一條連接只能發送一次請求，獲取響應后就斷開連接。該協議最早是為了 適用Web瀏覽器的上網瀏覽場景而設計的，目前在PC、手機、Pad等終端上都應用廣泛。由于這樣的通信 特點，HTTP技術在物聯網設備中很難實現設備的反向控制，不過非要實現也不是不行，下面看一下Web端的例子如果要實現設備的反向控制，可能就要用到前面提到的Comet技術。由于需要不斷的請求服務器，會導致通信 開銷非常大，加上HTTP冗長的報文頭，在節省流量上實在沒有優勢。當然，如果只是單純地讓設備定時上報數據而不做控制，也是可以使用HTTP協議的。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更具有優勢。CoAP也是一個能與MQTT競爭的協議。其模仿HTTP的REST模型，服務端以URI方式創建資源，客戶端可以 通過GET、PUT、POST、DELETE方式訪問這些資源，并且協議風格也和HTTP極為相似，例如一個設備有 溫度數據，那么這個溫度可以被描述為： CoAP://:/sensors/temperature 不過，如果使用CoAP可能會讓物聯網后臺的情況變得復雜，比如MQTT可以實現一個最簡單的IoT架構： Device + MQTT服務器 + APP，手機端或Web端可以直接從MQTT服務器訂閱想要的主題。而CoAP可能需要 這樣的架構：CoAP + Web + DataBase + App，使用CoAP必須經過DataBase才能轉給第三方。小結 MQTT基于異步發布/訂閱的實現解耦了消息發布者和訂閱者，基于二進制的實現節省了存儲空間及流量， 同時MQTT擁有更好的消息處理機制，可以替代TCP Socket一部分應用場景。相對于HTTP和XMPP，MQTT可以 選擇用戶數據格式，解析復雜度低，同時MQTT也可用于手機推送等領域。手機作為與人連接的入口，正好 建立了人與物的連接，可謂一箭雙雕。當然，其他協議也可以作為一個輔助的存在，HTTP可以為只需定時 上傳數據的設備服務，CoAP則更適用于非常受限的移動通信網絡，表3直觀地展示了上文提到的幾種協議之間 的優劣異同。

?

總結

以上是生活随笔為你收集整理的MQTT介绍与使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。