《HTTP与CoAP的协议转换代理的研究》-工学论文，软件工程论文-论文范文参考-科学狗论文网

标题

HTTP与CoAP的协议转换代理的研究

范文

宗娜++魏更宇

摘要：当受限网络连接到互联网之后，为了实现在互联网浏览器上访问受限资源，需要进行HTTP到CoAP和CoAP到HTTP的转换。本文基于CoRE工作组当前的草案，讨论了协议转换的流程和转换中的关键问题。参照CoRE工作组的标准进行研究、开发和部署，成为今后重要的课题。因此在总结工作组的主要进展的基础上，本文对相关代理功能的开发和部署提出了建议。

关键词：COAP；协议转换；映射；反向代理

中图分类号：TP319 文献标识码：A DOI： 10.3969/j.issn.1003-6970.2015.10.021

引言

物联网（Internet of things，IoT）是新一代信息技术的重要组成部分，也是“信息化”时代的重要发展阶段。随着可穿戴设备和智能家居等的兴起，主要由传感器节点组成的资源受限网络也日益引起关注。组成这种受限网络的结点往往是供电功率低、处理能力弱、存储容量小，因此组成受限网络的通信链路通常是低速的和多差错的。而传统互联网中普遍使用的应用层协议HTTP，由于复杂、协议头开销大而被认为不适用于资源受限网络。在万维网已经成为互联网中最重要的应用技术的情况下，CoAP 工作组将受限网络作为万维网的一种延伸，CoRE（Constrained Restful Environment）工作组始终关注HTTP-CoAP协议的转换功能，相关的协议草案也一直在演进和更新中。CoAP协议的基础内容已经定义在RFC7252中，有关描述HTTP-CoAP代理的最新草案是第7个版本，而且还在进一步的演进中。

物联网的资源访问主要有两种类型，第一种是从CoAP客户端访问CoAP服务器端的资源；第二种是从HTTP客户端访问CoAP服务器端的资源。而第二种方式中，HTTP客户端就是目前互联网上的浏览器，这种方式可能是今后最重要的一种方式。在这种方式中对资源的访问就需要对HTTP和CoAP进行转换，即将HTTP的请求转换为CoAP的请求，之后将CoAP的响应转换为HTTP的响应；总之，HTTP到CoAP和CoAP到HTTP的转换是双向的。

通过代理，用户在浏览器上可以直接访问到受限网中的资源，这将进一步实现物联网数据共享并满足OMA LWM2M中定义的应用需求。一个典型的HTIP客户端通过代理访问CoAP服务器上的资源可以描述为：浏览器发送请求到代理，代理接收后对URI进行映射并将HTTP头部重新封装为CoAP请求头，生成CoAP请求之后将其发送到受限网中的CoAP服务器。CoAP服务器对CoAP请求做出响应并发送给代理，代理对媒体类型和响应码等进行映射，重新封装为HTTP响应后将其返回客户端。本文根据CoRE 工作组的标准和实际的应用需求将给出对代理开发和部署方面的建议。

论文接下来的章节安排为：第1节介绍CoAP协议和CoAP代理，第2节详细研讨HTTP与CoAP协议转换过程中的关键问题，第3节讨论HTTP-CoAP代理的开发和部署，最后第4节对论文进行总结。

1 CoAP及CoAP代理

1.1 CoAP

CoAP是一种应用于受限网络和节点的特殊Web传输协议，核心内容为资源抽象、REST式交互以及可扩展的头选项等。CoAP在应用终端间提供请求/响应的交互模式，支持内置的资源发现，包含关键的网络概念，比如URIs和Content-Type。为了克服HTTP对于受限环境的劣势，CoAP既考虑到数据报长度的最优化，又考虑到提供可靠通信。一方面，CoAP提供REST式的方法如GET，POST，PUT和DELETE，以及可以独立定义的头选项提供的可扩展性。另一方面，CoAP基于轻量级的UDP协议，并且允许IP多播。

CoAP不是盲目的压缩了HTTP协议，考虑到资源受限设备的低处理能力和低功耗限制，它重新设计了HTTP的部分功能以适应设备的约束条件。此外，为了使协议适应物联网和M2M应用，CoAP改进了一些机制，同时增加了一些功能。

