宗娜++魏更宇

摘要：當受限網絡連接到互聯(lián)網之后，為了實現(xiàn)在互聯(lián)網瀏覽器上訪問受限資源，需要進行HTTP到CoAP和CoAP到HTTP的轉換。本文基于CoRE工作組當前的草案，討論了協(xié)議轉換的流程和轉換中的關鍵問題。參照CoRE工作組的標準進行研究、開發(fā)和部署，成為今后重要的課題。因此在總結工作組的主要進展的基礎上，本文對相關代理功能的開發(fā)和部署提出了建議。

關鍵詞：COAP；協(xié)議轉換；映射；反向代理

中圖分類號：TP319 文獻標識碼：A DOI： 10.3969/j.issn.1003-6970.2015.10.021

引言

物聯(lián)網（Internet of things，IoT）是新一代信息技術的重要組成部分，也是“信息化”時代的重要發(fā)展階段。隨著可穿戴設備和智能家居等的興起，主要由傳感器節(jié)點組成的資源受限網絡也日益引起關注。組成這種受限網絡的結點往往是供電功率低、處理能力弱、存儲容量小，因此組成受限網絡的通信鏈路通常是低速的和多差錯的。而傳統(tǒng)互聯(lián)網中普遍使用的應用層協(xié)議HTTP，由于復雜、協(xié)議頭開銷大而被認為不適用于資源受限網絡。在萬維網已經成為互聯(lián)網中最重要的應用技術的情況下，CoAP 工作組將受限網絡作為萬維網的一種延伸，CoRE（Constrained Restful Environment）工作組始終關注HTTP-CoAP協(xié)議的轉換功能，相關的協(xié)議草案也一直在演進和更新中。CoAP協(xié)議的基礎內容已經定義在RFC7252中，有關描述HTTP-CoAP代理的最新草案是第7個版本，而且還在進一步的演進中。

物聯(lián)網的資源訪問主要有兩種類型，第一種是從CoAP客戶端訪問CoAP服務器端的資源；第二種是從HTTP客戶端訪問CoAP服務器端的資源。而第二種方式中，HTTP客戶端就是目前互聯(lián)網上的瀏覽器，這種方式可能是今后最重要的一種方式。在這種方式中對資源的訪問就需要對HTTP和CoAP進行轉換，即將HTTP的請求轉換為CoAP的請求，之后將CoAP的響應轉換為HTTP的響應；總之，HTTP到CoAP和CoAP到HTTP的轉換是雙向的。

通過代理，用戶在瀏覽器上可以直接訪問到受限網中的資源，這將進一步實現(xiàn)物聯(lián)網數(shù)據(jù)共享并滿足OMA LWM2M中定義的應用需求。一個典型的HTIP客戶端通過代理訪問CoAP服務器上的資源可以描述為：瀏覽器發(fā)送請求到代理，代理接收后對URI進行映射并將HTTP頭部重新封裝為CoAP請求頭，生成CoAP請求之后將其發(fā)送到受限網中的CoAP服務器。CoAP服務器對CoAP請求做出響應并發(fā)送給代理，代理對媒體類型和響應碼等進行映射，重新封裝為HTTP響應后將其返回客戶端。本文根據(jù)CoRE 工作組的標準和實際的應用需求將給出對代理開發(fā)和部署方面的建議。

論文接下來的章節(jié)安排為：第1節(jié)介紹CoAP協(xié)議和CoAP代理，第2節(jié)詳細研討HTTP與CoAP協(xié)議轉換過程中的關鍵問題，第3節(jié)討論HTTP-CoAP代理的開發(fā)和部署，最后第4節(jié)對論文進行總結。

1 CoAP及CoAP代理

1.1 CoAP

