最近在開發新產品時，新產品支持的協議HTTPS/MQTT等標准協議，有人問我為什么一定要選擇MQTT？我自己思考了下，也沒有很清晰的概念，到網上找了MQTT相關資料，記錄如下。
①低協議開銷
MQTT 的獨特之處在於，它的每消息標題可以短至 2 個字節。MQ 和 HTTP 都擁有高得多的每消息開銷。對於 HTTP，為每個新請求消息重新建立 HTTP 連接會導致重大的開銷。MQ 和 MQTT 所使用的永久連接顯著減少了這一開銷。
②對不穩定網絡的容忍
MQTT 和 MQ 能夠從斷開等故障中恢復，而且沒有進一步的代碼需求。但是，HTTP 無法原生地實現此目的，需要客戶端重試編碼，這可能增加冪等性問題。
③低功耗
MQTT 是專門針對低功耗目標而設計的。HTTP 的設計沒有考慮此因素，因此增加了功耗。
④數百萬個連接的客戶端
在 HTTP 堆棧上，維護數百萬個並發連接，需要做許多的工作來提供支持。盡管可以實現此支持，但大多數商業產品都為處理這一數量級的永久連接而進行了優化。IBM 提供了 IBM MessageSight，這是一個單機架裝載服務器，經過測試能處理多達 100 萬個通過 MQTT 並發連接的設備。相反，MQ 不是為大量並發客戶端而設計的。
⑤推送通知
您需要能夠及時地將通知傳遞給客戶。為此，必須采用某種定期輪詢或推送方法；從電池、系統負載和帶寬角度講，推送是最佳解決方案。
我們的企業可能需要在沒有第三方中介的情況下發送敏感的信息。這降低了特定於操作系統的解決方案（比如 Apple iOS、Google Play 通知）作為主要傳輸機制的價值。
HTTP 只允許使用一種稱為COMET 的方法，使用持久的 HTTP 請求來執行推送。從客戶端和服務器的角度講，此方法都很昂貴。MQ 和 MQTT 都支持推送，這是它們的一個基本特性。
⑥客戶端平台差異
HTTP 和 MQTT 客戶端都已在大量平台上實現。MQTT 的簡單性有助於以極少的精力在額外的客戶端上實現 MQTT。
⑦ 防火牆容錯
一些企業防火牆將出站連接限制到一些已定義的端口。這些端口通常被限制為 HTTP（80 端口）、HTTPS（443 端口）等。HTTP 顯然可以在這些情況下運行。MQTT 可封裝在一個 WebSockets 連接中，顯示為一個 HTTP 升級請求，從而允許在這些情況下運行。MQ 不允許采用這種模式。
事實上，MQTT的應用非常之廣泛，幾乎現在隨便找一家大型的硬件、互聯網企業，都可以找到MQTT的身影，例如Facebook、BP、alibaba、baidu等等
————————————————
針對我這個開發的產品，我認為第四個功能是很重要的，也解釋問什么要用MQTT，隨着客戶端設備越來越多，HTTPS在多台設備並發時，響應不夠快，輪詢時間長等。
http使用TCP 三次握手建立連接，客戶端和服務器需要交換3個包，https除了 TCP 的三個包，還要加上 ssl握手需要的9個包，所以一共是12個包。http 建立連接，按照下面鏈接中針對Computer Science House的測試，是114毫秒；https建立連接，耗費436毫秒。ssl 部分花費322毫秒，包括網絡延時和ssl 本身加解密的開銷（服務器根據客戶端的信息確定是否需要生成新的主密鑰；服務器回復該主密鑰，並返回給客戶端一個用主密鑰認證的信息；服務器向客戶端請求數字簽名和公開密鑰）。
————————————————
版權聲明：本文為CSDN博主「yy-captain」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/makenothing/java/article/details/78378293
原文鏈接：https://blog.csdn.net/anxianfeng55555/java/article/details/80908958