由于物聯網中的很多設備都是資源受限型的，即只有少量的內存空間和有限的計算能力，所以傳統的HTTP協議應用在物聯網上就顯得過于龐大而不適用。 IETF的CoRE工作組提出了一種基于REST架構的CoAP協議。CoAP是6LowPAN協議棧中的應用層協議。該文在詳細介紹了CoAP協議的內容、特點和交互模型后，在uIPv6 START KIT無線網絡開發套件上，使用Contiki嵌入式操作系統，不僅在瀏覽器端實現了CoAP協議而且用自己編寫的客戶端程序實現了CoAP協議，增加了和數據庫之間的交互功能，從而實現了在Web界面上不僅可以查看實時數據，還可以查看歷史數據的功能。

　　0引言

　　物聯網是在互聯網的基礎上延伸和擴展的一種網絡，其用戶端延伸和擴展到了任何物品之間，彼此進行信息交換和通信，目的是實現所有物品與網絡的連接，從而方便識別、管理和控制。

　　無線物聯網的特點包括：全面感知、實時準確傳遞物品信息、利用智能計算技術對海量數據進行分析和處理，以實現智能化控制。

　　由于無線物聯網中的設備很多都是資源受限型的，這些設備只有少量的內存空間和有限的計算能力。為此，IETF（Intemet Engineering Task Force）的CoRE（Constrained RESTful Environment）工作組為受限節點制定相關的REST（Representational State Transfer）形式的應用層協議。這就是CoRE工作組正在制訂的CoAP（Constrained Application Protocol）協議。

　　1 6LoWPAN協議棧

　　由于TCP/IP協議棧不適用于資源受限的設備，因此提出了一種6LoWPAN（IPv6 over Low power Wireless Personal Area Networks）協議棧。CoAP是6LoWPAN協議棧中的應用層協議。6LoWPAN使IPv6可用于低功耗的有損網絡，它是基于IEEE 802.15.4標準的。6LoWPAN協議棧如圖1所示。

　　協議棧的下兩層用802.15.4 PHY/MAC，中間加一個IPv6-6LoWPAN適配層，傳輸層使用UDP協議，應用層使用CoAP協議。它包括REST的最小子集和到HTTP的無狀態映射。通信主機使用CoAP協議，能夠支持穩定的通信架構，以實現傳感器節點與互聯網的無線連接。

　　2 CoAP協議

　　在2010年3月，CoRE工作組開始制定CoAP協議，到目前為止，該協議還沒有定稿。CoAP協議是為物聯網中資源受限設備制定的應用層協議。它是一種面向網絡的協議，采用了與HTTP類似的特征，核心內容為資源抽象、REST式交互以及可擴展的頭選項等。應用程序通過URI標識來獲取服務器上的資源，即可以像HTTP協議對資源進行GET、PUT、POST和DELETE等操作。CoAP協議具有如下特點：（1）報頭壓縮：CoAP包含一個緊湊的二進制報頭和擴展報頭。它只有短短的4 B的基本報頭，基本報頭后面跟擴展選項。一個典型的請求報頭為10～20 B.圖2是CoAP協議的信息格式。

　　報頭部分各字段的含義如下：V（Version）表示CoAP協議的版本號；T（Type）表示消息的信息類型；OC（Option Count）表示頭后面的可選的選項數量；Code表示消息的類型：請求消息、響應消息，或者是空消息；Message ID表示消息編號，用于重復消息檢測、匹配消息類型等。

　　（2）方法和URIs：為了實現客戶端訪問服務器上的資源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP還支持URIs，這是Web架構的主要特點。

　　（3）傳輸層使用UDP協議：CoAP協議是建立在UDP協議之上，以減少開銷和支持組播功能。它也支持一個簡單的停止和等待的可靠性傳輸機制。

　　（4）支持異步通信：HTTP對M2M（Machine-to-Machine）通信不適用，這是由于事務總是由客戶端發起。而CoAP協議支持異步通信，這對M2M通信應用來說是常見的休眠/喚醒機制。

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

　　（6）支持緩存：CoAP協議支持資源描述的緩存以優化其性能。