CoAP是一種應用于受限網絡和節(jié)點的特殊Web傳輸協(xié)議，核心內容為資源抽象、REST式交互以及可擴展的頭選項等。CoAP在應用終端間提供請求/響應的交互模式，支持內置的資源發(fā)現(xiàn)，包含關鍵的網絡概念，比如URIs和Content-Type。為了克服HTTP對于受限環(huán)境的劣勢，CoAP既考慮到數(shù)據(jù)報長度的最優(yōu)化，又考慮到提供可靠通信。一方面，CoAP提供REST式的方法如GET，POST，PUT和DELETE，以及可以獨立定義的頭選項提供的可擴展性。另一方面，CoAP基于輕量級的UDP協(xié)議，并且允許IP多播。

CoAP不是盲目的壓縮了HTTP協(xié)議，考慮到資源受限設備的低處理能力和低功耗限制，它重新設計了HTTP的部分功能以適應設備的約束條件。此外，為了使協(xié)議適應物聯(lián)網和M2M應用，CoAP改進了一些機制，同時增加了一些功能。

HTTP的萬維網和CoAP的受限網絡的協(xié)議棧比較如圖1所示，可以看出 CoAP在資源受限網絡中的位置等同于HTTP在互聯(lián)網的位置。

可以在邏輯上認為CoAP協(xié)議采用了雙層的結構。事務層（Transaction layer）處理節(jié)點間的信息交換，同時也提供對多播和擁塞控制的支持。請求/響應層（Request/Response layer）用以傳輸對資源進行操作的請求和響應信息。

1.2 CoAP代理

CoAP代理是一個CoAP端點，可以代表CoAP客戶端執(zhí)行請求。當請求不可能產生或需要緩存響應以減少響應時間、網絡帶寬和能源消耗時，代理的存在非常必要。在CoRE 工作組的整體架構中，代理可以實現(xiàn)完全不同的功能。一種是正向代理的角色，代理由客戶端明確地選擇；另一種是反向代理的角色，代理代表原始服務器。由于這種區(qū)別，代理既可以是CoAP到CoAP的代理，也可以是跨協(xié)議的代理。不同于HTTP代理通常提供傳輸協(xié)議代理的功能以支持端到端的傳輸層安全，CoAP到CoAP的代理不具備這個功能。

通常代理需要一種方法來確定其發(fā)送請求的潛在的請求參數(shù)，這基于它從客戶端收到的請求。對于正向代理來說這種方式是完全指定的，而對于反向代理則需要特定的配置。特別地，反向代理的客戶端一般不標明目標地址的位置，因此某種形式的命名空間的翻譯對反向代理來說是必須的。

本文中HTTP到CoAP的代理為反向代理，即代理相當于HTTP服務器接收來自于HTTP客戶端的請求，并作為CoAP客戶端將提取的CoAP請求發(fā)送到受限網絡，而客戶端沒有意識到是與代理進行通信。正如通信是兩個方向，HTTP與CoAP的協(xié)議轉換包含HTTP-CoAP方向和CoAP-HTTP方向。

（1） HTTP-CoAP

實現(xiàn)時，HTTP客戶端發(fā)給代理1個HTTP請求，請求URI包含“coap”或“coaps”。代理接收后進行處理，發(fā)送到CoAP服務器。

（2） CoAP-HTTP

實現(xiàn)時，代理收到CoAP服務器發(fā)送的CoAP響應后進行處理，再發(fā)送回HTTP客戶端。

本節(jié)主要介紹了CoAP協(xié)議及CoAP代理的功能，接下來的章節(jié)將進一步討論HTTP-CoAP協(xié)議轉換中的主要功能。

2 HTTP-CoAP協(xié)議轉換

2.1 HTTP-CoAP的URI映射

目前絕大多數(shù)瀏覽器（火狐瀏覽器除外）并不支持使用”coap：∥”或”coaps：∥”發(fā)送HTTP請求，所以一個CoAP URI需要被web應用包裝到HTTPURI中并通過瀏覽器（UA）發(fā)送到HTTP-CoAP代理（HC）。

