【IoT美学】如何快速了解CoAP协议？一篇就够了

物联网产品的开发中，我们常常听到各种协议的名称（CoAP、MQTT等），但这些协议究竟如何去传输数据/下发指令，你都了解吗？

这一期，我主要介绍一下CoAP协议的相关内容！

如果你对这方面感兴趣，希望你在评论区留下我们的暗号：拯救小白！

也希望你能get到属于自己的知识盲点！

一、CoAP协议概述

    1.CoAP协议的产生

        物联网的初衷之一也就是通过大数据的采集分析去颠覆去交通、运输、物流、能源等生产生活的每个方面。一般而言，物联网遇到的最大的问题就是环境的不稳定性，也就是没有稳定的电源，并且无线网络的带宽、时延、丢包等问题都比较突出

    2.CoAP协议定义

        CoAP是受限制的应用协议（Constrained Application Protocol）的代名词

        对于那些物联网的设备而言接入互联网困难。在当前由PC机组成的世界，信息交换是通过TCP和应用层协议HTTP实现的。对于物联网小型设备而言，实现TCP和HTTP协议显然是一个过分的要求。对于物联网而言，CoAP这种轻量级的协议可以更好适配

        CoAP并不能替代HTTP协议，但是对于那些小设备（256KB Flash 32KB RAM 20MHz主频）而言CoAP的确是一个更好的解决方案

    3.CoAP协议在NB-IoT网络协议栈中的位置

        Device MCU

            Application

        Chipset AP

            CoAP

                CoAP   HTTP

                HTTP

            UDP/IP

                UDP/IP   TCP/IP

                TCP/IP

        Chipset CP

                NAS

                Uu

        NB-IoT 终端

            NB-IoT/eMTC

                S1-lite

                IoT Core/Existing Core

                CoAP

                IoT Platform

                第三方IoT业务服务器

                MME

                HSS

                PGW

                SGW

    4.CoAP协议特点

        CoAP协议网络传输层当前主要支持UDP

        CoAP是二进制格式的，HTTP是文本格式的，CoAP比HTTP更加紧凑

        轻量化，CoAP最小长度仅4个字节，一个HTTP的头部达几十个字节

        支持可靠传输，数据重传，块传输。确保数据可靠到达

        支持IP多播，即可以同时向多个设备发送请求

        非长连接通信，适用于低速率、低功耗物联网场景

        CoAP基于REST，服务器的资源地址和互联网一样也有类似URI的格式，客户端同样有POST，GET，PUT，DELETE方法来访问server，但是相对HTTP简化实现降低复杂度（代码更小，封包更小）

     5.RESTful架构

        REST（Representational State Transfer）是一种设计风格而不是标准，如果一个架构符合REST原则，我们就称它为RESTful架构，REST可以直译为表现层状态转化，表现层其实指的是资源的表现层。通俗来讲就是：资源在网络中某种表现形式进行状态转移。分解开来看：

        Resource：资源，即数据

        representational：某种表现形式，比如用JSON，XML等

        State Transfer：状态变化。通过动词（如POST，GET，PUT，DELETE）实现

