隨著芯片成本的不斷下降，移動(dòng)設(shè)備的不斷增多钾怔，互聯(lián)網(wǎng)的日益發(fā)達(dá)，設(shè)備間的通信互聯(lián)又重新走向了臺(tái)前愚臀。毫無疑問姑裂，把數(shù)以萬計(jì)的傳感器連接在一起能夠產(chǎn)生巨大的化學(xué)反應(yīng)梦皮，IoT的初衷之一也就是采集大數(shù)據(jù)。交通捧毛、運(yùn)輸呀忧、物流溃睹、能源因篇，幾乎生產(chǎn)生活的每個(gè)方面都可能被IoT所顛覆。一般而言咐吼，IoT遇到的最大的問題就是環(huán)境的不穩(wěn)定性锯茄，也就是沒有穩(wěn)定的電源茶没，并且無線網(wǎng)絡(luò)的帶寬抓半、延時(shí)、丟包等問題都比較突出廊移。所以，IoT領(lǐng)域一般使用輕量級(jí)的協(xié)議冶伞，如知名的消息協(xié)議MQTT和XMPP步氏。但今天我們關(guān)注的有所不同，它是在RFC 7252描述的受限應(yīng)用協(xié)議（Constrained Application Protocol, CoAP）芋类。
CoAP
理解CoAP協(xié)議主要要弄清幾個(gè)概念侯繁，首先贮竟，也就是上面提到的较剃，IoT中很多設(shè)備都是資源受限的，即只有少量的內(nèi)存空間和有限的計(jì)算能力惰拱，像HTTP這種協(xié)議就顯得過于龐大而不適用了。為此啊送，IETF（Intemet Engineering Task Force）的CoRE（Constrained RESTful Environment）工作組為受限節(jié)點(diǎn)制定相關(guān)的REST（Representational State Transfer）形式的應(yīng)用層協(xié)議偿短。
REST，是不是很熟悉馋没？REST也是互聯(lián)網(wǎng)中最為常用的架構(gòu)之一昔逗，許多服務(wù)的接口都是REST，微服務(wù)中間件的接口也大量采用了REST披泪，當(dāng)然纤子，針對(duì)數(shù)據(jù)耦合度比較高的情況搬瑰，為了簡化請求和查詢款票，后來也發(fā)明了GraphQL等。
REST架構(gòu)的基本概念可以參見阮一峰的理解RESTful架構(gòu)泽论。這里僅僅挑出幾個(gè)重點(diǎn)艾少，首先，它是client/server的架構(gòu)模型翼悴。其次谍椅，它把數(shù)據(jù)看做「資源」锁施，放到IoT里，就可以是溫度計(jì)測量的溫度姥饰，或者電池的剩余電量這些數(shù)據(jù)谈飒。
CoAP服務(wù)器則提供了人們能輕松看懂的URI掺逼，如/thermometers/5。在可發(fā)現(xiàn)性的使用慣例里，所有資源都可以通過訪問/.well-known/core這個(gè)地址列出，每個(gè)資源可以通過一系列查詢參數(shù)來篩選，如/.well-known/core?rt=light_switch會(huì)列出所有資源類型（rt, resource type）為light_switch的資源钉嘹。
和HTTP協(xié)議類似缨睡，你可以使用GET, POST, PUT 和 DELETE來操作資源沛贪，這種相似性使你可以映射請求到另一個(gè)服務(wù)器，也就是把CoAP和Web結(jié)合之碗。我們也要注意到，CoAP底層是基于UDP協(xié)議的，這樣能讓協(xié)議更加輕盈。請求既可以被確認(rèn)祭往，也可以不被確認(rèn)，可以根據(jù)需求而定已骇。Large payloads are handled on the application layer to avoid IP fragmentation through a block-wise transfer.
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Figure 1: Abstract Layering of CoAP
CoAP協(xié)議的傳輸層使用UDP協(xié)議乱豆。由于UDP傳輸?shù)牟豢煽啃月鄯海珻oAP協(xié)議采用了雙層結(jié)構(gòu)，定義了帶有重傳的事務(wù)處理機(jī)制勇边，并且提供資源發(fā)現(xiàn)和資源描述等功能奕坟。CoAP采用盡可能小的載荷，從而限制了分片苛萎。
最有趣的特性要屬“observe” 設(shè)置了。客戶端發(fā)送GET請求時(shí)可以傳遞一個(gè)flag來開啟觀察者模式(observation)。server之后會(huì)把這個(gè)客戶端列入特定資源的觀察者名單，然后客戶端持續(xù)監(jiān)聽服務(wù)端的響應(yīng)卿啡。它允許我們構(gòu)建被動(dòng)接收數(shù)據(jù)的系統(tǒng)剑逃，無論這些數(shù)據(jù)將在什么時(shí)候送達(dá)。我們回想到HTTP和Websocket的場景俗或，是不是有點(diǎn)像publisher-subscriber模式辱志？是不是有點(diǎn)像Meteor的REST for Websocket已球。簡言之，CoAP既可以單次REST請求，也可以通過observe實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)訂閱通铲。
當(dāng)然CoAP還有其他有趣的特性质和。數(shù)據(jù)包（Datagrams）的傳輸安全性可以由DTLS（Datagram Transport Layer Security胆描，數(shù)據(jù)包傳輸層安全性協(xié)議）來保證。未來也存在 multicast and grouping of resources 的可能性醋闭。CoAP被最大最有前景的開源IoT框架IoTivity使用丈咐，它是由 Open Connectivity Foundation 贊助的，OCF包含了許多工業(yè)巨頭衅澈，著名的微軟造虎、英特爾氓轰、高通怒医、三星蛤奥、思科、通用電氣都在其列刹孔。
小結(jié)
簡單地來說障斋，CoAP是簡化了HTTP協(xié)議的RESTful API被济，因而也只提供了REST的四個(gè)方法，即GET刊棕，POST，PUT和DELETE。對(duì)于資源受限的微處理器胸懈，和在資源受限的IP網(wǎng)絡(luò)下通信，HTTP并不是一種可行的選擇烙常。它占用了太多的資源和太多的帶寬挣棕。而對(duì)于物聯(lián)網(wǎng)這種嵌入式設(shè)備來說，對(duì)于資源與帶寬渐夸，是我們需要優(yōu)先考慮的內(nèi)容垫挨。
- CoAP采用了二進(jìn)制報(bào)頭九榔，而不是文本報(bào)頭(text header)
- CoAP降低了頭的可用選項(xiàng)的數(shù)量
- CoAP減少了一些HTTP的方法
- CoAP可以支持檢測裝置
