Labs 導讀

作為物聯網世界的主流協議之一，CoAP協議為低功耗受限設備的數據交互和網絡接入提供了可能，IETF在RFC7252中對其進行了詳細的定義，本文結合CoAP協議在和家親中的應用場景對其雙層模型及輸特性進行介紹。

和家親是中國移動面向智慧家庭用戶推出的智能連接類App，是物聯網在家庭應用場景中的落地實踐。物聯網強調的是物與物之間的連接通信，在和家親中實現這種物物連接的就是Andlink協議，它是對多種主流物聯網協議的綜合運用，其中包含CoAP、MQTT、LwM2M、HTTP等協議，他們的簡單對比如下表所示。由于多個協議都涉及到CoAP，因此本文重點介紹CoAP協議雙層模型及其傳輸特性。

Part 01.  和家親哪些場景用到了CoAP？  

在和家親中，CoAP主要應用在下述2個場景中：

1??LPWAN網絡(包括NB-IoT、LoRa、SigFox等)下，智能設備與家開平臺通過LwM2M協議進行交互，LwM2M協議的底層便是基于UDP/UDP+DTLS傳輸層協議之上的CoAP協議。

2??Wi-Fi網絡下，配網是實現智能設備后續注冊、上線、管控的前提條件，配網過程中涉及到智能組網終端查找、發送入網請求、通知設備入網信息、設備入網成功廣播、智能組網終端密碼變更同步等步驟，這些步驟的交互即是通過CoAP協議完成。

Part 02.  什么是CoAP協議？ 

CoAP協議(Constrained Application Protocol，標準文檔RFC7252)，屬于應用層協議，在M2M通信中的作用和互聯網中的HTTP類似，但在定義上只是實現了REST的一個子集，更重要區別是HTTP運行于TCP之上，而CoAP運行于UDP協議之上，由于UDP建立的是非可靠連接，在網絡數據傳輸過程中，無論是請求還是響應，均存在丟包的風險。那CoAP協議的傳輸如何保障可靠性呢？這就涉及到CoAP協議的雙層模型：

CoAP協議邏輯上分為Messaging Model和Request/Response Model，其中：

• Messaging Model：處理端到端之間的數據交換，并為各報文類型提供重傳機制，來彌補傳輸過程中的不可靠性。通過CoAP消息頭部的Message ID建立請求與應答消息之間的關聯，實現可靠傳輸。
• Request/Response Model：定義了Client側通過URI向服務端的資源發出操作請求和服務端響應的規則。通過CoAP消息頭部的Token建立Request和Response關聯，實現可靠響應。

注意區分Request/Response Model中的Token和Messaging Model中的Message ID是兩個不同字段，如下圖^[1]所示：

下面分別從Request/Response Model和Messaging Model分析CoAP協議的傳輸特性。

Part 03.  Messaging Model的可靠消息傳輸  

上述介紹的中間CoAP定義了四種不同類型的報文：CON、NON、ACK、RST。其中CON報文需要接收方確認，即每一個CON報文都對應一個頭部帶有相同Message ID的ACK報文或RST報文，如果在規定的時間內請求方未收到ACK報文或RST報文，那么客戶端將啟動 “重傳機制”。發送方未收到ACK/RST報文可能有兩種原因：

• CoAP請求丟失：CoAP請求已經發出，但未到達服務端
• CoAP響應丟失：服務器已收到請求并返回響應信息，但響應未正確到達客戶端

與重傳機制相關的參數包括：ACK_TIMEOUT、ACK_RANDOM_FACTOR、MAX_RETRANSMIT、MAX_TRANSMIT_SPAN、MAX_TRANSMIT_WAIT

• ACK_TIMEOUT：超時響應等待時間，默認2s。一個CON報文的初始等待時間為一個隨機數，取值范圍是ACK_TIMEOUT到ACK_TIMEOUT*ACK_RANDOM_FACTOR之間。隨著重傳次數增加，每一次的等待時間均為前一次的2倍。
• ACK_RANDOM_FACTOR：隨機系數，默認1.5。
• MAX_RETRANSMIT：最大重傳次數，固定值4次。
• MAX_TRANSMIT_SPAN：第一次發出CON報文到最后一次重新發送的最長時間間隔。
• MAX_TRANSMIT_WAIT：第一次發出CON報文到發送方放棄接收ACK或RST報文的最長時間間隔。

為進一步說明Messaging Model重傳機制，以和家親中設備端向智能組網終端發送入網CON請求為例，假如在本次CON報文發送中

ACK_TIMEOUT=2s

ACK_RANDOM_FACTOR=1.5

首次超時響應等待時間取t1=2.5s (2s<=t1<=2*1.5s)

由于網絡較差嘗試了4次重新發送都未收到ACK或RST響應報文，可以得到如下圖所示的交互結果：

需要注意的是上圖只是為了說明重傳機制的完整流程，只要CON消息發送后任意時刻，設備端收到來自服務端的ACK/RST消息，本次消息傳送便會終止。通過這種重傳機制，CoAP協議保證了端到端消息傳輸的可靠性。

Part 04.  Request/Response Model的消息傳輸 

Request/Response模型的交互方式類似于HTTP協議中的客戶端和服務端交互的C/S模型。

Request關注的是根據URI向服務端的資源發出操作請求，請求類型包括GET、POST、PUT 和 DELETE，但和HTTP不同的是不會先建立連接，而是通過CoAP消息進行異步交互，Request和Response之間通過CoAP消息頭部的Token字段進行匹配。

Response則根據Request類型和服務端當前狀態的差異，分為Piggybacked Response、Separate Response、Non-confirmable Response3種不同類型：

? Piggybacked Response（附帶響應）

下圖[1]中展示了對于兩個GET請求，服務端返回附帶響應的例子，一個成功，一個導致了4.04（資源未找到）。通過ACK報文回應CON報文，是最通用的類型，屬于可靠響應模式。

圖片

? Separate Response（獨立響應）

假如Server由于系統繁忙等原因無法直接給出數據響應，那么它就會立即發回一個空的ACK消息，服務端在數據準備好后服務器端就會把它組裝成一個新的CON類型消息（這需要客戶端的ACK），進行異步響應。獨立響應也屬于可靠響應模式。下圖[1]中可以看到兩次交互中使用的Token一致，都是0x73；但是Message ID已經變掉了，從0x7a10變成了0x23bb。

? Non-confirmable Response（無需響應）

Client的請求如果是NON類型，Server一般也回NON類型消息，但服務器也有可能發送一個CON類型的消息作為響應。適用于對響應可靠性要求不高的場景。例如對溫度傳感器數據的重復讀取，并不需要每一次都成功。圖中[1]request和response使用了相同的Token：0x74。

Part 05.  總結  

CoAP協議目前在和家親的智能設備大網和局域網連接、管控中都起到了重要的連接作用。作為物聯網的主流協議之一，CoAP協議除了本身單獨使用之外，還是LwM2M協議的底層消息傳遞協議，和MQTT相比，CoAP更加輕量、開銷更低，在諸如和家親設備配網等場景中更加合適。在使用CoAP時結合場景選擇合適的Message和Request/Response模型對保障傳輸可靠性，提高客戶端和服務端的交互效率十分重要。