CoAP(Constrained Application Protocol)是一种在物联网世界的类web协议,它的详细规范定义在RFC 7252。CoAP名字翻译来就是“受限应用协议”,顾名思义,使用在资源受限的物联网设备上。物联网设备的ram,rom都通常非常小,运行TCP和HTTP往往是不可以接受的。
CoAP协议有4种消息类型
CON—— 需要被确认的请求,如果CON请求被发送,那么对方必须做出响应。这有点像TCP,对方必须给确认收到消息,用以可靠消息传输。
NON—— 不需要被确认的请求,如果NON请求被发送,那么对方不必做出回应。这适用于消息会重复频繁的发送,丢包不影响正常操作。这个和UDP很像,用以不可靠消息传输。
ACK—— 应答消息,对应的是CON消息的应答。
RST—— 复位消息,可靠传输时候接收的消息不认识或错误时,不能回ACK消息,必须回RST消息。
第一行是消息头,必须有,固定4个byte。
Ver : 2bit, 版本信息,当前是必须写0x01。
T: 2bit, 消息类型,包括 CON, NON, ACK, RST这4种。
TKL: 4bit,token长度, 当前支持0~8B长度,其他长度保留将来扩展用。
Code:8bit,分成前3bit(0~7)和后5bit(0~31),前3bit代表类型。(前 3bit和后5bit用小数点分隔表示)
0.00 Indicates an Empty message
0.01-0.31 Indicates a request.
1.00-1.31 Reserved
2.00-5.31 Indicates a response.
6.00-7.31 Reserved
Message ID:16bit, 代表消息MID,每个消息都有一个ID ,重发的消息MID不变。
token值为0到8字节的序列。 ( 每条消息必须带有一个标记, 即使它的长度为零)。 每个请求都带有一个客户端生成的token, 服务器在任何结果响应中都必须对其进行回应。token类似消息ID,用以标记消息的唯一性。token还是消息安全性的一个设置,使用全8字节的随机数,使伪造的报文无法获得验证通过。
请求消息与回应消息都可以0~多个options。 主要用于描述请求或者响应对应的各个属性,类似参数或者特征描述,比如是否用到代理服务器,目的主机的端口等。
CoAP定义了许多option。消息中的每个option都有:option编号、option值长度、option值。 消息中的option号(TLV格式中的T)并不是直接指定option编号的。所有的option必须按实际option编号的递增排列,某一个option和上一个option之间的option编号差值为delta;每一个TLV格式的option号都是delta值(数据包中第一个option的delta即它的option编号)。同一个编号的option再次出现时,delta的值为0。
一个option之中的各个字段的含义如下:
在这些option中,Uri-Host、Uri-Port、Uri-Path和Uri-Query等和资源“位置”和参数有关。
【3】Uri-Host:CoAP主机名称,例如iot.baidu.com
【7】Uri-Port:CoAP端口号,默认为5683
【11】Uri-Path:资源路由或路径,例如temperature。资源路径采用UTF8字符串形式,长度不计第一个""。
【15】Uri-Query:访问资源参数,例如?value1=1&value2=2
,参数与参数之间使用“&”分隔,Uri-Query和Uri-Path之间采用“?”分隔。在这些option中,Content-Format和Accept用于表示CoAP负载的媒体格式。
【12】Content-Format:指定CoAP复杂媒体类型,媒体类型采用整数描述,例如application/json对应整数50,application/octet-stream对应整数40。
【17】Accept: 指定CoAP响应复杂中的媒体类型,媒体类型的定义和Content-Format相同。
CoAP协议中支持多个Option,例如:
第一个Option Delta=11,表示该Option表示Uri-Path(11)
第二个Option Delta=1,表示该Option=1+11,表示Content-Format(12)
第三个Option Delta=3,表示该Option=3+1+11,表示Uri-Query(15)
CoAP采用这样的方式表示多个option,而每种option都可以在HTTP协议中找到对应项。
实际携带数据内容, 若有, 前面加payload标识符“0xFF”,如果没有payload标识符,那么就代表这是一个0长度的payload。如果存在payload标识符但其后跟随的是0长度的payload,那么必须当作消息格式错误处理。
Code部分被分成了两部分,为了便于阅读,Code被描述为c.dd形式。
在CoAP请求中,Code被定义为CoAP请求方法,这些方法有GET、POST、PUT和DELETE,这些方法和HTTP协议非常相似。
【0.01】GET方法——用于获得某资源
【0.02】POST方法——用于创建某资源
【0.03】PUT方法——用于更新某资源
【0.04】DELETE方法——用于删除某资源
在CoAP响应中,Code被定义为CoAP响应码,类似于HTTP 200 OK等等。
【2.01】Created
【2.02】Deleted
【2.03】Valid
【2.04】Changed
【2.05】Content。类似于HTTP 200 OK
【4.00】Bad Request 请求错误,服务器无法处理。类似于HTTP 400。
【4.01】Unauthorized 没有范围权限。类似于HTTP 401。
【4.02】Bad Option 请求中包含错误选项。
【4.03】Forbidden 服务器拒绝请求。类似于HTTP 403。
【4.04】Not Found 服务器找不到资源。类似于HTTP 404。
【4.05】Method Not Allowed 非法请求方法。类似于HTTP 405。
【4.06】Not Acceptable 请求选项和服务器生成内容选项不一致。类似于HTTP 406。
【4.12】Precondition Failed 请求参数不足。类似于HTTP 412。
【4.15】Unsuppor Conten-Type 请求中的媒体类型不被支持。类似于HTTP 415。
【5.00】Internal Server Error 服务器内部错误。类似于HTTP 500。
【5.01】Not Implemented 服务器无法支持请求内容。类似于HTTP 501。
【5.02】Bad Gateway 服务器作为网关时,收到了一个错误的响应。类似于HTTP 502。
【5.03】Service Unavailable 服务器过载或者维护停机。类似于HTTP 503。
【5.04】Gateway Timeout 服务器作为网关时,执行请求时发生超时错误。类似于HTTP 504。
【5.05】Proxying Not Supported 服务器不支持代理功能。