Coap協(xié)議學習總結

1、 Coap協(xié)議學習總結1、Coap協(xié)議介紹 在2010年3月，CoRE工作組開始制定CoAP協(xié)議，到目前為止，該協(xié)議還沒有定稿。CoAP協(xié)議是為物聯網中資源受限設備制定的應用層協(xié)議。CoAP 是受限制的應用協(xié)議(Constrained Application Protocol)的代名詞。在最近幾年的時間中，專家們預測會有更多的設備相互連接，而這些設備的數量將遠超人類的數量。在這種大背景下，物聯網和 M2M技術應運而生。雖然對人而言，連接入互聯網顯得方便容易，但是對于那些微型設備而言接入互聯網非常困難。在當前由PC機組成的世界，信息交換是通過 TCP和應用層協(xié)議HTTP實現的。但是對于小型設備而

2、言，實現TCP和HTTP協(xié)議顯然是一個過分的要求。為了讓小設備可以接入互聯網，CoAP協(xié)議被 設計出來。CoAP是一種應用層協(xié)議，它運行于UDP協(xié)議之上而不是像HTTP那樣運行于TCP之上。CoAP協(xié)議非常的小巧，最小的數據包僅為4字節(jié)。 為了克服HTTP對于受限環(huán)境的劣勢，CoAP既考慮到數據報長度的最優(yōu)化，又考慮到提供可靠通信。一方面，CoAP提供URI，REST 式的方法如GET，POST，PUT和DELETE，以及可以獨立定義的頭選項提供的可擴展性。另一方面，CoAP基于輕量級的UDP協(xié)議，并且允許IP 多播。而組通信是物聯網最重要的需求之一，比如說用于自動化應用中。為了彌補UDP傳輸

3、的不可靠性，CoAP定義了帶有重傳機制的事務處理機制。并且提供 資源發(fā)現機制，并帶有資源描述。CoAP協(xié)議不是盲目的壓縮了HTTP協(xié)議，考慮到資源受限設備的低處理能力和低功耗限制，CoAP重新設計了HTTP的部分功能以適應設備的約束條件。另外，為了使協(xié)議適應物聯網和M2M應用，CoAP協(xié)議改進了一些機制，同時增加了一些功能。下圖1顯示了HTTP和CoAP的協(xié)議棧。CoAP和HTTP在傳輸層有明顯的區(qū)別。HTTP協(xié)議的傳輸層采用了TCP協(xié)議，而CoAP協(xié)議的傳輸層使用UDP 協(xié)議，開銷明顯降低，并支持多播。 事務層(Transaction layer)用于處理節(jié)點之間的信息交換，同時提供組播和擁

4、塞控制等功能。請求響應層(RequestResponselayer)用于傳輸對資源進行操作的請求和響應信息。CoAP協(xié)議的REST構架是基于該層的通信。CoAP的雙層處理方式，使得CoAP沒有采用TCP協(xié)議，也可以提供可靠的傳輸 機制。利用默認的定時器和指數增長的重傳間隔時間實現CON(Confirmable)消息的重傳，直到接收方發(fā)出確認消息。另外，CoAP的雙層處理方 式支持異步通信，這是物聯網和M2M應用的關鍵需求之一。2、CoAP協(xié)議是否可以替換HTTP協(xié)議？ CoAP并不能替代HTTP協(xié)議，但是對于那些小設備（256KB Flash 32KB RAM 20MHz主頻）而言CoAP的確

5、是一個好的解決方案。3、CoAP的交互模型和消息類型 CoAP使用類似于HTTP的請求響應模型：CoAP終端節(jié)點作為客戶端向服務器發(fā)送一個或多個請求，服務器端回復客戶端的CoAP請求。不同于 HTTP，CoAP的請求和響應在發(fā)送之前不需要事先建立連接，而是通過CoAP信息來進行異步信息交換。CoAP協(xié)議使用UDP進行傳輸。這是通過信息層選項的可靠性來實現的。CoAP采用和HTTP協(xié)議相同的請求響應工作模式。CoAP協(xié)議共有4中不同的消息類型。CON需要被確認的請求，如果CON請求被發(fā)送，那么對方必須做出響應。NON不需要被確認的請求，如果NON請求被發(fā)送，那么對方不必做出回應。ACK應答消息，

