宗娜++魏更宇

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

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

中圖分類號：TP319 文獻(xiàn)標(biāo)識碼：A DOI： 10.3969/j.issn.1003-6970.2015.10.021

引言

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

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

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

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

1 CoAP及CoAP代理

1.1 CoAP

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

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

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

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

1.2 CoAP代理

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

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

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

（1） HTTP-CoAP

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

（2） CoAP-HTTP

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

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

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

2.1 HTTP-CoAP的URI映射

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

URI映射是代表CoAP資源的URI轉(zhuǎn)化為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映射分為默認(rèn)映射，簡單形式的映射和高級形式的映射。

默認(rèn)映射是直接將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當(dāng)CoAP URI中存在查詢元素時，附加到base URI后則自然成為Hosting HTTP URI的查詢部分。默認(rèn)映射機(jī)制是HC代理默認(rèn)啟用的。

簡單形式的映射分為以下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。當(dāng)使用coaps協(xié)議時，結(jié)果為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的路徑部分，此時與默認(rèn)映射機(jī)制一致

（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)椤?”，其他與默認(rèn)映射機(jī)制一致

即http：//p.example.com/hc/coap/s.example.com/light，當(dāng)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”代表主機(jī)和端口號host[”：”port]，p代表URI中的路徑字段，q代表URI中的查詢字段

即Hosting HTTP URI =http：//p.example.com/hc？s=coap&hp=s.example.com&p=/light&q=，當(dāng)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é)商使用哪種映射模板，或者使用默認(rèn)映射模板。

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

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

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

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

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

2.2 CoAP-HTTP的響應(yīng)碼映射

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

響應(yīng)碼映射的具體流程總結(jié)為以下幾步：

（1）代理獲得CoAP響應(yīng)并解析，得到本次CoAP響應(yīng)碼。

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

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

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

2.3 媒體內(nèi)容映射

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 代理的部署

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

4 結(jié)論

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

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