Labs 導(dǎo)讀

作為物聯(lián)網(wǎng)世界的主流協(xié)議之一，CoAP協(xié)議為低功耗受限設(shè)備的數(shù)據(jù)交互和網(wǎng)絡(luò)接入提供了可能，IETF在RFC7252中對其進(jìn)行了詳細(xì)的定義，本文結(jié)合CoAP協(xié)議在和家親中的應(yīng)用場景對其雙層模型及輸特性進(jìn)行介紹。

作者：毛小俊

單位：中國移動智慧家庭運營中心

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

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

在和家親中，CoAP主要應(yīng)用在下述2個場景中：

LPWAN網(wǎng)絡(luò)(包括NB-IoT、LoRa、SigFox等)下，智能設(shè)備與家開平臺通過LwM2M協(xié)議進(jìn)行交互，LwM2M協(xié)議的底層便是基于UDP/UDP+DTLS傳輸層協(xié)議之上的CoAP協(xié)議。

Wi-Fi網(wǎng)絡(luò)下，配網(wǎng)是實現(xiàn)智能設(shè)備后續(xù)注冊、上線、管控的前提條件，配網(wǎng)過程中涉及到智能組網(wǎng)終端查找、發(fā)送入網(wǎng)請求、通知設(shè)備入網(wǎng)信息、設(shè)備入網(wǎng)成功廣播、智能組網(wǎng)終端密碼變更同步等步驟，這些步驟的交互即是通過CoAP協(xié)議完成。

Part 02 ●什么是CoAP協(xié)議？●

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

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

Messaging Model：處理端到端之間的數(shù)據(jù)交換，并為各報文類型提供重傳機制，來彌補傳輸過程中的不可靠性。通過CoAP消息頭部的Message ID建立請求與應(yīng)答消息之間的關(guān)聯(lián)，實現(xiàn)可靠傳輸。

Request/Response Model：定義了Client側(cè)通過URI向服務(wù)端的資源發(fā)出操作請求和服務(wù)端響應(yīng)的規(guī)則。通過CoAP消息頭部的Token建立Request和Response關(guān)聯(lián)，實現(xiàn)可靠響應(yīng)。

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

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

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

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

CoAP請求丟失：CoAP請求已經(jīng)發(fā)出，但未到達(dá)服務(wù)端

CoAP響應(yīng)丟失：服務(wù)器已收到請求并返回響應(yīng)信息，但響應(yīng)未正確到達(dá)客戶端

與重傳機制相關(guān)的參數(shù)包括：ACK_TIMEOUT、ACK_RANDOM_FACTOR、MAX_RETRANSMIT、MAX_TRANSMIT_SPAN、MAX_TRANSMIT_WAIT

ACK_TIMEOUT：超時響應(yīng)等待時間，默認(rèn)2s。一個CON報文的初始等待時間為一個隨機數(shù)，取值范圍是ACK_TIMEOUT到ACK_TIMEOUT*ACK_RANDOM_FACTOR之間。隨著重傳次數(shù)增加，每一次的等待時間均為前一次的2倍。

ACK_RANDOM_FACTOR：隨機系數(shù)，默認(rèn)1.5。

MAX_RETRANSMIT：最大重傳次數(shù)，固定值4次。

MAX_TRANSMIT_SPAN：第一次發(fā)出CON報文到最后一次重新發(fā)送的最長時間間隔。

MAX_TRANSMIT_WAIT：第一次發(fā)出CON報文到發(fā)送方放棄接收ACK或RST報文的最長時間間隔。

為進(jìn)一步說明Messaging Model重傳機制，以和家親中設(shè)備端向智能組網(wǎng)終端發(fā)送入網(wǎng)CON請求為例，假如在本次CON報文發(fā)送中

ACK_TIMEOUT=2s

ACK_RANDOM_FACTOR=1.5

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

由于網(wǎng)絡(luò)較差嘗試了4次重新發(fā)送都未收到ACK或RST響應(yīng)報文，可以得到如下圖所示的交互結(jié)果：

需要注意的是上圖只是為了說明重傳機制的完整流程，只要CON消息發(fā)送后任意時刻，設(shè)備端收到來自服務(wù)端的ACK/RST消息，本次消息傳送便會終止。通過這種重傳機制，CoAP協(xié)議保證了端到端消息傳輸?shù)目煽啃浴?/p>

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

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

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

Response則根據(jù)Request類型和服務(wù)端當(dāng)前狀態(tài)的差異，分為Piggybacked Response、Separate Response、Non-confirmable Response3種不同類型：

? Piggybacked Response（附帶響應(yīng)）

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

? Separate Response（獨立響應(yīng)）

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

? Non-confirmable Response（無需響應(yīng)）

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

Part 05 ●總結(jié)●

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

審核編輯：劉清