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