项目源码地点：https://github.com/eclipse/californium

引言

物联网时代，所有设备都可以接入我们的互联网。想想看只要有一台智妙手机，就可以操控所有的设备，也可以获取到所有设备收罗的信息。不外，并不是所有设备都支持HTTP协议的，并且让设备支持HTTP协议也不现实，因为对付设备来说，这个协议太重了，会耗损大量的带宽和电量。于是CoAP协议也就运应而生了，我们可以把它看为超简化版的HTTP协议。而Californium框架，就是对CoAP协议的Java实现。

CoAP协议

在阅读Californium框架之前，我们需要对CoAP协议有个大抵的相识，已经分明白的同学可以直接跳过本章节。

CoAP报文

首先让我们看一下CoAP协议的报文是长啥样的：

Version (Ver)：长度为2位，暗示CoAP协议的版本号。当前版本为01（二进制暗示形式）。

Type (T)：长度为2位，暗示报文范例。个中种种型及二进制暗示形式如下，Confirmable (00)、Non-confirmable (01)、Acknowledgement (10)、Reset (11)。在描写的时候为了轻便，会将Confirmable缩写为CON，Non-confirmable缩写为NON，Acknowledgement缩写为ACK，Reset缩写为RST。好比一个报文的范例为Confirmable，我们就会简写为CON报文。

Token Length (TKL)：长度为4位，暗示Token字段的长度。

Code：长度为8位，暗示响应码。个中前3位代表一个数，后5位代表一个数。如010 00000，转为十进制就是2.00（暗示时中间带一个点），其意思可以领略为HTTP中200 OK响应码。

Message ID：长度为16位，暗示动静id。用来暗示是否为同一个的报文（重发场景下，去重会用到），可能CON请求报文和ACK响应报文的匹配。

Token：长度由TKL字段抉择，暗示一次会话记录。用来关联请求和响应。有人大概有迷惑，Message ID不是可以将请求和响应关联吗？简直，CON范例的请求报文与ACK范例的响应报文可以用Message ID举办关联，但NON范例的报文由于没有要求是一对的，所以假如NON范例的报文想成对，那就只能通过沟通的Token来匹配了。

Options：长度不确定，暗示报文的选项。雷同为HTTP的请求头，内容包罗Uri-Host、Uri-Path、Uri-Port等等。

1 1 1 1 1 1 1 1：Payload Marker，用来断绝Options字段和Payload字段。

Payload：长度由数据包抉择，暗示应用层需要的数据。

动静传输模子

CoAP协议是固然是成立在UDP之上的，可是它有靠得住和不行靠两种传输模子。

靠得住传输模子

如上图，客户端通过提倡一个CON报文（Message ID = 0x7d34），处事端在收到CON报文之后，需要回覆一个ACK报文（Message ID = 0x7d34）。通过Message ID将CON报文和ACK报文对应起来。

确保靠得住传输的要领有俩：其一，通过处事端回覆ACK报文，劳务派遣管理系统，客户端可以确认CON报文已被处事端吸收；其二，超时重传机制。若客户端在一按时间内未收到ACK报文，则认为CON报文已经在链路上丢失，这时候就会重传CON报文，重传时间和次数可设置。

不行靠传输模子

如上图，客户端提倡一个NON报文（Message ID = 0x01a0）之后，处事端无需回覆响应，客户端也不会重发。

请求与响应模子

由于存在靠得住与不行靠两种传输模子，那么对应的也会存在两种请求与响应模子。

CON请求，ACK响应

如上图，客户端提倡了一个CON报文（Message ID = 0xbc90, Code = 0.01 GET, Options = {“Uri-Path”:”/temperature”}, Token = 0×71），处事端在收到查询温度的请求之后，回覆ACK报文（Message ID = 0xbc90, Code = 2.05 Content, Payload = “22.5 C”, Token = 0×71）。也就是说处事端可以在ACK报文中，就将客户端查询温度的功效一起返回。

虽然，尚有一种环境，那就是处事端大概由于某些原因不顿时返回功效。如上图，客户端提倡查询温度的CON报文之后，处事端先回覆ACK报文。一段时间事后，处事端再提倡CON报文给客户端，并将温度的功效一起携带，客户端收到功效之后回覆ACK报文。

NON请求，NON响应