CoAP协议笔记[RFC7252]

1. What is CoAP

    “The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained networks in the Internet of Things. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.”

 

2. Features

  • 基于REST架构:Servers make resources available under a URL, and clients access these resources using methods such as GET, PUT, POST, and DELETE.
  • UDP binding with reliability and multicast support.
  • Secure: Default choice of DTLS (Datagram Transport Layer Security) parameters is equivalent to 3072-bit RSA key.
  • Asynchronous message exchanges.
  • Simple proxy and caching capabilities.
  • Optional observation[RFC7641] and block transfer[draft-ietf-core-block-19-Block-wise transfers]

 

3. Protocol Overview 

3.1 A two-layer approach

CoAP messaging layer used to deal with UDP and the asynchronous nature of the interactions.

Request/response interactions using Method Code and Response Code.

3.2 Messaging Model

Reliability is provided by marking a message as Confirmable (CON) message

A message that does not require reliable transmission can be sent as a Non-confirmable message (NON).

3.3 Request/Response Model 

CoAP request and response semantics are carried in CoAP messages, which include either a Method Code or Response Code.

Request的Method code有GET, POST, PUT, DELETE四种。

Response有Piggybacked ResponseSeparate Response, Non-confirmable Response.

 

4. Format

 

Version (Ver): 2-bit unsigned integer.  Implementations of this specification MUST set this field to 1 (01 binary).

Type (T): 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3)

Token Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes).

Code:8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits).一般写成c.dd的形式,可以参考CoAP Code Registries.

Message ID: 16-bit unsigned integer in network byte order. Used to match messages of type Acknowledgement/Reset to messages of type Confirmable/Nonconfirmable.

Token: Used to match a response with a request.[0-8bytes].

Option: 在CoAP mesage中可以携带一些列的options (以Option Number表示)。每一个option组成如下:

Option Delta:4-bit unsigned integer. A value between 0 and 12.

如果Option Delta == 13, 那么Option Delta (extended)部分为1 byte,Option Delta = 13+Option Delta (extended)

如果Option Delta == 14, 那么Option Delta (extended)部分为2 byte,Option Delta = 14+255+Option Delta (extended)

Option Delta == 15无效。

Option Length:4-bit unsigned integer. A value between 0 and 12.

如果Option Length== 13, 那么Option Length(extended)部分为1 byte,Option Length= 13+Option Length(extended)

如果Option Length== 14, 那么Option Length(extended)部分为2 byte,Option Length= 14+255+Option Length(extended)

Option Delta == 15无效。

Option Number的计算

Option Number从option delta中得到。The Option Number is calculated by simply summing the Option Delta values of this and all previous options before it.也就是说某一个option的option number就是它之前所有Option的Option delta和它自己的option delta加起来的值。

 

5. Message Transmission

     有四种消息类型: Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

5.1 Messages Transmitted Reliably

  • 使用Confirmable (CON) message,Request和Response都可以使用这种Type.
  • 收到Confirmable (CON) message后有两种选择,(a)回Acknowledgement message (b)Reject the message. 
  • 如果要拒绝Confirmable (CON) message,则发送Reset (RST) message,然后忽略这个消息。
  • 重传。UDP不可靠,Sender发出Confirmable (CON) message后依靠a timeout and a retransmission counter来确定重传时机。

5.2 Messages Transmitted without Reliability

  • Request和Response都可以使用这种Type.
  • 不需要对方回Acknowledgement.
  • 果要拒绝Non-confirmable (NON) message,则发送Reset (RST) message,然后忽略这个消息。

总结下Mesage Type的使用如下:

*表示不是正常的操作,只是为了引起对方回Reset message(CoAP ping)。

 

6. Request/Response

6.1 Requset

  • CoAP supports the basic methods of GET, POST, PUT, and DELETE.

6.1.1 Method Code

  • GET:获取Server上的资源。Server可能回2.05 (Content) or 2.03 (Valid) Response Code。
  • POST:通常用来创建新的资源或者更新资源。如果资源已经被创建,Server回2.01 (Created) Response Code;如果PSOT成功但是Server没有创建资源,Server回2.04 (Changed) Response Code;如果POST成功导致目标资源删除,Server回2.02 (Deleted) Response Code。
  • PUT:更新Server上的资源。如果资源存在,回2.04(Changed) Response Code;如果资源不存在,则Server可能会创建资源,回2.01 (Created) Response Code。如果资源不能被创建或修改,则回Error Response.
  • DELETE:删除Server上的资源。回2.02 (Deleted) Response Code。

6.2 Response

  有Piggybacked Response, Separate Response, Non-confirmable Response三种类型

  • Piggybacked Response. 最常用的类型,Reponse内容直接放在acknowledges中。
  • Separate Response. Server暂时没办法直接回(可能需要更多的时间准备),直接回Empty Acknowledgement。当Server准备好了,给Client发Confirmable message(也可以是Non-confirmable message),最后Client回Acknowledgement。如果Server在回复Clinet之前又收到Client的重传,那么也回Empty Acknowledgement。
  • Non-confirmable Response. Client发出Non-confirmable message,Server一般也回Non-confirmable message。Spec说Server也可以发Confirmable message[P14].

三个Response类型的例子:

     

 

     

可以看到Server回Separate Response的时候,Token和Client的Request时的Token是一致的,但是Message ID已经变掉了。

6.2.1 Response Code

  • Success:2.xx
  • Client Error:4.xx
  • Server Error:5.xx

Success 2.xx

  • 2.01 Created. 回复POST或者PUT。
  • 2.02 Deleted.回复DELETE,有些情况下的POST。
  • 2.03 Valid.Indicate that the response identified by the entity-tag identified by the included ETag Option is valid.所以,Response必须带ETag Option。 
  • 2.04 Changed.回复POST和PUT。
  • 2.05 Content.回复GET。