6、如果接受到CON消息的響應。RST復位消息，當接收者接受到的消息包含一個錯誤，接受者解析消息或者不再關心發(fā)送者發(fā)送的內容，那么復位消息將會被發(fā)送。 雖然CoAP協(xié)議目前還在制定當中，但Contiki和TinyOS嵌入式操作系統(tǒng)已經支持CoAP協(xié)議。Contiki是一個多任務操作系統(tǒng)，并帶有uIPv6協(xié)議棧，適用于嵌入式系統(tǒng)和無線傳感器網絡，它占用系統(tǒng)資源小，適用于資源受限的網絡和設備。目前，火狐瀏覽器已經集成了Copper插件，從而實現了CoAP協(xié)議。但是這種方式只能讀取傳感器節(jié)點上的實時數據， 而不能查看各種歷史數據。為此，在Contiki系統(tǒng)的基礎上，基于uIPv6START KIT無線網

7、絡開發(fā)套件，用自己編寫的客戶端程序實現了和數據庫的交互，把歷史數據存入數據庫中，從而在Web瀏覽器端不僅可以訪問傳感器節(jié)點上的實時數 據，還能查看歷史數據，以便于分析問題。4、CoAP消息結構一個CoAP消息最小為4個字節(jié)，以下是CoAP協(xié)議不同部分的描述?！景姹綱ersion】：類似于IPv6和IPv6，僅僅是一個版本號。【消息類型Message Type】：CON，NON，ACK，RST。這些消息類型相當于HTTP協(xié)議的PUTGET等【消息ID Message ID】：每個CoAP消息都有一個ID，在一次會話中ID總是保持不變。但是在這個會話之后該ID會被回收利用?！緲擞?Token】：標

8、記是ID的另一種表現、【選項 Options】：CoAP選項類似于HTTP請求頭，它包括CoAP消息本身，例如CoAP端口號，CoAP主機和CoAP查詢字符串等?！矩撦dPayload】：真正有用的被交互的數據。圖 CoAP消息結構5、CoAP的URL 在 HTTP的世界中，正式RESTFul協(xié)議由于其簡單性和適用性，在WEB應用中越來越受歡迎，這樣的道理同樣適用于CoAP。一個CoAP資源可以被一 個URI所描述，例如一個設備可以測量溫度，那么這個溫度傳感器的URI被描述為：CoAP:/machine.address:5683 /sensors/temperature。請注意，CoAP的默認U

9、DP端口號為5683。6、CoAP觀察模式 在物聯網的世界中，你需要去監(jiān)控某個傳感器例如溫度或濕度等。在這種情況下，CoAP客戶端并不需要不停的查詢CoAP服務器端的數據變化情況。CoAP客 戶端可以發(fā)送一個觀察請求到服務器端。從該時間點開始計算，服務器便會記住客戶端的連接信息，一旦溫度發(fā)生變化，服務器將會把新結果發(fā)送給客戶端。如果客 戶端不在希望獲得溫度檢測結果，那么客戶端將會發(fā)送一個RST復位請求，此時服務器便會清除與客戶端的連接信息。7、CoAP塊傳輸 CoAP協(xié)議的特點是傳輸的內容小巧精簡，但是在某些情況下不得不傳輸較大的數據。在這種情況下可以使用CoAP協(xié)議中的某個選項設定分塊傳輸的

10、大小，那么無論是服務器或客戶端可完成分片和組裝這兩個動作。8、CoAP協(xié)議的特點： （1）報頭壓縮：CoAP包含一個緊湊的二進制報頭和擴展報頭。它只有短短的4 B的基本報頭，基本報頭后面跟擴展選項。一個典型的請求報頭為1020B。 報頭部分各字段的含義如下：V(Version)表示CoAP協(xié)議的版本號；T(Type)表示消息的信息類型；OC(Option Count)表示頭后面的可選的選項數量；Code表示消息的類型：請求消息、響應消息，或者是空消息；Message ID表示消息編號，用于重復消息檢測、匹配消息類型等。 （2）方法和URIs：為了實現客戶端訪問服務器上的資源，CoAP支持GET