二、CoAP协议报文结构

    1.CoAP报文结构简介

        和其他TCP IP协议簇中的协议一样，CoAP协议总是以“头”的形式出现在负载之前，而负载和CoAP头之间使用单字节0xFF‘分离

        CoAP协议报文第一行是消息头，必须有，固定4个byte，其它字段为可选：

                Ver：2bits，版本编号，指示CoAP协议的版本号。类似于HTTP 1.0 HTTP 1.1。版本编号占2位

                T：2bits，报文类型，CoAP协议定了4种不同形式的报文，包括CON，NON，ACK，RST这4种

                TKL：Token length，4bits，token长度

                Code：8bits，Code在CoAP请求报文和响应报文中具有不同的表现形式

                Message ID：16bits，报文编号，用于重复消息检测、匹配消息类型等。每个CoAP报文都有一个ID，在一次会话中ID总是保持不变。但是在这个会话结束之后，该ID会被回收利用

                Token：标识符具体内容，是ID的另一种表现，通过TKL指定Token长度

                Option：报文选项，通过报文选项可设定CoAP请求参数和负载媒体类型等

                1111 1111:CoAP报文和具体负载之间的分隔符，固定一个字节

                Payload：真正有用的被交互的数据

    2.CoAP报文结构中的Code字段

        Code占一个字节，它被分成了两部分，前3位一部分，后5位一部分，为了便于阅读，Code被描述为c.dd形式。其中0.XX表示C哦AP请求的某种方法，而2.XX、4.XX或5.XX则表示CoAP响应的某种具体表现

    3.CoAP的Request方法

        CoAP协议定义的Request方法有如下4种：

        【0.01】GET方法——用于获得某资源

        【0.02】POST方法——用于创建某资源

        【0.03】PUT方法——用于更新某资源

        【0.04】DELETE方法——用于删除某资源

        对于不能识别的方法，需要返回一个4.05（method Not Allowed ）的Piggybacked response

    4.CoAP Request方法在RESTful API中的典型应用

        资源

            一组资源的URI，比如http://example.com/resources/

            单个资源的URI，比如http://example.com/resources/142

        GET

            列出URI，以及该资源组中每个资源的详细信息（后者可选）

            获取指定的资源的详细信息，格式可以自选一个合适的网络媒体类型（比如：XML、JSON等）

        PUT

            使用给定的一组资源替换当前组资源。

            替换/创建指定的资源。并将其追加到相应的资源组中

        POST

            在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL。

            把指定的资源当做一个资源组，并在其下创建/追加一个新的元素，使其隶属于当前资源

        DELETE

            删除整组资源

            删除指定元素

    5.CoAP的响应码-2.XX

        在CoAP响应中，Code被定义为CoAP响应码，类似于HTTP 200 OK等

        【2.01】 Created：response to POST and PUT, response中可能包含一个操作结果的Resprentation ; not cacheable

        【2.02】 Deleted: response to POST and DELETE,  not cacheable

        【2.03】 Valid : 用于指示Request中ETag指定的Response是有效的，Response必须包含ETag，不能包含payload

        【2.04】  Changed：response to POST和PUT，not cacheable

        【2.05】 Content：response to GET，response中包含terget resource 的Representation，is cacheable

    6.CoAP的响应码-4.XX

        【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

    7.CoAP的响应码-5.XX

        【5.00】Internal Server Error 服务器内部错误。类似于HTTP 500

        【5.01】Not Implemented 服务器无法支持请求内容。类似于HTTP 501

        【5.02】Bad Gateway 服务器过载或者维护停机。类似于HTTP 503

        【5.03】Service Unavailable 服务器过载或者维护停机。类似于HTTP 503

        【5.04】Gateway Timeout 服务器作为网关时，执行请求时发生超时错误。类似于HTTP 504

        【5.05】Proxying Not Supported 服务器不支持代理功能

    8.CoAP协议报文结构-Option

        Option为可选项，0个或者多个options。主要用于描述请求或者响应对应的各个属性，类似参数或者特征描述，比如是否用到代理服务器，目的主机的端口等

        协议定义了Option，Option的属性有如下几类：

            Critical Option：接收方必须能够理解Option，否则消息无法正常处理

            Elective Option：接收方不识别该Option时，可以忽略，不影响消息的正常处理

    9.Option Format

        Option Delta：Option在message中的实例必须按照编号大小顺序存放

        Option length：取值0-12表示option占用的字节数；取值13时表示需要占用扩展中的一个字节，且表示option length减去269的部分；取值15时，保留

        Option value：表示Option具体内容项目

    10.CoAP中Option的定义

        CoAP定义了如下可以应用于Request和Response中的Option：

            Content-Format    Uri-Path

            ETag    Uri-Port'

            Location-Path    Uri-Query

            Location-Query    Accept

            Max-Age   If-Match

            Proxy-Uri

                If-No-Match

            Proxy-scheme

                ize1

            Uri-Host

    11.Option内容项-Uri-Host/Uri-Port/Uri-Path/Uri-Query

        Uri-Host/Uri-Port/Uri-Path/Uri-Query用于指定发往Server的Request中的目标resource，用于组合出目标resource的URI

            Uri-Host：指定目标资源所在的主机

            Uri-Port：指定目标资源所在的端口

            Uri-Path：指定目标资源绝对路径的一部分

            Uri-Query：指定URI的参数的一部分

        Request可以包含多个上述Option

    12.Option内容项-Content-Format描述

        Content-Format用于指定payload的格式（多媒体类型）

        CoAP支持多种媒体类型。从下图的信息可以发现，CoAP协议中关于媒体类型的定义比较简单，未来会根据实际情况扩展