HTTP的万维网和CoAP的受限网络的协议栈比较如图1所示，可以看出 CoAP在资源受限网络中的位置等同于HTTP在互联网的位置。

可以在逻辑上认为CoAP协议采用了双层的结构。事务层（Transaction layer）处理节点间的信息交换，同时也提供对多播和拥塞控制的支持。请求/响应层（Request/Response layer）用以传输对资源进行操作的请求和响应信息。

1.2 CoAP代理

CoAP代理是一个CoAP端点，可以代表CoAP客户端执行请求。当请求不可能产生或需要缓存响应以减少响应时间、网络带宽和能源消耗时，代理的存在非常必要。在CoRE 工作组的整体架构中，代理可以实现完全不同的功能。一种是正向代理的角色，代理由客户端明确地选择；另一种是反向代理的角色，代理代表原始服务器。由于这种区别，代理既可以是CoAP到CoAP的代理，也可以是跨协议的代理。不同于HTTP代理通常提供传输协议代理的功能以支持端到端的传输层安全，CoAP到CoAP的代理不具备这个功能。

通常代理需要一种方法来确定其发送请求的潜在的请求参数，这基于它从客户端收到的请求。对于正向代理来说这种方式是完全指定的，而对于反向代理则需要特定的配置。特别地，反向代理的客户端一般不标明目标地址的位置，因此某种形式的命名空间的翻译对反向代理来说是必须的。

本文中HTTP到CoAP的代理为反向代理，即代理相当于HTTP服务器接收来自于HTTP客户端的请求，并作为CoAP客户端将提取的CoAP请求发送到受限网络，而客户端没有意识到是与代理进行通信。正如通信是两个方向，HTTP与CoAP的协议转换包含HTTP-CoAP方向和CoAP-HTTP方向。

（1） HTTP-CoAP

实现时，HTTP客户端发给代理1个HTTP请求，请求URI包含“coap”或“coaps”。代理接收后进行处理，发送到CoAP服务器。

（2） CoAP-HTTP

实现时，代理收到CoAP服务器发送的CoAP响应后进行处理，再发送回HTTP客户端。

本节主要介绍了CoAP协议及CoAP代理的功能，接下来的章节将进一步讨论HTTP-CoAP协议转换中的主要功能。

2 HTTP-CoAP协议转换

2.1 HTTP-CoAP的URI映射

目前绝大多数浏览器（火狐浏览器除外）并不支持使用”coap：∥”或”coaps：∥”发送HTTP请求，所以一个CoAP URI需要被web应用包装到HTTPURI中并通过浏览器（UA）发送到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的查询参数

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协议时，结果为http：//p.example.com/hc？coaps_target_uri=coaps：//s.example.com/light

（2） target CoAP URI作为Hosting HTTP URI的查询参数

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的查询参数时，客户端省略协议名

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）协议名后的”：∥”字符变为”/”，其他与默认映射机制一致

即http：//p.example.com/hc/coap/s.example.com/light，当target CoAP URI存在查询参数时，如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”代表协议名称（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代理事先协商使用哪种映射模板，或者使用默认映射模板。

（2）如果HC代理支持发现机制，则HC代理可以发送带有”/.well-knowm/core？”的链接，响应中若有”hct”属性，则映射模板为”hct”属性的值。

（3）根据映射模板生成Hosting HTTP URI。

（4） HTTP客户端发送Host HTTP URI到HC代理。

（5） HC代理根据映射模板提取出正确的CoAP URI。

（6）HC代理此时相当于CoAP客户端向服务器发送CoAP URI以请求CoAP资源。

2.2 CoAP-HTTP的响应码映射

CoAP的响应码占一个字节，前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响应的某种具体表现。图2为CoAP与HTTP的响应码映射表，可以清楚地看到响应码间的映射不是完全一致的映射，并且一个CoAP响应码可能对应两个HTTP响应码。此时，需要根据响应的具体情境决定映射为哪种响应码。

响应码映射的具体流程总结为以下几步：

（1）代理获得CoAP响应并解析，得到本次CoAP响应码。

（2）根据以上CoAP-HTTP响应码映射表匹配出对应的HTTP响应码。

（3）当有两个匹配的映射时需要根据具体的情况进行映射，相应准则在草案中有详细的说明。