URI映射是代表CoAP資源的URI轉化為HTTP URI的過程。要求請求方（HTTP）瀏覽器可以處理完整的URI（Hosting HTTP URI），接收方HC代理可以提取目的CoAP URI（target CoAP URI，指向最終CoAP資源的URI），形式為”coap（coaps）：//host[“：”port] path-abempty [“？”query]”。在URI映射過程中還需要指向代理的URI，即base URID以上URI有這樣的組成方式：Hosting HTTP URI=base URI+target CoAP URI。

URI映射分為默認映射，簡單形式的映射和高級形式的映射。

默認映射是直接將target CoAP URI附加到HC提供的base URI上。例如，base URI為：http：//p.example.com/hc（以下同），target CoAP URI為coap：//s.example.com/light（以下同），則最終的Hosting HTTP URI為http：//p.example.com/hc/coap：//s.example.com/lightD當CoAP URI中存在查詢元素時，附加到base URI后則自然成為Hosting HTTP URI的查詢部分。默認映射機制是HC代理默認啟用的。

簡單形式的映射分為以下4種情況：

（1） CoAP URI是Hosting HTTP URI的查詢參數(shù)

Hosting HTTP URI=base URI +”？coap_target_uri=“+target CoAP URI

即為http：//p.example.com/hc？coap_target_uri=coap：//s.example.com/light。當使用coaps協(xié)議時，結果為http：//p.example.com/hc？coaps_target_uri=coaps：//s.example.com/light

（2） target CoAP URI作為Hosting HTTP URI的查詢參數(shù)

Hosting HTTP URI=base URI+”？target_uri=”+target CoAP URI

即Hosting HTTP URI=http：//p.example.com/hc？target_uri=coap：//s.example.com/light）

（3） target CoAP URI在Hosting HTTP URI的路徑部分，此時與默認映射機制一致

（4） target CoAP URI是Hosting HTTP URI的查詢參數(shù)時，客戶端省略協(xié)議名

Hosting HTTP URI=base URI+”？coap_uri=”+target CoAP URI

即Hosting HTTP URI=http：//p.example.com/hc？coap_uri=s.example.com/light

高級形式的映射分為以下2種情況：

（1）協(xié)議名后的”：∥”字符變?yōu)椤?”，其他與默認映射機制一致

即http：//p.example.com/hc/coap/s.example.com/light，當target CoAP URI存在查詢參數(shù)時，如coap：//s.example.com/light？on， Hosting HTTP URI為http：//p.example.com/hc/coap/s.example.com/light？on

（2 ）target CoAP URI分解為各個具體的部分，”s”代表協(xié)議名稱（coap或coaps），”hp”代表主機和端口號host[”：”port]，p代表URI中的路徑字段，q代表URI中的查詢字段

即Hosting HTTP URI =http：//p.example.com/hc？s=coap&hp=s.example.com&p=/light&q=，當target CoAP URI為coap：//s.example.com/light？on時，Hosting HTTP URI=http：//p.example.com/hc？s=coap&hp=s.example.com&p=/light&q=on

綜上，URI映射的整體過程可以歸納為以下幾步：

（1 ）HTTP客戶端與HC代理事先協(xié)商使用哪種映射模板，或者使用默認映射模板。

（2）如果HC代理支持發(fā)現(xiàn)機制，則HC代理可以發(fā)送帶有”/.well-knowm/core？”的鏈接，響應中若有”hct”屬性，則映射模板為”hct”屬性的值。

（3）根據(jù)映射模板生成Hosting HTTP URI。

（4） HTTP客戶端發(fā)送Host HTTP URI到HC代理。

（5） HC代理根據(jù)映射模板提取出正確的CoAP URI。

（6）HC代理此時相當于CoAP客戶端向服務器發(fā)送CoAP URI以請求CoAP資源。

2.2 CoAP-HTTP的響應碼映射

