無線物聯(lián)網(wǎng)中CoAP協(xié)議的研究與實(shí)現(xiàn)(一)

　　（5）支持資源發(fā)現(xiàn)：為了自主的發(fā)現(xiàn)和使用資源，它支持內(nèi)置的資源發(fā)現(xiàn)格式，用于發(fā)現(xiàn)設(shè)備上的資源列表，或者用于設(shè)備向服務(wù)目錄公告自己的資源。它支持RFC5785中的格式，在CoRE中用/.well—known/core的路徑表示資源描述。

　?。?）支持緩存：CoAP協(xié)議支持資源描述的緩存以優(yōu)化其性能。

　?。?）訂閱機(jī)制：CoAP使用異步通信方式，用訂閱機(jī)制實(shí)現(xiàn)從服務(wù)器到客戶端的消息推送。實(shí)現(xiàn)CoAP的發(fā)布，訂閱機(jī)制，它是請(qǐng)求成功后自動(dòng)注冊(cè)的一種資源后處理程序。是由默認(rèn)的EVENT_和PERIODIC_RESOURCEs來進(jìn)行配置的。它們的事件和輪詢處理程序用 EST.notify_subscri bers（）函數(shù)來發(fā)布。

　　2.1 CoAP協(xié)議棧圖3是CoAP協(xié)議棧。CoAP協(xié)議的傳輸層使用UDP協(xié)議。由于UDP傳輸?shù)牟豢煽啃?，CoAP協(xié)議采用了雙層結(jié)構(gòu)，定義了帶有重傳的事務(wù)處理機(jī)制，并且提供資源發(fā)現(xiàn)和資源描述等功能。CoAP采用盡可能小的載荷，從而限制了分片。

　　事務(wù)層（Transaction layer）用于處理節(jié)點(diǎn)之間的信息交換，同時(shí)提供組播和擁塞控制等功能。請(qǐng)求/響應(yīng)層（Request/Responselayer）用于傳輸對(duì)資源進(jìn)行操作的請(qǐng)求和響應(yīng)信息。CoAP協(xié)議的REST構(gòu)架是基于該層的通信。CoAP的雙層處理方式，使得CoAP沒有采用TCP協(xié)議，也可以提供可靠的傳輸機(jī)制。利用默認(rèn)的定時(shí)器和指數(shù)增長的重傳間隔時(shí)間實(shí)現(xiàn)CON（Confirmable）消息的重傳，直到接收方發(fā)出確認(rèn)消息。另外，CoAP的雙層處理方式支持異步通信，這是物聯(lián)網(wǎng)和M2M應(yīng)用的關(guān)鍵需求之一。

　　2.2 CoAP的訂閱機(jī)制HTTP的請(qǐng)求/響應(yīng)機(jī)制是假設(shè)事務(wù)都是由客戶端發(fā)起的，通常叫做拉模型。這導(dǎo)致客戶端不能高效的知統(tǒng)中，設(shè)備都是無線低功耗的，這些設(shè)備大部分時(shí)間是休眠狀態(tài)，因此不能響應(yīng)輪詢請(qǐng)求。而CoRE認(rèn)為支持本地的推送模型是一個(gè)重要的需求，也就是由服務(wù)器初始化事務(wù)到客戶端。推送模型需要一個(gè)訂閱接口，用來請(qǐng)求響應(yīng)關(guān)于特定資源的改變。而由于UDP的傳輸是異步的，所以不需要特殊的通知消息。訂閱機(jī)制如圖4所示。

　　2.3 CoAP的交互模型CoAP使用類似于HTTP的請(qǐng)求/響應(yīng)模型：CoAP終端節(jié)點(diǎn)作為客戶端向服務(wù)器發(fā)送一個(gè)或多個(gè)請(qǐng)求，服務(wù)器端回復(fù)客戶端的CoAP 請(qǐng)求。不同于HTTP，CoAP的請(qǐng)求和響應(yīng)在發(fā)送之前不需要事先建立連接，而是通過CoAP信息來進(jìn)行異步信息交換。CoAP協(xié)議使用UDP進(jìn)行傳輸。這是通過信息層選項(xiàng)的可靠性來實(shí)現(xiàn)的。CoAP定義了四種類型的信息：可證實(shí)的CON（Confirmable）信息，不可證實(shí)的NON（Non- Confirmable）信息，可確認(rèn)的ACK（Acknowledgement）信息和重置信息RST（Reset）。方法代碼和響應(yīng)代碼包含在這些信息中，實(shí)現(xiàn)請(qǐng)求和響應(yīng)功能。這四種類型信息對(duì)于請(qǐng)求/響應(yīng)的交互來說是透明的。

　　CoAP的請(qǐng)求/響應(yīng)語義包含在CoAP信息中，其中分別包含方法代碼和響應(yīng)代碼。CoAP選項(xiàng)中包含可選的（或默認(rèn)的）請(qǐng)求和響應(yīng)信息，例如URI和負(fù)載內(nèi)容類型。令牌選項(xiàng)用于獨(dú)立匹配底層的請(qǐng)求到響應(yīng)信息。

　　請(qǐng)求/響應(yīng)模型：請(qǐng)求包含在可證實(shí)的或不可證實(shí)的信息中，如果服務(wù)器端是立即可用的，它對(duì)請(qǐng)求的應(yīng)答包含在可證實(shí)的確認(rèn)信息中來進(jìn)行應(yīng)答。圖5是基本的 GET請(qǐng)求和響應(yīng)模式，其中圖5（a）表示成功發(fā)送請(qǐng)求和收到ACK確認(rèn)信息，圖5（b）表示重傳了請(qǐng)求信息，然后才收到ACK確認(rèn)信息。

　　雖然CoAP協(xié)議目前還在制定當(dāng)中，但Contiki和TinyOS嵌入式操作系統(tǒng)已經(jīng)支持CoAP協(xié)議。Contiki是一個(gè)多任務(wù)操作系統(tǒng)，并帶有 uIPv6協(xié)議棧，適用于嵌入式系統(tǒng)和無線傳感器網(wǎng)絡(luò)，它占用系統(tǒng)資源小，適用于資源受限的網(wǎng)絡(luò)和設(shè)備。目前，火狐瀏覽器已經(jīng)集成了Copper插件，從而實(shí)現(xiàn)了CoAP協(xié)議。但是這種方式只能讀取傳感器節(jié)點(diǎn)上的實(shí)時(shí)數(shù)據(jù)，而不能查看各種歷史數(shù)據(jù)。為此，在Contiki系統(tǒng)的基礎(chǔ)上，基于 uIPv6START KIT無線網(wǎng)絡(luò)開發(fā)套件，用自己編寫的客戶端程序?qū)崿F(xiàn)了和數(shù)據(jù)庫的交互，把歷史數(shù)據(jù)