11、、PUT、POST和DELETE等方法。CoAP還支持URIs，這是Web架構的主要特點。 (3)傳輸層使用UDP協(xié)議：CoAP協(xié)議是建立在UDP協(xié)議之上，以減少開銷和支持組播功能。它也支持一個簡單的停止和等待的可靠性傳輸機制。(4)支持異步通信：HTTP對M2M(Machine-to-Machine)通信不適用，這是由于事務總是由客戶端發(fā)起。而CoAP協(xié)議支持異步通信，這對M2M通信應用來說是常見的休眠喚醒機制。(5)支持資源發(fā)現：為了自主的發(fā)現和使用資源，它支持內置的資源發(fā)現格式，用于發(fā)現設備上的資源列表，或者用于設備向服務目錄公告自己的資源。它支持RFC5785中的格式，在CoRE中用w

12、ellknowncore的路徑表示資源描述。(6)支持緩存：CoAP協(xié)議支持資源描述的緩存以優(yōu)化其性能。(7)訂閱機制：CoAP使用異步通信方式，用訂閱機制實現從服務器到客戶端的消息推送。實現CoAP的發(fā)布，訂閱機制，它是請求成功后自動注冊的 一種資源后處理程序。是由默認的EVENT_和PERIODIC_RESOURCEs來進行配置的。它們的事件和輪詢處理程序用 ESTnotify_subscri bers()函數來發(fā)布。9、CoAP協(xié)議的火狐瀏覽器實現（B/S架構） B/S架構的系統(tǒng)結構如圖9所示系統(tǒng)由用戶瀏覽器、Web服務器、IPv6智能網關、MX231CC節(jié)點組成。用戶瀏覽器通過HTTP

13、協(xié)議訪問Web服務器，MX231CC節(jié)點通 過CoAP協(xié)議和IPv6智能網關進行通信，從而實現用戶瀏覽器訪問節(jié)點上資源的功能。圖9中實線表示有線連接，虛線表示無線連接。在當前的Contiki 2.5中，集成了CoAP 03和CoAP06這兩個版本。這兩個文件在Contiki 2.5的apps目錄下，關于CoAP的核心內容都在這兩個文件中。程序的主要部分為：AUTOSTART_PROCESSES（PERIODIC_RESOURCE（）為進程的主體部分。然后進行編譯，編譯成.elf文件，用JTAG下載器下載到節(jié)點上。節(jié)點地址設置為：2001：2：11：22ff：fe33：4499.這時， 用火狐瀏

14、覽器訪問節(jié)點，因為火狐瀏覽器自帶coap插件，如果用其他瀏覽器，那么需要進行coap的代理設置。以控制節(jié)點上的三色LED燈反轉為例，用下 面的請求格式：GETcoap:/：/readings其中mote_ip_address是節(jié)點的IPv6地址，port_number是節(jié)點的端口號，readings是客戶端請求的資源（溫度）。所以在瀏覽器地址欄輸入：coap:/2001：2：11：22ff：fe33：4499：61616/toggle，作用是讓節(jié)點上的三色LED燈進行反轉。服務器端的響應信息如圖10所示。 從瀏覽器端可以看出，CoAP協(xié)議支持Discover和Observe功能，具有GET、POST、PUT和DELETE等方法。Type表示信 息類型為ACK，Code為200，表示成功完成客戶端的請求。事務ID為38 264，它用于重復信息檢測，options為1表示有一個可選項，內容類型為text表示文本類型。由此可以看出，通過火狐瀏覽器的CoAP協(xié)議，可以訪問節(jié)點上的傳感器資源。10、CoAP協(xié)議的客戶端實現（C/S架構）通過火狐瀏覽器可以實現COAP協(xié)議，但是只能查看實時數據，不能查看歷史數據。為此，這里搭建了一個C/S架構的環(huán)境。如圖11所