24小時(shí)聯(lián)系電話:18217114652、13661815404
中文
行業(yè)資訊
物聯(lián)網(wǎng)約束應(yīng)用協(xié)議（CoAP）的基礎(chǔ)
并非所有連接的設(shè)備都相等。盡管有些功能更強(qiáng)大且技術(shù)先進(jìn)，但其他功能卻是簡(jiǎn)單的傳感器和家庭自動(dòng)化設(shè)備，其能量，內(nèi)存，計(jì)算能力和帶寬有限。為了補(bǔ)償這種資源受限和低功耗的設(shè)備，開發(fā)人員可以選擇約束應(yīng)用協(xié)議（CoAP）作為其IoT協(xié)議，以更有效地在兩個(gè)對(duì)等方之間進(jìn)行通信。
這種輕量級(jí)的RESTful協(xié)議專門針對(duì)網(wǎng)絡(luò)中具有大量終端設(shè)備的部署進(jìn)行了優(yōu)化。CoAP能夠在設(shè)備上創(chuàng)建和管理資源，發(fā)布和訂閱數(shù)據(jù)，管理數(shù)據(jù)多播，在請(qǐng)求時(shí)提供設(shè)備描述，以及提供機(jī)制以告知設(shè)備是否通電（同時(shí)節(jié)省能源并簡(jiǎn)化客戶端與客戶端之間的通信）。設(shè)備。更好的是，CoAP和HTTP REST之間的基礎(chǔ)設(shè)施相似性使設(shè)計(jì)人員能夠?qū)?duì)RESTful模式的理解運(yùn)用到他們的IoT解決方案中。
讓我們探討一下這種獨(dú)特的請(qǐng)求/響應(yīng)通信類型的內(nèi)容和原因。
CoAP一目了然
就像HTTP用于在客戶端和服務(wù)器之間傳輸數(shù)據(jù)和命令一樣，CoAP允許相同的命令傳輸功能，但是不需要相同數(shù)量的資源，因此非常適合當(dāng)今的物聯(lián)網(wǎng)（IoT）設(shè)備。
服務(wù)層協(xié)議是由Internet工程任務(wù)組（IETF）設(shè)計(jì)的，即使在受限的低帶寬網(wǎng)絡(luò)中也可以使簡(jiǎn)單的設(shè)備加入IoT。
從開發(fā)人員的角度來(lái)看，CoAP感覺(jué)非常像HTTP。從傳感器獲取值與從Web API獲取值沒(méi)有太大區(qū)別。兩種協(xié)議之間的相似性極大地簡(jiǎn)化了開發(fā)，因?yàn)樵O(shè)備開發(fā)人員可以在其基礎(chǔ)架構(gòu)中使用傳統(tǒng)客戶端/服務(wù)器HTTP REST服務(wù)中的知名模式。此外，由于HTTP和CoAP共享REST模型，因此可以使用與應(yīng)用程序無(wú)關(guān)的跨協(xié)議代理輕松連接它們。例如，在CoAP vs MQTT方面，這是一個(gè)主要優(yōu)勢(shì)，因?yàn)楹笳卟皇腔?span lang="EN-US">RESTful的。
更快的通訊，更好的電池
CoAP旨在滿足多播支持，低開銷和簡(jiǎn)單性等特殊要求，這是物聯(lián)網(wǎng)設(shè)備的三個(gè)重要元素，它們深深地嵌入并且比傳統(tǒng)的互聯(lián)網(wǎng)設(shè)備具有更少的內(nèi)存和電源。因此，效率是不可或缺的，而這正是CoAP所能提供的。
例如，由于其開銷低且簡(jiǎn)單，CoAP降低了功耗要求。該協(xié)議例如通過(guò)UDP和BLE進(jìn)行操作，而UDP和BLE所需的通信開銷最小，并允許更快的喚醒時(shí)間和延長(zhǎng)的睡眠狀態(tài)。兩者合計(jì)，這意味著電池使用壽命更長(zhǎng)。此外，UDP和BLE所提供的較小的數(shù)據(jù)包大小可導(dǎo)致更快的通信周期，再次使電池使用壽命更長(zhǎng)。
實(shí)際上，在控制智能家居設(shè)備時(shí)，更快的通信周期和更長(zhǎng)的電池使用時(shí)間是極好的好處。CoAP允許與例如智能鎖，警報(bào)器或加熱系統(tǒng)的直接交互，就像在傳統(tǒng)HTTP REST服務(wù)中公開時(shí)那樣。同樣，工業(yè)設(shè)備用戶也可以從發(fā)送控制命令，查詢寄存器和更改配置的功能中受益。
遠(yuǎn)程訪問(wèn)注意事項(xiàng)
但是，與此同時(shí)，設(shè)備設(shè)計(jì)人員必須意識(shí)到CoAP的局限性。
CoAP本身不提供遠(yuǎn)程訪問(wèn)，因此，如果連接位于防火墻后面，則用戶將無(wú)法訪問(wèn)其設(shè)備。因此，由于按照標(biāo)準(zhǔn)在CoAP中沒(méi)有安全的傳輸，因此用戶將需要自帶。
答案可能是HTTPS，TLS，DTLS或第三方平臺(tái)。但是，無(wú)論選擇如何，設(shè)備用戶和設(shè)計(jì)人員都必須承認(rèn)這一局限性并做出相應(yīng)的準(zhǔn)備，這是不可或缺的。同樣，不要忽略此方程式中的訪問(wèn)控制。用戶必須非常確定在穿越任何防火墻時(shí)允許誰(shuí)進(jìn)入，因此，用戶有責(zé)任確保在正確的客戶端和設(shè)備之間進(jìn)行數(shù)據(jù)傳輸?；蛘?，他們可以選擇具有內(nèi)置安全傳輸和訪問(wèn)控制的第三方遠(yuǎn)程訪問(wèn)平臺(tái)。
都是關(guān)于節(jié)點(diǎn)的
隨著傳感器數(shù)量逐月增長(zhǎng)，很明顯，連接物聯(lián)網(wǎng)數(shù)十億個(gè)節(jié)點(diǎn)將需要同時(shí)廉價(jià)且高效。實(shí)現(xiàn)該協(xié)議是CoAP最為令人興奮的元素之一，因?yàn)樵搮f(xié)議已設(shè)計(jì)為可在內(nèi)存低至10 kb（KiB），代碼空間為100 KiB的微控制器上運(yùn)行。
本質(zhì)上，CoAP采用了HTTP
REST的最佳元素并縮小了它們的尺寸。REST主要在HTTP上運(yùn)行，并且通常在Web API中使用?；?span lang="EN-US">REST體系結(jié)構(gòu)的應(yīng)用程序符合一些指導(dǎo)原則和約束，因此生成的協(xié)議性能良好，并且具有高度可伸縮性，簡(jiǎn)單性，并且易于修改和擴(kuò)展。由于CoAP基于REST，但著重于縮小協(xié)議的大小，因此它是熟悉RESTful模式的小型設(shè)備和設(shè)計(jì)人員的理想解決方案。
再次，設(shè)備和網(wǎng)絡(luò)設(shè)計(jì)人員必須考慮訪問(wèn)和安全性，并通過(guò)第三方平臺(tái)的實(shí)現(xiàn)來(lái)實(shí)現(xiàn)對(duì)等（P2P）遠(yuǎn)程連接，這可能是最好的選擇?？傮w而言，CoAP通過(guò)使IoT設(shè)備能夠經(jīng)濟(jì)高效且安全地在遠(yuǎn)距離傳輸數(shù)據(jù)的同時(shí)又僅消耗很少的電量，從而幫助最小化了云設(shè)備連接的成本。同時(shí)，對(duì)于設(shè)計(jì)者而言，與HTTP REST的相似性使任何設(shè)備向CoAP的過(guò)渡在2021年都更加誘人。