一，MQTT協(xié)議
1、MQTT協(xié)議可以以極少的代碼和有限的帶寬，為連接遠程設備提供實時可靠的消息服務。
2、使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布，解除應用程序耦合。
對負載內(nèi)容屏蔽的消息傳輸。
使用 TCP/IP 提供網(wǎng)絡連接。
3、實現(xiàn)MQTT協(xié)議需要客戶端和服務器端通訊完成，在通訊過程中，MQTT協(xié)議中有三種身份：發(fā)布者（Publish）、代理（Broker）（服務器）、訂閱者（Subscribe）。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務器，消息發(fā)布者可以同時是訂閱者。
4、MQTT傳輸?shù)南⒎譃椋褐黝}（Topic）和負載（payload）兩部分：
（1）Topic，可以理解為消息的類型，訂閱者訂閱（Subscribe）后，就會收到該主題的消息內(nèi)容（payload）。
（2）payload，可以理解為消息的內(nèi)容，是指訂閱者具體要使用的內(nèi)容。
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協(xié)議），是一種基于發(fā)布/訂閱（Publish/Subscribe）模式的輕量級通訊協(xié)議，該協(xié)議構(gòu)建于TCP/IP協(xié)議上，由IBM在1999年發(fā)布，目前最新版本為v3.1.1。MQTT最大的優(yōu)點在于可以以極少的代碼和有限的帶寬，為遠程設備提供實時可靠的消息服務。做為一種低開銷、低帶寬占用的即時通訊協(xié)議，MQTT在物聯(lián)網(wǎng)、小型設備、移動應用等方面有廣泛的應用。
當然，在物聯(lián)網(wǎng)開發(fā)中，MQTT不是唯一的選擇，與MQTT互相競爭的協(xié)議有XMPP和CoAP協(xié)議等，
應用消息 Application Message
MQTT協(xié)議通過網(wǎng)絡傳輸應用數(shù)據(jù)。應用消息通過MQTT傳輸時，它們有關聯(lián)的服務質(zhì)量（QoS）和主題（Topic）。
客戶端Client
使用MQTT的程序或設備。客戶端總是通過網(wǎng)絡連接到服務端。
它可以發(fā)布應用消息給其它相關的客戶端。
訂閱以請求接受相關的應用消息。取消訂閱以移除接受應用消息的請求。從服務端斷開連接。
一般情況，云下設備==客戶端
服務端 Server
一個程序或設備，作為發(fā)送消息的客戶端和請求訂閱的客戶端之間的中介。
服務端接受來自客戶端的網(wǎng)絡連接。接受客戶端發(fā)布的應用消息。處理客戶端的訂閱和取消訂閱請求。轉(zhuǎn)發(fā)應用消息給符合條件的已訂閱客戶端。
（服務端不是數(shù)據(jù)的終點，它只是數(shù)據(jù)的中轉(zhuǎn)站）
（一般情況下，云平臺==服務端）
訂閱 Subscription
訂閱包含一個主題過濾器（Topic Filter）和一個最大的服務質(zhì)量（QoS）等級。
訂閱與單個會話（Session）關聯(lián)。會話可以包含多于一個的訂閱。會話的每個訂閱都有一個不同的主題過濾器。
主題名 Topic
Name附加在應用消息上的一個標簽，服務端已知且與訂閱匹配。服務端發(fā)送應用消息的一個副本給每一個匹配的客戶端訂閱。
主題過濾器 Topic Filter
訂閱中包含的一個表達式，用于表示相關的一個或多個主題。主題過濾器可以使用通配符。
會話 Session
客戶端和服務端之間的狀態(tài)交互。一些會話持續(xù)時長與網(wǎng)絡連接一樣，另一些可以在客戶端和服務端的多個連續(xù)網(wǎng)絡連接間擴展。
控制報文 MQTT Control Packet
通過網(wǎng)絡連接發(fā)送的信息數(shù)據(jù)包。MQTT規(guī)范定義了十四種不同類型的控制報文，其中一個（PUBLISH報文）用于傳輸應用消息。
ASCII：0~31及127（共33個）是控制字符或通信專用字符（其余為可顯示字符32~126（共95個）是字符（32是空格），其中48~57為0到9十個阿拉伯數(shù)字。65~90為26個大寫英文字母，97~122號為26個小寫英文字母，其余為一些標點符號、運算符號等。 GBK：漢字內(nèi)碼擴展規(guī)范（國標）。 采用單/雙字節(jié)變長編碼，完全兼容AsCH字符編碼英文使用單字節(jié)編碼，中文部分采用雙字節(jié)編碼。 UTF-8：是一種針對 Un i code的可變長度字符編碼，又稱萬國碼。 UTF-8用1到6個字節(jié)編碼 Uni code字符。 可以表示中文簡體繁體及其它語言（如英文，日文，韓文）。 注意：即使是同一個漢字，在不同的編碼中所對應的數(shù)值/長度是不同的（如：GBK/UTF-8安信可IDE默認是GBK編碼，MTT規(guī)定為UTF-8編碼。 如果使用安信可編譯器編程發(fā)送漢字，需將安信可IDE的編碼方式設為UTF-8。
清理會話 Clean Session
當MTT客戶端接入MTT服務端時，選擇是否繼續(xù)之前的會話。
如果不清理會話，MTT服務端會在之前交互的基礎上，繼續(xù)交互如果清理會話，MTT服務端必須新建一個全新的會話。
消息質(zhì)量（QoS）
MQTT消息質(zhì)量有三個等級，QoS 0，QoS 1和 QoS 2。
QoS 0：最多分發(fā)一次。消息的傳遞完全依賴底層的TCP/IP網(wǎng)絡，協(xié)議里沒有定義應答和重試，消息要么只會到達服務端一次，要么根本沒有到達。
QoS 1：至少分發(fā)一次。服務器的消息接收由PUBACK消息進行確認，如果通信鏈路或發(fā)送設備異常，或者指定時間內(nèi)沒有收到確認消息，發(fā)送端會重發(fā)這條在消息頭中設置了DUP位的消息。
QoS 2：只分發(fā)一次。這是最高級別的消息傳遞，消息丟失和重復都是不可接受的，使用這個服務質(zhì)量等級會有額外的開銷。
eg.
目前流行的共享單車智能鎖，智能鎖可以定時使用QoS level 0質(zhì)量消息請求服務器，發(fā)送單車的當前位置，如果服務器沒收到也沒關系，反正過一段時間又會再發(fā)送一次。之后用戶可以通過App查詢周圍單車位置，找到單車后需要進行解鎖，這時候可以使用QoS level 1質(zhì)量消息，手機App不斷的發(fā)送解鎖消息給單車鎖，確保有一次消息能達到以解鎖單車。最后用戶用完單車后，需要提交付款表單，可以使用QoS level 2質(zhì)量消息，這樣確保只傳遞一次數(shù)據(jù)，否則用戶就會多付錢了。
MQTT的消息類型（Message Type）
固定報文頭中的第一個字節(jié)包含連接標志（Connect Flags），連接標志用來區(qū)分MQTT的消息類型。MQTT協(xié)議擁有14種不同的消息類型（如表2），可簡單分為連接及終止、發(fā)布和訂閱、QoS 2消息的機制以及各種確認ACK。至于每一個消息類型會攜帶什么內(nèi)容。
發(fā)布/訂閱模式解耦了發(fā)布消息的客戶（發(fā)布者）與訂閱消息的客戶（訂閱者）之間的關系，這意味著發(fā)布者和訂閱者之間并不需要直接建立聯(lián)系。
這個模式有以下好處：
發(fā)布者與訂閱者只需要知道同一個消息代理即可
發(fā)布者和訂閱者不需要直接交互
發(fā)布者和訂閱者不需要同時在線
JSON
JSON中文全稱是JavaScript對象標記語言，在這門語言中，一切都是對象。因此，任何支持的類型都可以通過JSON來表示，例如字符串、數(shù)字、對象、數(shù)組等。其語法規(guī)則是：
對象表示為鍵值對； 數(shù)據(jù)由逗號分隔； 花括號保存對象； 方括號保存數(shù)組。
JSON層次結(jié)構(gòu)簡潔清晰，易于閱讀和編寫，同時也易于機器解析和生成，有效提升網(wǎng)絡傳輸效率。
對于單片機開發(fā)者，主流的微控制器軟件開發(fā)工具Keil有提供JSON庫，可以用于STC、STM32等微控制器開發(fā)，所以在微控制器上解析JSON不需要自己寫一個JSON解析器或者移植了。
如果實在懶得使用JSON庫生成或解析，也可以直接使用C語言中的sprintf生成JSON字符串，比如：
sprintf(buf, '{\'String\':\'%s\', \'Value\':%d}', 'Hello World!', 12345);