CoAP的響應碼占一個字節(jié)，前3位一部分，后5位一部分。為了方便描述，它被表示為c.dd的結構。其中0.XX表示CoAP請求的某種方法類型，即0.01表示GET方法，0.02為POST方法，0.03為PUT方法，0.04為DELETE方法。2.XX、4.XX或5.XX則表示CoAP響應的某種具體表現(xiàn)。圖2為CoAP與HTTP的響應碼映射表，可以清楚地看到響應碼間的映射不是完全一致的映射，并且一個CoAP響應碼可能對應兩個HTTP響應碼。此時，需要根據(jù)響應的具體情境決定映射為哪種響應碼。

響應碼映射的具體流程總結為以下幾步：

（1）代理獲得CoAP響應并解析，得到本次CoAP響應碼。

（2）根據(jù)以上CoAP-HTTP響應碼映射表匹配出對應的HTTP響應碼。

（3）當有兩個匹配的映射時需要根據(jù)具體的情況進行映射，相應準則在草案中有詳細的說明。

為加快查表的速度，可建立一個Map以存儲這張映射表，數(shù)據(jù)結構為Map

2.3 媒體內容映射

HC代理需要將HTTP媒體類型（Media Type）和內容編碼（Content-Encoding）翻譯為CoAP內容格式（Content-Formats）。媒體類型翻譯發(fā)生在HTTP到CoAP方向的GET、POST或PUT方法及CoAP至0 HTTP方向的2.XX響應中。特別地，PUT和POST方法需要將Content-Type和Content-Encoding映射為單一的CoAP Content-Formats選項，GET方法需要將Accept和Accept-Encoding映射為單一的CoAP Accept選項。為產生HTTP響應，CoAP Content-Formats選項映射為合適的HTTP Content-Type和Content-Encoding的組合。

可能出現(xiàn)兩種特殊情境：當一個HTTP請求包含Content-Type和Content-Encoding，但HC代理無法映射為等價的CoAP Content-Formats時，應該返回415（不支持的媒體類型）。如果HC代理接收到一個無法識別其Content-Formats的CoAP響應，它可以返回一個沒有Content-Type頭的HTTP實體，或者進一步檢查數(shù)據(jù)以決定其類型。

HTTP到CoAP方向的資源集可能有1000多種IANA注冊的媒體類型，而CoAP中只定義了6種類型。因此，根據(jù)HC代理的應用程序的松/緊耦合度，HC代理可以實現(xiàn)不同的媒體類型映射機制。當緊耦合時，HC代理明確知道應用支持哪種Content-Format，嚴格執(zhí)行媒體類型的映射。但當HC代理是一個通用的應用層網關時，太嚴格就會大大減少成功轉發(fā)的流量，這種情形下就需要實現(xiàn)”loose”媒體映射。

互聯(lián)網媒體類型通過一個超類別（如”text”）和緊隨其后的子類別（如”html”）及可選的參數(shù)（如”charset=utf-8”）結構化信息類型。然而這種方法并不適用于CoAP，Content-Formats將一個互聯(lián)網媒體類型和內容轉碼合并為小的整型值。為了彌補這種沒有靈活性的做法，草案中引入了”loose”媒體類型映射機制，其是代理可選的特性。”loose”媒體類型映射是將比較具體的媒體類型轉化成其超類，然后再映射為CoAP內容類型的一種。例如，”application/soap+xml”的超類是”application/xml”，這樣便可以成功地映射。在”loose”媒體類型映射機制下，代理如果找不到某個具體媒體類型的合適超類，則可以返回”application/octetstream”。表l是此機制的媒體類型通用查詢表，給定一個媒體類型，在表中從上到下與其進行對比，直到匹配為止。

媒體類型映射為內容形式的算法流程圖如圖3所示。其中C-T和C-E分別代表HTTP頭域中的Content-Type和Content-Encoding，C-F代表CoAP中的Content-Formats。