为加快查表的速度，可建立一个Map以存储这张映射表，数据结构为Map

2.3 媒体内容映射

HC代理需要将HTTP媒体类型（Media Type）和内容编码（Content-Encoding）翻译为CoAP内容格式（Content-Formats）。媒体类型翻译发生在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的组合。

可能出现两种特殊情境：当一个HTTP请求包含Content-Type和Content-Encoding，但HC代理无法映射为等价的CoAP Content-Formats时，应该返回415（不支持的媒体类型）。如果HC代理接收到一个无法识别其Content-Formats的CoAP响应，它可以返回一个没有Content-Type头的HTTP实体，或者进一步检查数据以决定其类型。

HTTP到CoAP方向的资源集可能有1000多种IANA注册的媒体类型，而CoAP中只定义了6种类型。因此，根据HC代理的应用程序的松/紧耦合度，HC代理可以实现不同的媒体类型映射机制。当紧耦合时，HC代理明确知道应用支持哪种Content-Format，严格执行媒体类型的映射。但当HC代理是一个通用的应用层网关时，太严格就会大大减少成功转发的流量，这种情形下就需要实现”loose”媒体映射。

互联网媒体类型通过一个超类别（如”text”）和紧随其后的子类别（如”html”）及可选的参数（如”charset=utf-8”）结构化信息类型。然而这种方法并不适用于CoAP，Content-Formats将一个互联网媒体类型和内容转码合并为小的整型值。为了弥补这种没有灵活性的做法，草案中引入了”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。

在代理功能开发的过程中，除关注协议转换中代理的关键功能，根据具体的应用场景需要注意一些细节问题；此外，为了更大地发挥代理的作用，也需要将代理部署到合适的位置上。本文的下一节详细讨论了这两点内容。

3 代理功能的开发与部署

CoRE 工作组关于CoAP与HTTP协议转换的工作一直在进行中，第7个版本的主要进展是解决了如何从HTTP客户端发现CoAP资源，及对媒体类型映射的建议。

（1）对HTTP客户端来说，它并不知道通过代理的哪些CoAP资源是可用的（代理默认不支持能发现所有CoAP资源的机制）。当HC代理集成了资源发现的功能，HTTP客户端便可以通过HTTP协议对代理进行资源目录的查询，来发现所有其感兴趣的CoAP资源。

（2）一个新的HTTP媒体类型：”application/coap-payload”。当代理收到带有其不识别的Content-Format的CoAP响应时（不识别的原因可能是Content-Format的值在代理部署之后注册或者CoAP服务器使用没有注册的实验数据），HC代理应该返回一个通用的application/coap-payload媒体类型，这个媒体类型代表CoAP消息可以携带的任何payload。application/coap-payload带有一个参数”cf，”cf的值代表CoAP的某种Content-Fonnat，而HC代理并不识别。

3.1 代理功能的开发

代理功能的核心部分是映射模块，此模块需要实现上文描述的映射功能。本文基于实际的应用需求，给出代理开发的几点建议。

（1）代理需要决定是否对一个请求进行映射。CoAP为此定义了Proxy-Uri头选项，当其值为”coap”时不执行映射，”http”时执行映射。然而代理的主要功能即是实现协议转换，所以本文中的代理是希望进行映射的。

（2） CoAP规范定义了多种不同的头选项。当代理支持缓存功能时，需要处理Max-Age选项；其余的头选项则直接映射为相关的HTTP头选项。

（3） CoAP支持可靠和不可靠的消息。为保证消息传输的安全，本文建议代理默认使用可靠的消息机制，同时支持使用不可靠的消息机制。

（4）由于CoAP协议不支持所有的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协议转换的相关内容尚未最终定稿，工作组也一直在积极地推进有关研究。

本文基于CoAP RFC和工作组最新的草案，详细地介绍了CoAP协议和CoAP代理的概念，同时具体描述了HTTP与CoAP协议的转换流程，包括HTTP到CoAP的转换和CoAP到HTTP的转换，并对代理功能实现中的关键问题媒体内容映射进行了归纳总结。本文还进一步根据实际的应用需求给出了代理开发和部署方面的建议，为后续研究协议转换奠定了良好的基础。

随便看

科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。