Client Error 4.xx

  • 4.00 Bad Resuest.
  • 4.01 Unauthorized
  • 4.02 Bad Option
  • 4.03 Forbidden
  • 4.04 Not Found
  • 4.05 Method Not Allowed
  • 4.06 Not Acceptable
  • 4.12 Precondition Failed
  • 4.13 Request Entity Too Large
  • 4.15 Unsupported Content-Format

Server Error 5.xx

  • 5.00 Internal Server Error
  • 5.01 Not Implemented
  • 5.02 Bad Gateway
  • 5.03 Service Unavailable
  • 5.03 Service Unavailable
  • 5.05 Proxying Not Supported

7. Options

7.1 Option Numbers

不同的Option有不同Option Number来表示。

Critical = (onum & 1);
UnSafe = (onum & 2);
NoCacheKey = ((onum & 0x1e) == 0x1c);

7.2 Option Value formats

  • empty: zero-length sequence of bytes.
  • opaque: An opaque sequence of bytes.
  • uint: non-negative integer that is represented in network byte.
  • string:Unicode string that is encoded using UTF-8 [RFC3629] in Net-Unicode form.

Critical/Elective Option

根据对于未识别的Option的处理分为Critical/Elective Option。

--如果某个Option未被识别,如果是Elective Option,直接忽略;如果是Confirmable request中的Critical Option,Server回4.02 (Bad Option)。

--Confirmable response或者Nonconfirmable message中的Critical Option,对端需要Reject the message。

--只适用于non-proxying endpoints。

Unsafe or Safe-to-Forward

根据Proxy对于未被识别的Option的处理分为Unsafe or Safe-to-Forward Option。

 

Cache-Key

Repeatable:在一个mesage中可能有一个或者多个这样的option。

7.3 Base specification Options  

7.3.1 Uri-Host, Uri-Port, Uri-Path, and Uri-Query

表示一个Resource的地址。 

  • Uri-Host Option specifies the Internet host of the resource being requested.
  • Uri-Port Option specifies the transport-layer port number of the resource.
  • Uri-Path Option specifies one segment of the absolute path to the resource.
  • Uri-Query Option specifies one argument parameterizing the resource.

7.3.2 Proxy-Uri and Proxy-Scheme

用于forward-proxy。

7.3.3 Content-Format

表示Message中Payload的类型。

7.3.4 Accept

表明Client可以接受哪种content format。如果Server不能回复此种content format,则回4.06 "Not Acceptable"。

7.3.5 Max-Age

表示Cached reposne 为Fresh状态的最大时间,超过这个时间,Cached Response为Not Fresh。

7.3.6 ETag

  • 和HTTP协议中的ETag功能类似。提供Resource的Server产生这个Tag,ETag是一个可以与Web资源关联的记号。
  • 当Client GET时,server传回Etag给client。那么下次client去访问server的同一个Resource时就可以带上这个ETag来知道server端的资源有没有改变。
  • 经常和If-Match/If-None-Match配合来使用。

一个HTTP协议使用ETag的例子:

      客户端请求一个页面(A)。 服务器返回页面A,并在给A加上一个ETag。 客户端展现该页面,并将页面连同ETag一起缓存。 客户再次请求页面A,并将上次请求时服务器返回的ETag一起传递给服务器。 服务器检查该ETag,并判断出该页面自上次客户端请求之后还未被修改,直接返回响应304(未修改——Not Modified)和一个空的响应体。

7.3.7 Location-Path and Location-Query

Relative URI to request URL that consists either of an absolute path, a query string, or both.

7.3.8 Conditional Request Options

使Client在某种特定情况下才向Server发Request。如果条件不满足Client发了request,Server会回4.12 (Precondition Failed) Response code。

7.3.8.1 if-Match
  • 通常用在resource update(PUT),条件是目标Resource或者Resource的Etag存在。
  • If-Match Option的Value可以是empty string或者一个ETag。
  • 有多个If-Macth Option的话,只要满足一个即可。
7.3.8.2 None-Match
  • 通常用在resource update(PUT),条件是目标Resource不存在。If-Match Option没有Value。

7.3.11Size1

常用在Block-wise Transfer中。

也用在当Client的包太大时,Server回复4.13 Response code,带上Size1 Option告诉Client能接受的最大值。

 

8. Caching

CoAP includes a simple caching model 

Cacheability determined by response code.

An option number mask determines if it is a cache key.

8.1 Freshness model

Freshness checked using the Max-Age Option。

  •  当一个response是“Fresh”状态时,它可以直接用来处理Request,而不用去访问origin server。
  • Origin server提供一个explicit expiration time(利用Max-Age Option)来决定某个response的“freshness”。
  • Max-Age option默认值是60s。
  • 如果Origin server不希望caching,可以设置Max-Age option的value为0。

8.2 Validation model

Validity checked using the Etag Option。

  • 当一个endpoint有多个cached response,但都不“fresh”时,Request可以使用ETag Option,作用是给origin server一个机会来选择一个stored response,并且update这个resposne的freshness。这个过程叫做“validating"”或者“revalidating”。
  • Server回复2.03 (Valid) response with Etag option。收到后就就会更新cached response的freshness。

所以我的理解是ETag就是一个标签(entity-tag),由提供Resource的Server生成,标签表示的是随时间变化的同一个Resource。

 

9. Proxying

对于Safe-to-Forward options必须forward。

Forward-Proxies

作用是代理发往Server的Request。在Request message中使用Proxy-Uri Option表明Proxy,使用Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options表明origin server。

Reverse-Proxies

不使用Proxy-Uri Option。

posted on 2016-04-07 19:54  jianqi2010  阅读(10203)  评论(0编辑  收藏  举报

导航