Ⅰ 關於stm32與伺服器通信的問題
你是想用web遠程監控單片機的運行，但是不知道怎麼把單片機的信息上傳到伺服器，轉化成web頁面展示出來，我做過一個是通過阿里雲IOT實現的
單片機內加入MQTT協議，與阿里雲伺服器通信，可以通過IOT studio快速配置生成web
官方給到歷程是都是通過ESP的WiFi來聯網。我做的是通過W5500聯網的
把c語言Link Kit SDK移植到stm32單片機中，web由IOT studio生成。
Ⅱ 嵌入式方向要學習什麼課程
1.1 有哪些設備使用單片機或Linux
所有的電子產品，所用技術都可以認為要麼是單片機，要麼是Linux；GUI方面主要是QT/Android，它們都是運行於Linux之上的。我們說的單片機不使用操作系統，但是使用單片機設備肯定遠遠超過Linux。很多人也是先學習單片機，從單片機進入電子工程師行業，日常生活中，有哪些產品使用單片機、Linux呢？下面舉一些例子：
下面我們用類比和邏輯推導出嵌入式Linux系統的組成，沒錯，「推導」。
從上圖可以知道：組成：嵌入式Linux系統= bootloader + linux內核 + 根文件系統(裡面含有APP)。
bootloader：它的目的是啟動內核，去哪等讀內核？讀到哪裡？去Flash等外設讀內核，存到內存里去。所以需要有Flash里外設的驅動能力，為了調試方便還會有網路功能。所以，可以認為 booloader = 裸機集合，它就是一個復雜的單片機程序。
Linux內核：Linux內核的最主要目的是去啟動APP，APP保存在哪裡？保存在「根文件系統」里。「根文件系統」又保存在哪裡？在Flash、SD卡等設備里，甚至可能在網路上。所以Linux內核要有這些Flash、SD卡里設備的驅動能力。
不僅如此，Linux內核還有進程調度能力、內存管理等功能。
所以：Linux內核 = 驅動集合 + 進程調度 + 內存管理等。
2.3 要學習bootloader嗎
Bootloader有很多種，常用的叫u-boot。
在實際工作中，對於u-boot基本上是修修改改，甚至不改。但是u-boot本身是很復雜的，比如為了便於調試，它支持網路功能；有些內核是保存在FAT32分區里，於是它要能解析FAT32分區，讀FAT32分區的文件。
花那麼多精力去學習u-boot，但是工作中基本用不到，這對初學者很不友善。
所以，對於初學者，我建議：理解u-boot的作用、會使用u-boot的命令，這就可以了。
如果你的工作就是修改、完善bootloader，那麼再去研究它吧。
2.4 要學習Linux內核、要學習驅動程序嗎
之前我們說過Linux內核 = 驅動集合 + 進程調度 + 內存管理等，如果要學習Linux內核，從驅動程序入手是一個好辦法。
但是人人都要學習Linux內核、人人都要學習Linux驅動嗎？顯然不是。
作為初學者，懂幾個簡單的驅動程序，有利於工作交流；理解中斷、進程、線程的概念，無論是對驅動開發、應用程序開發，都是很有好處的。
所以對於初學者，建議前期只學習這幾個驅動：LED、按鍵、中斷。
LED驅動程序：這是最簡單的驅動程序。
按鍵驅動程序：它也比較簡單，從它引入「中斷」。
中斷：從「中斷」它可以引入：休眠-喚醒、進程/線程、POLL機制、非同步通知等概念。這些概念無論是對驅動開發，還是對應用開發，都很重要。
所以，對於初學者，我建議必須學習這幾個驅動：LED、按鍵、中斷。
入門之後，如果你想從事內核開發、驅動開發，那麼可以去鑽研幾個驅動程序(輸入系統、I2C匯流排、SPI匯流排等)，掌握若干個大型驅動程序後，你對內核的套路就有所了解了，再去研究其他部分(比如進程管理、文件系統)時你會發現套路是如此通用。
攝像頭(VL42)、音效卡ALSA驅動是Linux中比較復雜的2類驅動，它們是很難的，如果工作與此相關再去研究。
2.5 要學習Linux應用程序嗎？先學一些基礎技能
要學，即使以後你只想研究內核，一些基本的應用開發編寫能力也是需要的：
基本設備的訪問，比如LCD、輸入設備
進程、線程、進程通信、線程同步與互斥
休眠-喚醒、POLL機制、信號
網路編程
①②③部分的知識，跟驅動有密切的關系，它們是相輔相承的。
掌握了基本驅動開發能力、基本應用開發能力之後，在工作中你就可以跟別人友好溝通了，不至於一臉懵逼。
2.6 應用程序是怎麼啟動的？要了解一下根文件系統
你辛辛苦苦寫出了應用程序，怎麼把它放到板子上，讓它開機就自動啟動？
你寫的程序，它依賴於哪些庫，這些庫放到板子上哪個目錄？
怎麼做一個可升級的系統？即使升級中途斷電了，也要保證程序至少還可以運行老的版本？
這些都需要我們了解一下根文件系統。
先了解一下init進程：它要讀取配置文件，根據配置文件啟動各個APP。
了解了init進程，你就了解了根文件系統的組成，就可以隨心所欲裁剪系統，為你的項目製作出最精簡的系統。
第3章 學習方法
3.1 先不要打破砂鍋問到底
嵌入式涉及的東西太多太雜了，如果心裡沒有主線，碰到什麼都要去研究個透徹，最終反而忘記自己要學什麼了。
嵌入式涉及硬體知識、軟體知識，軟體里涉及匯編、ARM架構、C語言、Makefile、Shell；又分為bootloader、內核、驅動、基本的APP、GUI。
比如我們會用到Makefile，了解它的基本規則，會用我們提供的Makefile就可以。
不需要深入研究那些make函數，因為在工作中都有現成的Makefile給你使用，不需要自己去編寫一套Makefile。何必花上好幾天去深入研究它呢？
比如我們會用到bootloader，難道又要花上幾個月來深入研究u-boot嗎？工作中基本不需要改u-boot，會用那幾個命令就可以。
甚至有些學員先去買本shell的書來學習shell命令，何必？我們在視頻中用到什麼命令，你不懂時再去網路一下這些命令就可以了。
不要脫離初學者的主線：應用基礎、驅動基礎。有了這2個基礎後，你想深入研究某部分時，再去花時間吧。
3.2 思路要清晰，不怕抄代碼
視頻里的代碼，請你一定要自己去寫一次、寫多次。為什麼我現在寫驅動那麼熟？我2009年在華清遠見上課時，
每次上課我都要給學生寫一次那些驅動，十幾次下來閉著眼睛都知道內核的套路了。
記不住那些函數？我也記不住，我都是去參考同類的驅動程序，這又不是閉卷考試。
但是要理清楚思路，你寫這個程序要完成什麼功能、怎麼實現這些功能？這個要弄清楚。
有了思路後再寫代碼，不知道怎麼寫？沒關系，看看視頻，看看示例，然後關閉視頻看看能否自己寫出來。
3.3 對自己的方向很了解，我只能帶你到這里了
我的專長是操作系統，是快速地帶領大家掌握一些項目開發的基礎知識。
如果你決定深入研究某方面時，我並不能帶你多久。你要去看源碼，去看這方面的專業書籍。
比如想深入鑽研內核的內存管理時，它有頁表映射(你需要閱讀ARM架構的手冊)、SLAB分配器、vmalloc/malloc實現、mmap實現、缺頁中斷、父進程子進程之間的頁面管理等等，內容非常多。有時候連書籍都沒有，你需要直接啃代碼。
當你想從事某個行業時，就需要深入研究行業相關的知識。
比如CAN匯流排，它可以寫成一本書：CAN協議、CAN報文、Socket CAN、車身網路拓撲結構，CAN應用報文，CAN網路管理報文，CAN診斷報文。
想做物聯網網關，需要深入研究MQTT，MQTT協議相對簡單，但是MQTT英文原版協議有130多頁，中文版有近100頁，是一本小書了。
每個行業都有自己的業務邏輯，在掌握基本的編程能力之一，你需要結合具體的業務去深入學習。
Ⅲ 物聯網開發需要什麼技術呢
物聯網開發需要的技術
一：單片機/嵌入式開發
智能硬體，哎，不就是單片機嗎?說到底就是一個微控制器，現在出現的智能手錶，調光LED燈，藍牙開鎖，WiFi插座等等，說到底不就是單片機開發嘛?單片機，電子和通信專業一般都會教51或AVR、計算機系接觸不到。現在流行的Arino也是單片機開發的一種。
但是要做一款智能硬體，技術上只會單片機編程還是不行的。哎呀嘛什麼智能硬體，本質上就是一個電子產品!。所以你要開發一款能拿得出手的智能硬體，電子系統設計必須要會的!
二：網路通信協議
智能硬體與傳統的電子產品最大的差別，就是智能硬體連上了網路。要連上網路，就需要用到網路通信模塊及學習網路通信協議——TCP/IP。
TCP/IP是一個技術的總稱，裡麵包含兩種協議TCP、UDP，位於網路通信分層模型的傳輸層，同時也是由操作系統管理。而HTTP、DNS、URI等這些技術，屬於應用層，位於TCP/UDP之上。同樣，最近物聯網比較流行的，針對計算能力有限的通訊設備而出的MQTT協議，也屬於TCP之上。
為了讓電子產品有聯網的能力，只要在電路設計上給主控晶元連接一個通信模塊，寫好收發網路指令的代碼，剩下的就是電子產品設計了。
三：服務端開發框架
Client/Server架構，即客戶端/伺服器架構。智能硬體連上後台伺服器後，其就是一個客戶端，一個終端。由於單片機中資源受限，實際上是不太可能用HTTP協議的，所以互聯網中通用的Web伺服器開發並不適合這里。有的廠家會在TCP之上自定義協議，有的就移植別人做好的協議比如MQTT，CoAP等等。
服務端開發就比較復雜了。單片機/嵌入式軟體開發還好，只要學習好C語言即可打遍天下無敵手，而服務端開發，用Java呢還是Python還是PHP?反正Java和Python選一個就好了，嵌入式出身的工程師，一般都會學Python。
Python伺服器端的開發框架種類繁多，Web開發的有Django、FlaskTornado WebServer，TCP伺服器可以用Twisted，等等。MQTT有已經做好的伺服器，像這樣的伺服器不用自己開發，直接部署即可。
Ⅳ 學習物聯網應用工程師有什麼要求
要想成為系統的的物聯網工程師需要系統學習。由淺入深地對嵌入式物聯網技術以及Linux平台全面掌握，能夠獨立勝任物聯網開發、嵌入式Linux應用開發、5G周邊產品開發、底層系統開發、設備驅動開發、從終端到雲技術開發以及Linux衍生產品等多方面工作。可以更加系統的了解嵌入式物聯網相關行業知識。具體所學知識包括：1.嵌入式C語言高級編程及行業應用2.各常用數據結構與演算法相關知識，以及面向介面的編程3.GUI圖形庫應用開發技術4.Linux操作系統使用5.Linux系統編程6.Linux系統網路編程7.Linux網路路由及數據交換技術8.嵌入式資料庫9.嵌入式C++語言編程，以及面向模板庫的應用開發10.OpenCV、OpenGL等圖像處理11.AI模型訓練及場景定位識別應用12.RFID場景應用13.zigbee低功耗網路技術14.Bluebooth組網技術15.MQTT雲平台搭建技術16.NB-IOT各大雲平台通信技術17.基於5G技術的嵌入式物聯網行業應用18.ARM體系結構19.Bootloader啟動過程20.常見Bootloader源碼及平台移植21.嵌入式Linux內核裁減以及移植 22.嵌入式Linux平台搭建技術及技巧
Ⅳ MQTT和Websocket的區別是什麼
簡單回答一下, MQTT ( MQ Telemetry Transport ) 是針對物聯網而設計的, 如手機對家裡的智能開關, 而 WebSocket 是針對瀏覽器與伺服器之間而設計的. 兩者基本上是兩個世界的東西.
MQTT 只是一個介面, 讓兩個 "物件" 能夠透過 TCP 協議通訊, 但並沒有規定(在應用層面上)通訊中要怎樣"對答", 如 pop3 郵件伺服器會有:
S: 220 我是 xxx 伺服器
C: HELO myServer
S: 250 Nice to meet you
C: auth login
....
這些是沒有硬性被定義的, 兩個 "物件" 之間要怎麼"聊天", 由你自己來定.
WebSocket 則是一個 http 協議中的伸延 (先這麼理解吧!), 而 http 協議, 基本上就是一個請求, 一個回答, 然後就自動掛線, 客端和伺服器端不會婆婆媽媽. 但即使就前面說的, 一問一答, 當中便有大量的 header 字串來往, 如果要處理串流這樣大的數據再 + 一大堆 header, 這樣就是很龐大的負擔, websocket 就開了這個婆媽之門, 客端和伺服器端可以以 full plex 的形式做大量 binary 的數據傳輸, 決省了一大堆 header, 其中一些安全機制也保證了大堆資料不被搞亂. 但無論如何, WebSocket 離不開 HTTP!!!
以上, 只是很概念的說法, 便於你理解, 詳細你得自己翻下文獻了.
Ⅵ 如何在windows上用C語言實現MQTT協議
C語言是一門通用計算機編程語言，廣泛應用於底層開發。C語言的設計目標是提供一種能以簡易的方式編譯、處理低級存儲器、產生少量的機器碼以及不需要任何運行環境支持便能運行的編程語言。
盡管C語言提供了許多低級處理的功能，但仍然保持著良好跨平台的特性，以一個標准規格寫出的C語言程序可在許多電腦平台上進行編譯，甚至包含一些嵌入式處理器(單片機或稱MCU)以及超級電腦等作業平台。
二十世紀八十年代，為了避免各開發廠商用的C語言語法產生差異，由美國國家標准局為C語言制定了一套完整的美國國家標准語法，稱為ANSI C，作為C語言最初的標准。 目前2011年12月8日，國際標准化組織(ISO)和國際電工委員會(IEC)發布的C11標準是C語言的第三個官方標准，也是C語言的最新標准，該標准更好的支持了漢字函數名和漢字標識符，一定程度上實現了漢字編程。
C語言是一門面向過程的計算機編程語言，與C++，Java等面向對象的編程語言有所不同。
其編譯器主要有Clang、GCC、WIN-TC、SUBLIME、MSVC、Turbo C等。
Ⅶ 3. MQTT簡要介紹
——
[1.MQTT項目工程](https://github.com/LiamBindle/MQTT-C)
[2.MQTT API說明文檔](https://liambindle.ca/MQTT-C/group__api.html)
[3.MQTT協議中文版](https://mcxiaoke.gitbooks.io/mqtt-cn/content/mqtt/01-Introction.html)
MQTT是一個客戶端服務端架構的發布/訂閱模式的消息傳輸協議。它的設計思想是輕巧、開放、簡單、規范，易於實現。這些特點使得它對很多場景來說都是很好的選擇，特別是對於受限的環境如機器與機器的通信（M2M）以及物聯網環境（IoT）。
MQTT協議通過交換預定義的MQTT控制報文來通信。
報文格式: 固定包頭+可變包頭+payload。
固定包頭: 由兩個位元組組成
byte1 高四位表示控制報文的類型，低四位表示控制報文類型的標志位。
byte2表示剩餘長度，包括可變報頭和負載的數據。剩餘長度不包括用於編碼剩餘長度欄位本身的位元組數。
可變包頭：
某些MQTT控制報文包含一個可變報頭部分。它在固定報頭和負載之間。可變報頭的內容根據報文類型的不同而不同。可變報頭的報文標（Packet Identifier）欄位存在於在多個類型的報文里。
有效載荷：
對於PUBLISH來說有效載荷就是應用消息。
——1. 網路建立連接後，客戶端發送的第一個報文必須是CONNECT報文
——2. 客戶端只能發送一次CONNECT 報文，發送兩次會當作協議違規處理，並斷開連接。
——3. 有效載荷包括：客戶端唯一標識符，will主題，will消息，用戶名和密碼。
——4.可變包頭：協議名（protocol name）+協議級別（protocol level）+連接標志（connect flags）+保持連接（keep alive）。
——5. 協議名： MQTT的UTF-8編碼的字元串。(MSB+LSB +MQTT 六個位元組)
——6. 協議級別：一個位元組
——7. 連接標志：一個位元組，包含一些用於指定MQTT連接行為的參數。同時還指出有效載荷中的欄位是否存在。服務端必須驗證CONNECT控制報文的保留標志位（第0位）是否為0，如果不為0必須斷開客戶端連接。
——8. 清理會話：byte8 的bit1位標志。
這個二進制位指定了會話狀態的處理方式。客戶端和服務端可以保存會話狀態，以支持跨網路連接的可靠消息傳輸。這個標志位用於控
制會話狀態的生存時間。
標志設置為0：服務端必須基於當前會話（使用客戶端標識符識別）的狀態恢復與客戶端的通信。
標志設置為1：客戶端和服務端必須丟棄之前的任何會話並開始一個新的會話。會話僅持續和網路連接同樣長的時間。
——9. 遺囑標志 WILL FLAG: byte8的bit2位標志。
遺囑標志（Will Flag）被設置為1，表示如果連接請求被接受了，遺囑（Will Message）消息必須被存儲在服務端並且與這個網路連接關聯。之後網路連接關閉時，服務端必須發布這個遺囑消息，除非服務端收到DISCONNECT報文時刪除了這個遺囑消息。
服務端發送CONNACK報文響應從客戶端收到的CONNECT報文。服務端發送給客戶端的第一個報文必須是CONNACK。
如果客戶端在合理的時間內沒有收到服務端的CONNACK報文，客戶端應該關閉網路連接。合理 的時間取決於應用的類型和通信基礎設施。
CONNACK報文沒有有效載荷。
PUBLISH控制報文是指從客戶端向服務端或者服務端向客戶端傳輸一個應用消息。
固定包頭：
注意byte1的bit3為重發標志DUP。
如果DUP標志被設置為0，表示這是客戶端或服務端第一次請求發送這個PUBLISH報文。如果DUP標志被設置為1，表示這可能是一個早前報文請求的重發。
服務端發送PUBLISH報文給訂閱者時，收到（入站）的PUBLISH報文的DUP標志的值不會被傳播。發送（出站）的PUBLISH報文與收到（入站）的PUBLISH報文中的DUP標志是獨立設置的，它的值必須單獨的根據發送（出站）的PUBLISH報文是否是一個重發來確定。
可變包頭：
主題名 :topic name
報文標識符 ：packet identitfier。
有效載荷 ：有效載荷包含將被發布的應用消息。數據的內容和格式是應用特定的。有效載荷的長度這樣計算：用固定報頭中的剩餘長度欄位的值減去可變報頭的長度。包含零長度有效載荷的PUBLISH報文是合法的。
響應：PUBLISH報文的接收者必須按照根據PUBLISH報文中的QoS等級發送響應。
PUBACK報文是對QoS 1等級的PUBLISH報文的響應。
PUBACK報文沒有有效載荷。
PUBREC報文是對QoS等級2的PUBLISH報文的響應。它是QoS 2等級協議交換的第二個報文。
PUBREC報文沒有有效載荷。
PUBREL報文是對PUBREC報文的響應。它是QoS 2等級協議交換的第三個報文。
PUBREL報文沒有有效載荷。
PUBCOMP報文是對PUBREL報文的響應。它是QoS 2等級協議交換的第四個也是最後一個報文。
PUBCOMP報文沒有有效載荷。
客戶端向服務端發送 SUBSCRIBE 報文用於創建一個或多個訂閱。每個訂閱注冊客戶端關心的一個或多個主題。為了將應用消息轉發給與那些訂閱匹配的主題，服務端發送PUBLISH報文給客戶端。SUBSCRIBE報文也（為每個訂閱）指定了最大的QoS等級，服務端根據這個發送應用消息給客戶端。
有效載荷：
SUBSCRIBE報文的有效載荷包含了一個主題過濾器列表，它們表示客戶端想要訂閱的主題。SUBSCRIBE報文的有效載荷必須包含至少一對主題過濾器 和 QoS等級欄位組合。沒有有效載荷的SUBSCRIBE報文是違反協議的。
響應：
服務端收到客戶端發送的一個SUBSCRIBE報文時，必須使用SUBACK報文響應，SUBACK報文必須和等待確認的SUBSCRIBE報文有相同的報文標識符。
服務端發送SUBACK報文給客戶端，用於確認它已收到並且正在處理SUBSCRIBE報文。SUBACK報文包含一個返回碼清單，它們指定了SUBSCRIBE請求的每個訂閱被授予的最大QoS等級。
有效載荷：
有效載荷包含一個返回碼清單。每個返回碼對應等待確認的SUBSCRIBE報文中的一個主題過濾器。返回碼的順序必須和SUBSCRIBE報文中主題過濾器的順序相同。
客戶端發送UNSUBSCRIBE報文給服務端，用於取消訂閱主題。
有效載荷 ：
UNSUBSCRIBE報文的有效載荷包含客戶端想要取消訂閱的主題過濾器列表。
UNSUBSCRIBE報文中的主題過濾器必須是連續打包的、按照定義的UTF-8編碼字元串
UNSUBSCRIBE報文的有效載荷必須至少包含一個消息過濾器。沒有有效載荷的UNSUBSCRIBE報文是違反協議的。
響應：
UNSUBSCRIBE報文提供的主題過濾器（無論是否包含通配符）必須與服務端持有的這個客 戶端的當前主題過濾器集合逐個字元比較。如果有任何過濾器完全匹配，那麼它（服務端）自己的訂閱將被刪除，否則不會有進一步的處理。
如果服務端刪除了一個訂閱：
——它必須停止分發任何新消息給這個客戶端 []。
——它必須完成分發任何已經開始往客戶端發送的QoS 1和QoS 2的消息 []。
——它可以繼續發送任何現存的准備分發給客戶端的緩存消息。
服務端必須發送UNSUBACK報文響應客戶端的UNSUBSCRIBE請求。UNSUBACK報文必須包含和UNSUBSCRIBE報文相同的報文標識符 。即使沒有刪除任何主題訂閱，服務端也必須發送一個UNSUBACK響應 。
如果服務端收到包含多個主題過濾器的UNSUBSCRIBE報文，它必須如同收到了一系列的多個UNSUBSCRIBE報文一樣處理那個報文，除了將它們的響應合並到一個單獨的UNSUBACK報文外。
服務端發送UNSUBACK報文給客戶端用於確認收到UNSUBSCRIBE報文。
UNSUBACK報文沒有有效載荷。
客戶端發送PINGREQ報文給服務端的。用於：
1. 在沒有任何其它控制報文從客戶端發給服務的時，告知服務端客戶端還活著。
2. 請求服務端發送 響應確認它還活著。
3. 使用網路以確認網路連接沒有斷開。
保持連接（Keep Alive）處理中用到這個報文。
——PINGREQ報文沒有可變報頭。
——PINGREQ報文沒有有效載荷。
響應：
服務端必須發送 PINGRESP報文響應客戶端的PINGREQ報文。
服務端發送PINGRESP報文響應客戶端的PINGREQ報文。表示服務端還活著。
保持連接（Keep Alive）處理中用到這個報文。
PINGRESP報文沒有可變報頭。
PINGRESP報文沒有有效載荷。
DISCONNECT報文是客戶端發給服務端的最後一個控制報文。表示客戶端正常斷開連接。
DISCONNECT報文沒有可變報頭。
DISCONNECT報文沒有有效載荷。
響應：
客戶端發送DISCONNECT報文之後：
—— 必須關閉網路連接 [MQTT-3.14.4-1]。
——不能通過那個網路連接再發送任何控制報文。
服務端在收到DISCONNECT報文時：
——必須丟棄任何與當前連接關聯的未發布的遺囑消息。
——應該關閉網路連接，如果客戶端 還沒有這么做。
為了提供服務質量保證，客戶端和服務端有必要存儲會話狀態。在整個會話期間，客戶端和服務端都必須存儲會話狀態 。會話必須至少持續和它的活躍網路連接同樣長的時間。服務端的保留消息不是會話狀態的組成部分。服務端應該保留那種消息直到客戶端刪除它。
MQTT協議要求基礎傳輸層能夠提供有序的、可靠的、雙向傳輸（從客戶端到服務端 和從服務端到客戶端）的位元組流。
無連接的網路傳輸協議如UDP是不支持的，因為他們可能會丟失數據包或對數據包重排序。
MQTT按照這里定義的服務質量 (QoS) 等級分發應用消息。分發協議是對稱的，在下面的描述中，客戶端和服務端既可以是發送者也可以是接收者。分發協議關注的是從單個發送者到單個接收者的應用消息。服務端分發應用消息給多個客戶端時，每個客戶端獨立處理。分發給客戶端的出站應用消息和入站應用消息的QoS等級可能是不同的。
qos0：最多分發一次
qos1：至少分發一次
qos2：僅分發一次
客戶端設置清理會話（CleanSession）標志為0重連時，客戶端和服務端必須使用原始的報文標識符重發任何未確認的PUBLISH報文（如果QoS>0）和PUBREL報文 [MQTT-4.4.0-1]。這是唯一要求客戶端或服務端重發消息的情況。
服務端接管入站應用消息的所有權時，它必須將消息添加到訂閱匹配的客戶端的會話狀態。正常情況下，客戶端收到發送給它的訂閱的消息。客戶端也可能收到不是與它的訂閱精確匹配的消息。如果服務端自動給客戶端分配了一個訂閱，可能發生這種情況。正在處理UBSUBSCRIBE請求時也可能收到消息。客戶端必須按照可用的服務質量（QoS）規則確認它收到的任何PUBLISH報文，不管它選擇是否處理報文包含的應用消息 。
實現本章定義的協議流程時，客戶端必須遵循下列規則：
重發任何之前的PUBLISH報文時，必須按原始PUBLISH報文的發送順序重發（適用於QoS 1和QoS 2消息）[MQTT-4.6.0-1]。
——必須按照對應的PUBLISH報文的順序發送PUBACK報文（QoS 1消息）。
——必須按照對應的PUBLISH報文的順序發送PUBREC報文（QoS 2消息。
——必須按照對應的PUBREC報文的順序發送PUBREL報文（QoS 2消息）。
服務端必須默認認為每個主題都是有序的。它可以提供一個管理功能或其它機制，以允許將一個或多個主題當作是無序的 。
服務端處理發送給有序主題的消息時，必須按照上面的規則將消息分發給每個訂閱者。此外，它必須按照從客戶端收到的順序發送PUBLISH報文給消費者（對相同的主題和QoS）。
斜杠（『/』 U+002F）用於分割主題的每個層級，為主題名提供一個分層結構.
數字標志（『#』 U+0023）是用於匹配主題中任意層級的通配符。
加號 (『+』 U+002B) 是只能用於單個主題層級匹配的通配符。
服務端不能將 $ 字元開頭的主題名匹配通配符 (#或+) 開頭的主題過濾器.
$SYS/ 被廣泛用作包含伺服器特定信息或控制介面的主題的前綴。
應用不能使用 $ 字元開頭的主題。
訂閱 「#」 的客戶端不會收到任何發布到以 「$」 開頭主題的消息。
訂閱 「+/monitor/Clients」 的客戶端不會收到任何發布到 「$SYS/monitor/Clients」 的消息。
訂閱 「$SYS/#」 的客戶端會收到發布到以 「$SYS/」 開頭主題的消息。
訂閱 「$SYS/monitor/+」 的客戶端會收到發布到 「$SYS/monitor/Clients」 主題的消息。
如果客戶端想同時接受以 「$SYS/」 開頭主題的消息和不以 $ 開頭主題的消息，它需要同
時訂閱 「#」 和 「「$SYS/#」。
除非另有說明，如果服務端或客戶端遇到了協議違規的行為，它必須關閉傳輸這個協議違規控制報文的網路連接.
MQTT方案通常部署在不安全的通信環境中。在這種情況下，協議實現通常需要提供這些機制：
——用戶和設備身份認證
——服務端資源訪問授權
——MQTT控制報文和內嵌應用數據的完整性校驗
——MQTT控制報文和內嵌應用數據的隱私控制
作為傳輸層協議，MQTT僅關注消息傳輸，提供合適的安全功能是實現者的責任。使用TLS[RFC5246] 是比較普遍的選擇。
廣泛採用高級加密標准 [AES] 數據加密標准 [DES] 。
推薦使用為受限的低端設備特別優化過的輕量級加密國際標准 ISO 29192 [ISO29192] 。
如果MQTT在WebSocket [RFC6455] 連接上傳輸，必須滿足下面的條件：
——MQTT控制報文必須使用WebSocket二進制數據幀發送。如果收到任何其它類型的數據幀，接收者必須關閉網路連接 。
——單個WebSocket數據幀可以包含多個或者部分MQTT報文。接收者不能假設MQTT控制報文按WebSocket幀邊界對齊 。
——客戶端必須將字元串 mqtt 包含在它提供的WebSocket子協議列表裡 。
——服務端選擇和返回的WebSocket子協議名必須是 。
——用於連接客戶端和伺服器的WebSocket URI對MQTT協議沒有任何影響。
MQTT規范定義了MQTT客戶端實現和MQTT服務端實現的一致性要求
MQTT實現可以同時是MQTT客戶端和MQTT服務端。接受入站連接和建立到其它服務端的出站連接的服務端必須同時符合MQTT客戶端和MQTT服務端的要求 。
為了與任何其它的一致性實現交互操作，一致性實現不能要求使用在本規范之外定義的任何擴展 。
附錄：
控制報文類型
byte1：標志位flags：
Ⅷ 關於mosquitto怎麼用c語言實現消息的訂閱和發送（mqtt）
1.目標：測試Mosquitto使用MQTT協議發消息的相關性能指標，包含發送速度，並發負載能力，資源佔用，消息到達率。
2.MQTT協議簡介：
1).建立長連接。客戶端發起請求和服務端建立長連接，建立成功後，服務端會返回ACK(CONNACK)
2).客戶端訂閱：客戶端發起訂閱，訂閱成功後，服務端會返回ACK(SUBACK)
3).發消息：發布者會給服務端發消息，服務端在把消息給合適的客戶端。
Qos=0(服務質量)：客戶端消息收到後，不會發出ACK給服務端(PUBACK)。
Qos =1:服務端會發ACK給發布者，客戶端收到消息後會發ACK給服務端。
4).取消訂閱：客戶端發起取消訂閱，服務端返回ACK(UNSUBACK)
5)Pingreq&Pingresp:客戶端和服務端會保持心跳。
3.存在問題：
1. 如何模擬出40W的用戶
2. 如何長連接，訂閱，發消息，取消訂閱，Pingreq行為如何實現。
4. python開源庫 Mosquitto.py，解決所有問題
1. 模擬40W用戶
a)可以使用虛擬機和Mosquitto.py實現，具體為：一般一台虛擬機最多是6W+的模擬數據（需要修改句柄數，我使用5W），方法是Client_id可以簡單的做出5W個來，然後調用Mosquitto裡面的connect方法，建立長連接。准備8台虛擬機就可以實現40W客戶端的模擬
2.行為的模擬
a)訂閱：Mosquitto.subscribe / 發消息：Mosquitto.publish / 取消訂閱：Mosquitto.unsubscribe。 簡單一句話 Mosquitto庫實現所有的行為.
5. 指標：發送速度，到達率，並發負載，資源佔用。
a. 發送速度：服務端日誌記錄，分析解決
b. 到達率： 1.客戶端記錄下收到消息，分析計算。2.計算服務端收到的PUBACK（客戶端收到消息返回的ACK），進行計算
c. 並發負載：5W 用戶不斷增加，注意觀察服務端的負載情況。
e.資源佔用：其實主要是cpu/mem/帶寬：cpu多核的話需要觀察top命令下的_id欄位, mem可以觀察free -h命令的剩餘mem, 帶寬可以使用mpstat進行觀察
6. 可以遇見問題：
a. 模擬客戶端的虛擬機需要修改句柄數才能支持5W的客戶端模擬數量
b. 要先吃透MQTT協議的流程，吃透了進行測試會非常的方便
c. Clear session，設置為true則不為客戶端保留休息，設置為false保留消息。其實就是客戶端離線後在連接上可以收到之前推出的消息。
Ⅸ 物聯網工程師需要學習什麼技術
物聯網工程師需要掌握：物聯網產業與技術導論、物聯網工程概論、、Java程序設計、單片機原理及應用、無線感測網路概論、移動通信技術、蜂窩物聯網技術等技術。
物聯網是基於互聯網、廣播電視網、傳統電信網等信息承載體，讓所有能夠被獨立定址的普通物理對象實現互聯互通的網路又稱為物聯網域名。
物聯網理念最早可追溯到比爾·蓋茨1995年《未來之路》一書。在《未來之路》中，比爾·蓋茨已經提及物互聯，只是當時受限於無線網路、硬體及感測設備的發展，並未引起重視。
(9)c語言mqtt擴展閱讀：
物聯網專業畢業生需掌握的知識與技能：
1、掌握和計算機科學與技術相關的基本理論知識；掌握物聯網工程的分析和設計的基本方法。
2、了解文獻檢索、資料查詢的基本方法，具有一定的科學研究和實際工作能力。
3、了解與物聯網工程有關的法規。
4、能夠運用學習知識和外文閱讀能力查閱外文資料。
5、掌握文獻檢索、資料查詢的基本方法，具有獲取信息的能力。
參考資料來源：網路—物聯網工程專業