為了更好地了解風險，漏洞和威脅，需要更好地了解協議及其工作方式。細節深刻，值得一讀。
MQTT，消息隊列遙測傳輸，是一種非常簡單和輕量級的消息傳遞協議。它是為具有受限資源的設備開發的，可以通過低于最佳網絡的最佳性能進行通信，這些網絡可能遭受低帶寬，高延遲或者僅僅是明顯不可靠的。它位于TCP之上，利用發布/訂閱模型，訂閱“客戶”和數據“經紀人”扮演中間人。該模型的工作方式類似于新聞專線發布服務，其中像AP或路透社這樣的“經紀人”允許記者將報告“發布”到他們的有線服務。同時，雖然已經“訂閱”該線路的新聞室能夠通過經紀人接收新聞。
根據MQTT FAQ，該協議的“設計原則是盡量減少網絡帶寬和設備資源需求，同時還試圖確?？煽啃院鸵欢ǔ潭鹊慕桓侗ＷC?！彼€指出這些原則使該協議成為最新一代的理想選擇。 M2M系統，物聯網和“帶寬和電池功率非常高的移動應用”。它是一個相當成熟的協議，自1999年以來一直存在，并且仍在不斷發展以更好地滿足安全性，低功耗和延遲的需求。MQTT通過端口1883上的TCP / IP與IANA一起工作，而TCP / IP端口8883通過SSL注冊使用MQTT。
MQTT協議的發布者/訂閱者/代理模型的概念圖。
如果愿意的話，約束應用協議(CoAP)是一種更年輕且尚未正式標準化的“原始協議”。據官方網站稱，它“專為智能能源和樓宇自動化等機器對機器(M2M)應用而設計”。CoAP也通過其他機制使用，例如移動通信網絡上的短信。
它專為通過互聯網或網絡的電力或網絡受限設備而設計，但使用用戶數據報協議(UDP)而不是TCP。根據Eclipse Foundation的說法，“CoAP數據包比HTTP TCP流程要小得多。從字符串到整數的位域和映射被廣泛用于節省空間。數據包很容易生成，并且可以在適當的位置進行解析，而不會在受限設備中占用額外的RAM。“沒有機制支持QoS以確保收到數據包。
CoAP遵循客戶端/服務器模型，可與HTTP和RESTful API以及軟件設計范例互操作。 因為它基于UDP，所以CoAP不要求客戶端保持對服務器的連接，這在許多用例中被認為是一個好處。
客戶端可以向服務器發送一個CoAP數據包。每個請求都有一些選項，其中最重要的一個是統一資源標識符(URI)，它指示所請求資源的“路徑” - 非常類似于網站的統一資源定位符(URL)。請注意，節點可以同時是服務器和客戶端，實現點對點，全雙工數據層。
使用CoAP和HTTPS以及REST API的名義CoAP架構。請注意靈活的拓撲。這里，CoAP客戶端節點位于受約束的環境中。橙色箭頭是CoAP連接，黃色是HTTPS(作為示例)。
TrendMicro在他們的論文中提供了兩種協議的出色比較：
“CoAP比MQTT輕得多，在操作要求方面(即，不需要代理設置)和內存和網絡開銷(即，UDP不需要保持連接打開，并且消息的大小要小得多)。因此，它滿足低功耗物聯網節點的要求：它最大限度地降低了傳輸成本，并且不會強制建立始終在線的連接。
就其而言，MQTT優于CoAP，用于關鍵任務M2M：它允許實施服務質量并確保消息傳遞。另一方面，CoAP優于MQTT，用于收集從微小場傳感器等瞬態低功率節點傳輸的遙測數據。CoAP的一個極端應用用例是衛星通信：歐洲航天局的電信系統高級研究(ARTES)計劃最近啟動了衛星網絡中M2M通信的研究項目(延遲可能非常高)，CoAP是毫不奇怪地列在所選協議中?！?/p>
-20241213094735.png)