　　（7）訂閱機制：CoAP使用異步通信方式，用訂閱機制實現從服務器到客戶端的消息推送。實現CoAP的發布，訂閱機制，它是請求成功后自動注冊的一種資源后處理程序。是由默認的EVENT_和PERIODIC_RESOURCEs來進行配置的。它們的事件和輪詢處理程序用 EST.notify_subscri bers（）函數來發布。

　　2.1 CoAP協議棧圖3是CoAP協議棧。CoAP協議的傳輸層使用UDP協議。由于UDP傳輸的不可靠性，CoAP協議采用了雙層結構，定義了帶有重傳的事務處理機制，并且提供資源發現和資源描述等功能。CoAP采用盡可能小的載荷，從而限制了分片。

　　事務層（Transaction layer）用于處理節點之間的信息交換，同時提供組播和擁塞控制等功能。請求/響應層（Request/Responselayer）用于傳輸對資源進行操作的請求和響應信息。CoAP協議的REST構架是基于該層的通信。CoAP的雙層處理方式，使得CoAP沒有采用TCP協議，也可以提供可靠的傳輸機制。利用默認的定時器和指數增長的重傳間隔時間實現CON（Confirmable）消息的重傳，直到接收方發出確認消息。另外，CoAP的雙層處理方式支持異步通信，這是物聯網和M2M應用的關鍵需求之一。

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

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

　　CoAP的請求/響應語義包含在CoAP信息中，其中分別包含方法代碼和響應代碼。CoAP選項中包含可選的（或默認的）請求和響應信息，例如URI和負載內容類型。令牌選項用于獨立匹配底層的請求到響應信息。

　　請求/響應模型：請求包含在可證實的或不可證實的信息中，如果服務器端是立即可用的，它對請求的應答包含在可證實的確認信息中來進行應答。圖5是基本的 GET請求和響應模式，其中圖5（a）表示成功發送請求和收到ACK確認信息，圖5（b）表示重傳了請求信息，然后才收到ACK確認信息。

　　雖然CoAP協議目前還在制定當中，但Contiki和TinyOS嵌入式操作系統已經支持CoAP協議。Contiki是一個多任務操作系統，并帶有 uIPv6協議棧，適用于嵌入式系統和無線傳感器網絡，它占用系統資源小，適用于資源受限的網絡和設備。目前，火狐瀏覽器已經集成了Copper插件，從而實現了CoAP協議。但是這種方式只能讀取傳感器節點上的實時數據，而不能查看各種歷史數據。為此，在Contiki系統的基礎上，基于 uIPv6START KIT無線網絡開發套件，用自己編寫的客戶端程序實現了和數據庫的交互，把歷史數據存入數據庫中，從而在Web瀏覽器端不僅可以訪問傳感器節點上的實時數據，還能查看歷史數據，以便于分析問題。

　　3實驗平臺及CoAP協議的實現

　　3.1實驗平臺硬件平臺式是美信凌科公司的IPv6智能網關（MXG300）、MX231CC節點、USB無線網卡（STICK）和JTAG下載器。實驗的硬件平臺配置和硬件平臺如圖6，圖7所示。軟件平臺是WinAVR和AVR studio，用于向節點和USB網卡中下載程序。

　　其中IPv6智能網關上的主要芯片有：BCM 6358UKFBG支持多用戶以太網功能，具有高度優化的32 MIPS CPU和標準的EJTAG調試器；BCM53 25EKQMG集成了5個收發器，具有128 KB的數據包緩沖區，最多可以支持2K的MAC地址，支持地址自動學習，提供真正的即插即用連接，而且是低功耗的；SIGe2521A60提供 2.4～2.5 GHz的無線工作頻段范圍，應用于ISM 2.4.GHz的無線解決方案。

　　圖8是IPv6智能無線網關的接口布局，它是基于OPENWRT系統定制完成的。具備3個局域網口，1個廣域網口，1個802.11a/b/g WiFi無線網絡接口，1個標準USB口和1個可選的串口調試口。該智能無線網關除具備通用無線路由器的功能以外，還可以實現基于Contiki操作系統的USB UIP網絡和普通IP網絡之間的IPv6互連，同時還支持有能力的系統在OPENWRT的基礎上開發自己的應用軟件包，實現更復雜的應用。