三、CoAP协议逻辑分层模型

    1.CoAP协议逻辑分层模型

        CoAP消息模型Messages

        CoAP资源请求/响应模型Requests/Responses

        CoAP逻辑上分为两层：资源请求/响应层（Request/Response）和消息层（Messages）。Messages层只负载控制端到端的报文交互；资源请求/响应层负责传输资源操作的请求和响应

    2.CoAP Messages承载的信息

        CoAP Messages承载的信息包括

            Request

            Response

            Empty Message

    3.CoAP Messages模型

        CoAP Messages用于承载资源请求/响应模型Request/Response模型信息，有两种模式：

            Reliability Mode：可靠消息传输

                Confirmable Message需要   Acknowledgement Message 确认

                Confirmable Message和Acknowledgement Message通过Message ID匹配

        Non-Reliability Mode：非可靠消息传输

                Non-Confirmable Message不需要

                Acknowledgement Message确认

    4.CoAP Message分类

        协议定义的Message有如下几种，由报文中的【T】字段确定类型

            CON消息（Confirmable Message）：需要确认的消息，Receipt方必须对消息回复Acknowledgement或者Reset

            NON消息（Non-confirmable Message）：不需要确认的消息，但是Receipt方可能回复Reset

            ACK消息（ACK Message）：用于向Sender确认Confirmable Message已收到，可以携带Piggybacked Response

            RST消息（Reset Message）：用于回复收到无法处理的Message（Confirmable和Nonconfirmable Message），也可通过一个Empty的Confirmable Message触发一个Rest，用于Endpoint的保活检测

            Empty Message：一个既不是request也不是response的Message

    5.CoAP Message的可靠传输

        CON和ACK/Reset Message中携带Message ID用于配对是一次可靠传输过程，支持重复检测

        简单的停等基于指数回退的重传机制保证可靠性

            Client构造Con Msg发送到Server，未收到ACK或Reset时，支持基于指数回退的重发

            Server如果可以处理该Message，返回ACK，否则返回Reset

        Message的可靠传输由一个CON msg发起

        CON msg总是承载一个Request或Response，除非是一个为了触发Reset msg的empty msg

        Receipt收到一个CON msg，处理结果是：回复一个ACK msg（携带匹配的message ID）或者在如下情况下Rejecting一个消息：

            recipient不能正确处理message

            message是一个empty message

            Message存在格式错误

        Rejecting一个msg的结果是回复Reset msg或者忽略它

    6.CoAP Message的非可靠传输

        NON msg中仍然携带Message ID用于重复检测

            Client对于不需要可靠传输的Message通过Non-CON msg传递

            虽然不需要ACK确认NON Msg，Server仍然可能会返回Reset给Client（比如Server不能处理这个NON msg）

    7.CoAP Request/Response模型

        CoAP Request和Response的语法通过Message承载

        可靠传输Request的响应方式有两种：

                同步可靠响应模式（piggybacked response）

                异步可靠响应模式（Separate Response）

        非可靠传输Request和Response

    8.同步可靠响应模式（piggybacked response）

        Request和Response通过Token配对

    9.异步可靠响应模式（Separate response）

        跨多对Msg的Request和Response通过Token配对

    10.非可靠响应模式

        Request和Response通过Token配对

        对于通过NON承载的Request，Server可以选择通过CON返回Response

    11.CoAP安全

        CoAP支持通过DTLS加密，相对非加密场景的变化

                Message Layer：CoAP通信前，需要建立TLS session，Message作为DTLS的payload处理，增加了DTLS header（13 byte）的开销；Message除通过Message ID匹配外，还需要满足在同一个DTLS session内

                Request/Response Layer：Request和Response除通过Token匹配外，还必须满足在同一个DTLS session内

四、CoAP代理、块传输和安全

    1.CoAP协议逻辑分层模型

        CoAP协议模型如下图所示：

            Application

            Requests/Responses

            Messages

            UDP

            CoAP

        CoAP逻辑上分为两层：资源请求/响应层(Request/Response)和消息层（Messages）。Messages层只负责控制端到端的报文交互；资源请求/响应层负责传输资源操作的请求和响应。

    2.代理的工作模式

        按代理方向分为以下两种工作模式：

        CoAP-HTTPProxying

        HTTP-CoAPProxying

        CoAP Server

            CoAP Req

            CoAP Rsp

            PROXY

            HTTP Req

            Http Rsp

            HTTP Server

    3.BlockTransfer-块传输

        CoAP协议的特点是传输的内容小巧精简，但是在某些情况下不得不传输较大的数据。在这种情况下可以使用CoAP协议中的某个选项设定分块传输的大小，那么无论是服务器或客户端可完成分片和组装这两个动作。

    4.CoAP安全

        CoAP支持通过DTLS加密，相对非加密场景的变化MessageLayer：CoAP通信前，需要建立TLSsession，Message作为DTLS的payload处理，增加了DTLSheader(13byte)的开销；Message除通过MessageID匹配外，还需要满足在同一个DTLSsession内Request/ResponseLayer：Request和Response除通过Token匹配外，还必须满足在同一个DTLSsession内。

        非加密场景：

            Application

            Requests/Responses

            Messages

            UDP

            CoAP

        非加密场景：

            Application

            Requests/Responses

            Messages

            DTLS

            UDP

            CoAP