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)行介紹。

作者：毛小俊

單位：中國移動(dòng)智慧家庭運(yùn)營中心

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

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

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

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

Wi-Fi網(wǎng)絡(luò)下，配網(wǎng)是實(shí)現(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類似，但在定義上只是實(shí)現(xiàn)了REST的一個(gè)子集，更重要區(qū)別是HTTP運(yùn)行于TCP之上，而CoAP運(yùn)行于UDP協(xié)議之上，由于UDP建立的是非可靠連接，在網(wǎng)絡(luò)數(shù)據(jù)傳輸過程中，無論是請求還是響應(yīng)，均存在丟包的風(fēng)險(xiǎn)。那CoAP協(xié)議的傳輸如何保障可靠性呢？這就涉及到CoAP協(xié)議的雙層模型：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ACK_TIMEOUT=2s

ACK_RANDOM_FACTOR=1.5

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

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

需要注意的是上圖只是為了說明重傳機(jī)制的完整流程，只要CON消息發(fā)送后任意時(shí)刻，設(shè)備端收到來自服務(wù)端的ACK/RST消息，本次消息傳送便會(huì)終止。通過這種重傳機(jī)制，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不同的是不會(huì)先建立連接，而是通過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]中展示了對于兩個(gè)GET請求，服務(wù)端返回附帶響應(yīng)的例子，一個(gè)成功，一個(gè)導(dǎo)致了4.04（資源未找到）。通過ACK報(bào)文回應(yīng)CON報(bào)文，是最通用的類型，屬于可靠響應(yīng)模式。

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

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

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

Client的請求如果是NON類型，Server一般也回NON類型消息，但服務(wù)器也有可能發(fā)送一個(gè)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é)議除了本身單獨(dú)使用之外，還是LwM2M協(xié)議的底層消息傳遞協(xié)議，和MQTT相比，CoAP更加輕量、開銷更低，在諸如和家親設(shè)備配網(wǎng)等場景中更加合適。在使用CoAP時(shí)結(jié)合場景選擇合適的Message和Request/Response模型對保障傳輸可靠性，提高客戶端和服務(wù)端的交互效率十分重要。

審核編輯：劉清