　　OPENWRT是一個開源的Linux版本。主要應用于嵌入式系統。網關和節點上同時裝有Contiki系統，它提供宏定義和RESTful網絡服務實例。

　　MX231CC節點上的主要芯片是ATmega1284P，它具有128 KB的可編程閃存，4 KB的E2PROM，16 KB的片內SRAM，JTAG接口，優化的功耗和處理速度。節點上運行Contiki系統。節點上還有光敏傳感器、室內溫度傳感器、三色LED指示燈等。

　　3.2 CoAP協議的火狐瀏覽器實現（B/S架構）

　　B/S架構的系統結構如圖9所示。

　　系統由用戶瀏覽器、Web服務器、IPv6智能網關、MX231CC節點組成。用戶瀏覽器通過HTTP協議訪問Web服務器，MX231CC節點通過CoAP協議和IPv6智能網關進行通信，從而實現用戶瀏覽器訪問節點上資源的功能。圖9中實線表示有線連接，虛線表示無線連接。

　　在當前的Contiki 2.5中，集成了CoAP 03和CoAP06這兩個版本。這兩個文件在Contiki 2.5的apps目錄下，關于CoAP的核心內容都在這兩個文件中。程序的主要部分為：

　　AUTOSTART_PROCESSES（PERIODIC_RESOURCE（）為進程的主體部分。

　　然后進行編譯，編譯成。elf文件，用JTAG下載器下載到節點上。節點地址設置為：2001：2：：11：22ff：：fe33：4499.這時，用火狐瀏覽器訪問節點，因為火狐瀏覽器自帶coap插件，如果用其他瀏覽器，那么需要進行coap的代理設置。以控制節點上的三色LED燈反轉為例，用下面的請求格式：GETcoap://［］：

　　/readings其中mote_ip_address是節點的IPv6地址，port_number是節點的端口號，readings是客戶端請求的資源（溫度）。

　　所以在瀏覽器地址欄輸入：coap://［2001：2：：11：22ff：fe33：4499］：61616/toggle，作用是讓節點上的三色LED燈進行反轉。服務器端的響應信息如圖10所示。

　　從瀏覽器端可以看出，CoAP協議支持Discover和Observe功能，具有GET、POST、PUT和DELETE等方法。Type表示信息類型為ACK，Code為200，表示成功完成客戶端的請求。事務ID為38 264，它用于重復信息檢測，options為1表示有一個可選項，內容類型為text表示文本類型。

　　由此可以看出，通過火狐瀏覽器的CoAP協議，可以訪問節點上的傳感器資源。

　　3.3 CoAP協議的客戶端實現（C/S架構）

　　上節通過火狐瀏覽器可以實現COAP協議，但是只能查看實時數據，不能查看歷史數據。為此，這里搭建了一個C/S架構的環境。如圖11所示。

　　圖11中客戶端軟件是用基于。NET架構的C#語言編寫的，數據庫使用SQL Server 2008.通過此程序，可以每隔10 s讀取一次數據，存入到數據庫中。并可以通過前臺的Web界面查看各種歷史數據，包括溫度、濕度、亮度等。

　　插入數據庫中的數據如圖12所示，圖中顯示的是室內的亮度值。

　　在Web瀏覽器端可以查看實時和歷史數據，頁面顯示效果如圖13所示。

　　由此看出，基于C/S架構的方式，不僅可以顯示實時數據，還可以查看歷史數據，以便及時發現問題，更加具有實用性。

　　4結論

　　本文詳細介紹了CoAP協議的內容、特點、交互模型以及訂閱機制，還給出了基于uIPv6 START KIT無線網絡開發套件的系統配置方式，該網絡可以通過火狐瀏覽器和客戶端軟件兩種方式實現CoAP協議，用戶不僅可以讀取傳感器上的實時數據，而且可以查看歷史數據。