在代理功能開發(fā)的過程中，除關注協(xié)議轉換中代理的關鍵功能，根據(jù)具體的應用場景需要注意一些細節(jié)問題；此外，為了更大地發(fā)揮代理的作用，也需要將代理部署到合適的位置上。本文的下一節(jié)詳細討論了這兩點內容。

3 代理功能的開發(fā)與部署

CoRE 工作組關于CoAP與HTTP協(xié)議轉換的工作一直在進行中，第7個版本的主要進展是解決了如何從HTTP客戶端發(fā)現(xiàn)CoAP資源，及對媒體類型映射的建議。

（1）對HTTP客戶端來說，它并不知道通過代理的哪些CoAP資源是可用的（代理默認不支持能發(fā)現(xiàn)所有CoAP資源的機制）。當HC代理集成了資源發(fā)現(xiàn)的功能，HTTP客戶端便可以通過HTTP協(xié)議對代理進行資源目錄的查詢，來發(fā)現(xiàn)所有其感興趣的CoAP資源。

（2）一個新的HTTP媒體類型：”application/coap-payload”。當代理收到帶有其不識別的Content-Format的CoAP響應時（不識別的原因可能是Content-Format的值在代理部署之后注冊或者CoAP服務器使用沒有注冊的實驗數(shù)據(jù)），HC代理應該返回一個通用的application/coap-payload媒體類型，這個媒體類型代表CoAP消息可以攜帶的任何payload。application/coap-payload帶有一個參數(shù)”cf，”cf的值代表CoAP的某種Content-Fonnat，而HC代理并不識別。

3.1 代理功能的開發(fā)

代理功能的核心部分是映射模塊，此模塊需要實現(xiàn)上文描述的映射功能。本文基于實際的應用需求，給出代理開發(fā)的幾點建議。

（1）代理需要決定是否對一個請求進行映射。CoAP為此定義了Proxy-Uri頭選項，當其值為”coap”時不執(zhí)行映射，”http”時執(zhí)行映射。然而代理的主要功能即是實現(xiàn)協(xié)議轉換，所以本文中的代理是希望進行映射的。

（2） CoAP規(guī)范定義了多種不同的頭選項。當代理支持緩存功能時，需要處理Max-Age選項；其余的頭選項則直接映射為相關的HTTP頭選項。

（3） CoAP支持可靠和不可靠的消息。為保證消息傳輸?shù)陌踩?，本文建議代理默認使用可靠的消息機制，同時支持使用不可靠的消息機制。

（4）由于CoAP協(xié)議不支持所有的HTTP功能，HTTP-CoAP的映射不那么直接。代理對HTTP和CoAP者B支持的PUT、GET、POST和DELETE方法直接進行翻譯；將HTTP的HEAD方法翻譯為CoAP的GET方法；對于CoAP不支持的TRACE，OPTIONS，CONNECT，PATCH方法，代理返回501錯誤。

3.2 代理的部署

代理可以與CoAP服務器或者與HTTP客戶端在一個網域，也可以在兩者外部，即CoAP服務器及HTTP客戶端網域的外面。草案建議將代理部署在靠近CoAP服務器的一端，如圖4所示。這種情況下，代理在受限網絡的邊緣，能夠避免受限網中的HTTP流量和受限網外任何不安全的CoAP多播流量。

4 結論

目前CoRE工作組給出的HTTP-CoAP協(xié)議轉換的相關內容尚未最終定稿，工作組也一直在積極地推進有關研究。

本文基于CoAP RFC和工作組最新的草案，詳細地介紹了CoAP協(xié)議和CoAP代理的概念，同時具體描述了HTTP與CoAP協(xié)議的轉換流程，包括HTTP到CoAP的轉換和CoAP到HTTP的轉換，并對代理功能實現(xiàn)中的關鍵問題媒體內容映射進行了歸納總結。本文還進一步根據(jù)實際的應用需求給出了代理開發(fā)和部署方面的建議，為后續(xù)研究協(xié)議轉換奠定了良好的基礎。