『壹』 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!!!
以上, 只是很概念的說法, 便於你理解, 詳細你得自己翻下文獻了.
『貳』 如何通過php實現mqtt協議
MQTT是一個輕量級的消息發布/訂閱協議，它是實現基於手機客戶端的消息推送伺服器的理想解決方案。
我們可以從這里下載該項目的實例代碼，並且可以找到一個採用PHP書寫的伺服器端實現。
架構如下所示：
『叄』 MQTT 基本認知
物聯網 (internet of thing) ，表示的是可以把一些帶某些感測器的設備(終端)，接入到互聯網的行為。
通過互聯網連接這些設備，這些設備就能夠互相協作。
而 MQTT 就是這些設備之間數據通信的一個基於 TCP/IP 的協議。
每個終端都和實現了 MQTT 協議的代理/伺服器相連。
通過 published MQTT 代理伺服器的某個 主題 發送數據。
通過 subscription 從 MQTT 代理伺服器獲取自己訂閱的 主題 數據。
MQTT 協議是一種輕量級的、靈活的網路協議。並且非常適合 IOT 的場景。
大多數開發人員已經熟悉了 HTTP WEB 協議。那麼為什麼不讓 IOT 設置鏈接到 WEB 服務？
設備可以採用 HTTP 請求的形式發送數據，並採用 HTTP 響應的形式從伺服器獲取數據，接受更新。
因為對於 IOT 的設備來說，這種 主動請求--> 被動等待應答的 數據傳輸模型存在嚴重的局限性：
那麼，MQTT 為什麼如此輕便且靈活？MQTT 協議的一個關鍵的特性是 發布/訂閱模型 。它將數據的發布者和接受者分離。
一個設備終端既可以是數據的發布者 (published) 也可以是數據的訂閱者 (subscription) 。
一個設備如果要發布數據，只需要往代理伺服器中 相應的主題發布數據內容即可。
一個設備如果需要接受到數據，只需要在代理伺服器中， 提前訂閱自己需要關注的主題即可。
MQTT 最基本的體驗，就是使用 mosquitto 。
Mosquitto是一款實現了 MQTT v3.1 協議的開源消息代理軟體，提供輕量級的，支持發布/訂閱的的消息推送模式，使設備對設備之間的短消息通信簡單易用。
它可以理解成一個 MQTT 的代理伺服器。
基本步驟如下：
安裝成功截圖
使用 brew services start mosquitto 啟動 MQTT 服務
運行截圖
然後再打開另外兩個終端窗口，模擬兩個IOT設備。A 訂閱 MQTT 服務。B 向 MQTT 的服務發送數據。
A訂閱當前MQTT的某個服務。
B向 MQTT 伺服器發布(published) 數據。
然後，我們就可以在A控制台里看到由 B 通過 MQTT 服務發送的數據了。
基本流程圖
控制台 A 向 MQTT 伺服器訂閱 dw/demo 服務，並被動的等待 MQTT 伺服器返回數據。
控制台 B 主動的向 MQTT 伺服器的 dw/demo 服務發送 published 數據，之後。伺服器會主動向事先訂閱了 dw/demo 的終端分發此消息。
MQTT 是一種鏈接協議，它指定了如何組織數據位元組並通過 TCP/IP 網路傳輸它們。但實際上，開發人員並不需要鏈接這個鏈接協議的具體細節。我們只需要知道，每條消息都有一個命令和數據有效負載。該命令定義消息類型(比如 CONNECT 消息或者 SUB SCRIBE 消息)。所有的 MQTT 庫和工具都提供了直接處理這些消息的基本方法，並且能自動填充一些必要的欄位(在數據包的對應位元組填充)，比如消息和客戶端 ID。
首先客戶端發送一條 CONNECT消息 來鏈接代理。CONNECT 消息要求建立從客戶端到代理伺服器的鏈接。
CONNECT 命令的基本參數
當客戶端向代理伺服器發送一條 CONNECT 命令之後，伺服器會調用 CONNACK 命令，告知服務鏈接的狀態。
CONNACK 命令的基本參數
當客戶端和伺服器建立連接之後，客戶端就可以向伺服器訂閱某些主題的。(發送一條或多條 SUBSCRIBE消息 )。
表明當伺服器接受到其他終端推送的此主題數據時，伺服器會默認發送給它。
SUBSCRIBE 參數列表
當客戶端成功的向伺服器訂閱某個主題之後，伺服器會返回一條 SUBACK 的消息，其中包含一個或者多個 returnCode 參數。
SUBACK消息參數
returnCode : 值 0 - 2 ，表示成功訂閱，並返回這個訂閱消息的 QOS。值 128 ： 訂閱失敗。
既然客戶端可以向伺服器訂閱某個主題，當然也可以取消訂閱。
與 SUBSCRIBE 訂閱命令相反的命令是 UNSUBSCRIBE 取消訂閱命令。
此命令非常簡單。只有一個topic(主題)參數。
上面講的是訂閱，訂閱是需要有消息從伺服器發送過來的。但是伺服器本身基本不產生數據，那數據從何而來呢？
通過另外一個客戶端執行 PUBLISH 命令，往代理伺服器發送數據。並最終通過代理伺服器將數據傳遞給訂閱了此服務的客戶端。
PUBLISH 消息參數
對於 MQTT 的一張基本理解圖
基本流程圖：
最後總結
參考資料： 初識 MQTT
『肆』 【內部分享】MQTT協議解讀及使用經驗
時間：2018-07-26
Q: 什麼是網路連接？
A: 網路連接是傳輸層定義的概念，在傳輸層以下只存在網路數據包的相互交換。
所謂連接，其實也不是在網路上有一條真實存在的數據通道。只要通信雙方在一段時間內持續保持數據包交換，就可以視為雙方建立的連接並沒有斷開。
連接的建立是依託於TCP協議的三次握手，一旦連接已經建立完畢，通信雙方就可以復用這條虛擬通道進行數據交換。如果連接保持長時間工作一直沒有被中斷，那麼這樣的TCP連接就俗稱為長連接。
Message Queue Telemetry Transport ，中文直譯： 消息隊列遙測傳輸協議 。
在MQTT協議被設計出來的年代，還沒有物聯網這么時髦的詞彙，當年叫做 遙測設備 。
MQTT協議真正開始聲名鵲起的原因，是其正好恰恰踩中移動互聯網發展的節拍，為消息推送場景提供了一個既簡便又具有良好擴展性的現成解決方案。
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
可以看出，MQTT對消息頭的規定十分精簡， 固定頭部佔用空間大小僅為1個位元組 ，一個最小的報文佔用的空間也 只有兩個位元組 （帶一位元組的長度標識位）。
這也是MQTT協議針對不穩定及帶寬低下的網路環境做出的特定設計 - - - - 盡可能地節省一切不必要的網路開銷 。
Q：為什麼MQTT協議需要心跳報文(PINGREQ, PINGRESP)來維護連接狀態，只監控該TCP的連接狀態是否可以實現目的？
A: TCP數據傳輸默認的超時時間過長，不符合應用層上細粒度的要求。
TCP數據傳輸超時的情況可分成三種： 服務端斷開 、 客戶端斷開 、 中間網路斷開 。
在前兩種場景下，若斷開操作是一方主動發起的，即表示為TCP連接正常結束，雙方走四次揮手流程；若程序異常結束，則會觸發被動斷開事件，通信另一方也能立刻感知到本次連接所打開的 Socket 出現中斷異常。
唯獨中間網路的狀態是通信雙方不能掌握的。 在Linux系統下 ，TCP的連接超時由內核參數來控制，如果通信中的一方沒有得到及時回復，默認會主動再嘗試 6次 。如果還沒有得到及時回應，那麼其才會認定本次數據超時。
連帶首次發包與六次重試，Linux系統下這7次發包的超時時間分別為 2的0次方 至 2的6次方 ，即1秒、2秒、4秒、8秒、16秒、32秒、64秒，一共127秒。MQTT協議認為如此長的超時時間對應用層而言粒度太大，因此其在應用層上還單獨設計屬於自身的心跳響應控制。常見的MQTT連接超時多被設定為 60秒 。
擴展知識 - TCP的KeepAlive機制： http://hengyunabc.github.io/why-we-need-heartbeat/
由通信中的 報文標識符 ( Packet Identifier )傳達。
Q：僅Publish與Pubrec能保證消息只被投遞一次嗎？
A： 業務上可以實現，但MQTT協議並沒有如此設計，原因如下：
每個消息都會擁有屬於自己的報文標識符，但如果需要兩次數據交換就實現消息僅只收到一次，就需要通信雙方記錄下每次使用的報文標識符，並且在處理每一條消息時都需要去重處理，以防消息被重復消費。
但MQTT協議最初被設計的工作對象是輕量級物聯設備，為此在協議的設計中報文標識符被約定為 可重用 ，以減少對設備性能的消耗，換回的代價不得不使用四次網路數據交換，才能確保消息正好被消費一次。
Q：兩個不同客戶端在發布與訂閱同一Topic下的消息時，都可以提出通信Qos要求，此時以哪項為基準？
A： 偽命題，故意在分享時埋下坑，等人來踩。
兩個不同客戶端的通信是需要 Broker 進行中轉，而不是直連。因此，通信中存在兩個不同的會話，雙方的Qos要求僅僅作用於它們與 Broker 之間的會話，最終的Qos基準只會向最低要求方看齊。
例：遺囑消息的正確使用方式可參考此篇文章： https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament
雖然可以藉助 Retain Message 實現綁定一條消息至某個Topic，以達到消息的暫時保留目的。
但首先 Retain Message 並不是為存儲場景而設計的，再次MQTT協議並沒有對消息的持久化作出規定，也就是說Broker重啟後，現有保留消息也將丟失。
Q：兩種特殊消息的使用場景？
A： 遺囑消息，多用於客戶端間獲取互相之間異常斷線的消息通知；
保留消息，可保存 最近一條 廣播通知，多用於公告欄信息的發布。
Eclipse Mosquitto ：MQTT協議的最小集實現
有 EMQ , HiveMQ , RabbitMQ MQTT Adapter 等。
Qos=2 消息保障的網路I/O次數過多，如果不是必需，盡少在程序里使用此類消息。
畢竟當初其設計的目的是為了減少設備的性能佔用，但若應用場景並不是物聯網，而是用於手機、電腦或瀏覽器端等現在已不缺性能的設備上，最好在報文體中，使用UUID生成全局唯一的消息ID，然後自行在業務解析中判斷此報文是否被消費過。
或者，業務方在處理消息時保證其被消費的冪等性，也可消除重復消息對系統帶來的影響。
正如MQTT協議並沒有依賴TCP連接狀態，自己在應用層協議上實現心跳報文來控制連接狀態，業務方作為MQTT協議的使用者，也不要完全依賴協議的工作狀態，而是依託MQTT協議建立屬於業務本身的信息匯報機制，以加強系統的穩健性。
Retain Message 可視為客戶端主動拉取的行為。如果業務系統採用 HTTP+MQTT 雙協議描述業務過程，主動拉取的操作也可使用 HTTP 請求替代。
作為一個長連接型的應用，上線前需要根據業務量級，評估對操作系統 埠數 與 文件描述符 的佔用要求，以防伺服器資源被打滿。
在服務端的配置文件和客戶端的連接參數中，都擁有 max_inflight_messages 此項配置，來維護 Qos=1 or 2 消息是否被成功消費的狀態。
MQTT 最初被設計為物聯網級的通信協議，因此此參數的默認配額較小（大多數情況下被限制到10至20）。
但如果將MQTT協議應用至手機、PC或Web端的推送場景時，硬體性能已不在是瓶頸，在實際使用中推薦把此參數調大。
Mosquitto提供Bridge功能，需要我們自己配置。
Bridge 意為橋接，當我們把兩台Broker橋接在一起時，只需要修改一台Broker的配置，填上另一台Broker的運行地址。前一台Broker將作為客戶端發布與訂閱後一台Broker的所有Topic，實現消息互通的目的。
橋接帶來的問題有以下幾點：
我的建議：
Websockets協議被設計的目的是為瀏覽器提供一個全雙工的通信協議，方便實現消息推送功能。
在Websockets協議被設計出來前，受限於HTTP協議的一問一答模型，消息的推送只能靠輪詢來實現，在資源消耗與時效性保障上，均難以達到令人滿意的效果。
Websockets協議復用了HTTP協議的頭部信息，告知瀏覽器接下來的操作將觸發協議升級，然後通信雙方繼續復用HTTP的Header，但報文內容已轉變為雙方均接受的新協議的格式。
Websockets協議改進了網頁瀏覽中的消息推送的方式，因此被廣泛應用在聊天、支付通知等實時性要求比較高的場合下。
MQTT協議重點在於 消息隊列的實現，其對消息投遞的方式作出約定，並提供一些額外的通信保障 。
MQTT可採取原生的TCP實現，也有基於Websockets的實現版本。當然後者在網路位元組的利用率上，不如前者那麼精簡。但瀏覽器端無法直接使用TCP協議，所以就只能基於Websockets協議開發。
不過基於Websockets的應用也有方便之處：一是證書不需要額外配置，直接與網站共用一套基礎設施；二是可使用 Nginx 等工具管理流量，與普通HTTP流量可共用一套配置方法。
MQTT非常適合入門，原因如下：
實際的應用場景遠比理想中的復雜，無法一招走遍天下，必須做好取捨。
MQTT協議在這方面做得很優秀，以後工作中可以作為參考，設計好自己負責的業務系統。
『伍』 web 物聯網用什麼開發
物聯網中最常用的編程語言，即Java，C，C ++，Python，JavaScript和Go。
Java：物聯網技術最流行的編程語言
Java有多個應用領域，從後端編程到Android的移動應用。根據 Eclipse基金會執行的2017年物聯網開發者調查，Java首次提供了用於物聯網開發的編程語言列表，專門用於網關和雲。
使用Java進行物聯網開發的一個主要好處是便攜性。Java沒有任何硬體限制，這意味著您可以在計算機上編寫和調試Java代碼，並將其部署到幾乎任何運行Java虛擬機的設備上。出於這個原因，許多公司選擇聘請Java開發人員進行物聯網項目。
C：嵌入式設備的關鍵編程語言
C編程語言接下來成為物聯網IoT堆棧最喜歡的語言。然而，根據Eclipse基金會的說法，它被認為是受限設備開發的領先技術。
該編程語言提供對低級硬體API的直接訪問。由於其與機器語言的相似性，C非常快速且靈活，使其成為處理能力有限的物聯網系統的完美選擇。
C ++：Linux的第一語言
與其前身C一樣，C ++已廣泛用於嵌入式系統開發。但是，C ++的主要優勢在於處理能力，在任務更加復雜時使其成為C的有用替代方案。
C ++最適合編寫硬體特定的代碼。它可與Linux，第一大物聯網技術操作系統配合使用。但是，與Java相比，它具有有限的可移植性。
Python：面向數據的物聯網系統的解決方案
作為最受歡迎的網路編程語言之一，以及科學計算的前沿技術，Python在物聯網開發中也獲得了巨大的推動力。 對於數據密集型應用程序，Python是一個不錯的選擇，特別是在管理和組織復雜數據時。
JavaScript：事件驅動物聯網應用的最佳解決方案
根據年度StackOverflow開發者調查顯示，JavaScript是過去五年來最流行的編程語言之一，是現代Web開發中的核心技術。
在許多其他應用領域中，JavaScript是物聯網編程語言中最常用的構建事件驅動系統。它可以管理連接設備的大型網路，並且在需要處理多個任務而無需等待其他任務完成時可以勝任。JavaScript對IoT的主要優勢之一是非常節約資源。
Go：堅固的技術堆棧為復雜的物聯網網路提供動力
Go是一款開源編程語言，由Google創建。盡管它不能像語言那樣擁有同樣廣泛的用途，但我們之前專注於這一點，它是在您的物聯網系統內建立通信層的強大技術。
Go語言關於物聯網的主要優勢是並發性和同時運行多個進程（數據輸入和輸出）的能力。這使得構建由多個感測器和設備組成的復雜IoT網路變得更加容易。
『陸』 關於stm32與伺服器通信的問題
你是想用web遠程監控單片機的運行，但是不知道怎麼把單片機的信息上傳到伺服器，轉化成web頁面展示出來，我做過一個是通過阿里雲IOT實現的
單片機內加入MQTT協議，與阿里雲伺服器通信，可以通過IOT studio快速配置生成web
官方給到歷程是都是通過ESP的WiFi來聯網。我做的是通過W5500聯網的
把C語言Link Kit SDK移植到stm32單片機中，web由IOT studio生成。
『柒』 如何實現消息推送功能
?可以用第三方軟體極光推送來實現。對於定製化需求較強的，或者想擁有自己推送平台的開發者，極光提供全功能的私有雲方案。極光推送快速開始步驟: 1、到極光推送官方網站注冊開發者帳號；
2、登錄進入管理控制台，創建應用程序，得到 Appkey（SDK 與伺服器端通過 Appkey 互相識別）；
3、在推送設置中給 Android 設置包名、給 iOS 上傳證書、啟用 WinPhone，根據你的需求進行選擇；
4、下載 SDK 集成到 App 里。
客戶端初始化 JPush 成功後，JPush 服務端會分配一個 Registration ID，作為此設備的標識（同一個手機不同 App 的 Registration ID 是不同的）。開發者可以通過指定具體的 Registration ID 來進行對單一設備的推送。