說到工業(yè)物聯(lián)網(wǎng)協(xié)議，我們要了解物聯(lián)網(wǎng)協(xié)議中有哪些種類的協(xié)議。
物聯(lián)網(wǎng)協(xié)議是指在物聯(lián)網(wǎng)環(huán)境中用于設(shè)備間通信和數(shù)據(jù)傳輸?shù)膮f(xié)議。根據(jù)不同的作用，物聯(lián)網(wǎng)協(xié)議大體上可分為傳輸協(xié)議、行業(yè)協(xié)議。
傳輸協(xié)議：一般負(fù)責(zé)子網(wǎng)內(nèi)設(shè)備間以及設(shè)備到的組網(wǎng)及通信。例如TCP，UDP，HTTP，MQTT等。這些協(xié)議能夠確保在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)的安全性和可靠性。
行業(yè)協(xié)議：某個(gè)行業(yè)范圍內(nèi)統(tǒng)一的標(biāo)準(zhǔn)協(xié)議。例如車聯(lián)網(wǎng) JT/T808、視頻GB/T 28181等一些國標(biāo)協(xié)議。
本章我們主要討論的是其中的傳輸協(xié)議。
下面列舉一些常見協(xié)議以及各個(gè)協(xié)議的優(yōu)缺點(diǎn)
UDP
UDP通信基于IP協(xié)議，將數(shù)據(jù)源IP、目的地IP和端口以及數(shù)據(jù)封裝成數(shù)據(jù)包，大小限制在64KB內(nèi)，直接發(fā)送出去。接收端只負(fù)責(zé)接收數(shù)據(jù)包，無所謂是哪個(gè)發(fā)送端的數(shù)據(jù)包。UDP通信的過程相對(duì)簡單，不需要建立連接和進(jìn)行數(shù)據(jù)包的順序傳輸，因此它的傳輸速度較快，適用于對(duì)實(shí)時(shí)性要求較高的應(yīng)用。
數(shù)據(jù)傳輸效率高，數(shù)據(jù)傳輸速度快。
不會(huì)增加網(wǎng)絡(luò)負(fù)擔(dān)。
適用于實(shí)時(shí)性要求高的數(shù)據(jù)傳輸場景。
數(shù)據(jù)傳輸不可靠，數(shù)據(jù)可能會(huì)丟失。
不支持擁塞和流量控制機(jī)制，容易導(dǎo)致網(wǎng)絡(luò)擁堵。
不支持錯(cuò)誤恢復(fù)和重傳機(jī)制，無法保證數(shù)據(jù)完整性。
主要應(yīng)用于實(shí)時(shí)數(shù)據(jù)傳輸和設(shè)備之間的快速通信，包括實(shí)時(shí)視頻和音頻流傳輸、傳感器數(shù)據(jù)采集和控制信號(hào)發(fā)送、廣播和組播等。由于UDP協(xié)議具有低時(shí)延、少開銷、無需建立連接等特點(diǎn)，能夠滿足物聯(lián)網(wǎng)中對(duì)快速傳輸和實(shí)時(shí)性要求高的應(yīng)用場景。
TCP
首先，客戶端發(fā)送一個(gè)SYN（同步）包，向服務(wù)器請(qǐng)求建立連接。服務(wù)器在收到SYN包后，回復(fù)一個(gè)SYN-ACK（同步-確認(rèn)）包，表明已收到客戶端的請(qǐng)求，并準(zhǔn)備好建立連接。最后，客戶端回復(fù)一個(gè)ACK（確認(rèn)）包，表明已經(jīng)收到服務(wù)器的回復(fù)，連接建立成功。
建立連接后，數(shù)據(jù)包的傳輸通過序列號(hào)和確認(rèn)應(yīng)答來進(jìn)行。每個(gè)數(shù)據(jù)包都有一個(gè)序列號(hào)和一個(gè)確認(rèn)號(hào)，序列號(hào)表示這個(gè)數(shù)據(jù)包的數(shù)據(jù)在整個(gè)數(shù)據(jù)流中所處的位置，確認(rèn)號(hào)表示接收端期望接收的下一個(gè)數(shù)據(jù)包的序列號(hào)。當(dāng)發(fā)送端發(fā)送數(shù)據(jù)時(shí)，會(huì)按照序列號(hào)的順序進(jìn)行發(fā)送，接收端收到數(shù)據(jù)后會(huì)回復(fù)一個(gè)ACK確認(rèn)包，表示已經(jīng)接收到該數(shù)據(jù)包。如果發(fā)送端沒有收到ACK確認(rèn)包，則會(huì)重復(fù)發(fā)送該數(shù)據(jù)包，直到收到ACK為止。
當(dāng)要斷開連接時(shí)客戶端會(huì)向服務(wù)端發(fā)送一個(gè)帶有FIN(結(jié)束)標(biāo)志的數(shù)據(jù)包，表示不在發(fā)送數(shù)據(jù)；服務(wù)段收到FIN后，回復(fù)一個(gè)帶有ACK標(biāo)志的數(shù)據(jù)包給客戶端，表示收到關(guān)閉請(qǐng)求，服務(wù)端再完成數(shù)據(jù)發(fā)送后也會(huì)給客戶端發(fā)送一個(gè)FIN標(biāo)志的數(shù)據(jù)包，表時(shí)服務(wù)端也準(zhǔn)備關(guān)閉連接，客戶端收到服務(wù)器的FIN后會(huì)返回一個(gè)ACK給服務(wù)端，表示收到。此時(shí)雙方關(guān)閉連接完成。
數(shù)據(jù)傳輸可靠性高，數(shù)據(jù)不會(huì)丟失。
支持流量控制和擁塞控制，避免網(wǎng)絡(luò)擁堵。
支持錯(cuò)誤恢復(fù)和重傳機(jī)制，可保證數(shù)據(jù)傳輸準(zhǔn)確性。
建立連接及斷開連接需要消耗大量時(shí)間，因此會(huì)增加網(wǎng)絡(luò)負(fù)擔(dān)。
數(shù)據(jù)傳輸效率較低，數(shù)據(jù)傳輸速度較慢。
不適用于實(shí)時(shí)性要求高的數(shù)據(jù)傳輸場景。
在實(shí)際使用中，基本上是使用基于TCP的一些應(yīng)用層協(xié)議，如MQTT，HTTP。
HTTP
HTTP是基于TCP的封裝，并且規(guī)定了請(qǐng)求、響應(yīng)的報(bào)文格式，HTTP是無狀態(tài)協(xié)議，每個(gè)請(qǐng)求都是獨(dú)立的，即服務(wù)端不需要記錄客戶端的狀態(tài)。
成熟穩(wěn)固：HTTP是互聯(lián)網(wǎng)上使用最廣泛的協(xié)議之一，有大量的工具和庫支持。
無狀態(tài)：默認(rèn)情況下，HTTP是無狀態(tài)的，每次請(qǐng)求之間都是獨(dú)立的，不會(huì)保留之前的狀態(tài)。
靈活強(qiáng)大：HTTP支持各種類型的媒體，還有方法如GET、POST等用于不同的操作。
基于文本：HTTP是基于文本的，便于查看和調(diào)試。
由于必須由設(shè)備主動(dòng)向服務(wù)器發(fā)送數(shù)據(jù)，難以主動(dòng)向設(shè)備推送數(shù)據(jù)。
不同于用戶交互終端如pc、手機(jī)，物聯(lián)網(wǎng)場景中的設(shè)備多樣化，對(duì)于運(yùn)算和存儲(chǔ)資源都十分受限的設(shè)備，http協(xié)議實(shí)現(xiàn)、XML/JSON數(shù)據(jù)格式的解析，都是不可能的任務(wù)。
適用于對(duì)設(shè)備硬件和網(wǎng)絡(luò)帶寬充裕的場景需要與云平臺(tái)進(jìn)行通信的設(shè)備。
MQTT
MQTT協(xié)議的底層原理是基于TCP/IP協(xié)議棧的，通過三個(gè)主要組件實(shí)現(xiàn)通信：客戶端、代理（Broker）和主題（Topic）?？蛻舳俗鳛榘l(fā)布者或訂閱者發(fā)送和接收消息，代理則負(fù)責(zé)轉(zhuǎn)發(fā)消息，主題用于標(biāo)識(shí)消息主體的類別。可以通過指定Qos用于確保消息在不同網(wǎng)絡(luò)環(huán)境下的可靠性和可用性。
QoS 0：最多一次。消息發(fā)布不會(huì)進(jìn)行重傳，不保證可靠性，可能會(huì)導(dǎo)致消息的丟失。
QoS 1：至少一次。消息發(fā)布可能會(huì)進(jìn)行重傳，確保消息至少傳輸一次，但可能會(huì)導(dǎo)致消息的重復(fù)。
QoS 2：恰好一次。消息發(fā)布會(huì)進(jìn)行重傳，確保消息恰好傳輸一次，但可能會(huì)導(dǎo)致消息的重復(fù)。
MQTT通信機(jī)制主要包括連接建立、發(fā)布、訂閱和斷開連接四個(gè)步驟。連接建立階段包括客戶端與代理之間的握手和認(rèn)證，建立起可靠的連接。發(fā)布階段是指客戶端向代理發(fā)送消息的過程，可以選擇指定消息的主題和質(zhì)量等級(jí)。訂閱階段是指客戶端對(duì)特定主題感興趣并請(qǐng)求接收相關(guān)消息的過程。斷開連接階段則是客戶端與代理之間的連接結(jié)束，釋放相關(guān)網(wǎng)絡(luò)資源。
輕量級(jí)：協(xié)議設(shè)計(jì)簡潔，網(wǎng)絡(luò)帶寬占用極低。
靈活性：可以通過不同的QoS級(jí)別和持久化會(huì)話來適應(yīng)不同的應(yīng)用場景。
可擴(kuò)展性：支持廣播和多播，可以實(shí)現(xiàn)多設(shè)備之間的協(xié)同通信。
可靠性：提供不同的QoS級(jí)別，確保消息的可靠傳遞。
在工業(yè)物聯(lián)網(wǎng)傳輸協(xié)議這個(gè)范圍內(nèi)幾乎沒有。
MQTT 是基于發(fā)布/訂閱模式的，對(duì)消息的可靠性依賴于 QoS（服務(wù)質(zhì)量）等級(jí)的設(shè)置。雖然 QoS 1 和 QoS 2 提供了消息傳輸?shù)拇_認(rèn)機(jī)制，但在網(wǎng)絡(luò)不穩(wěn)定或高負(fù)荷的情況下，可能會(huì)導(dǎo)致消息丟失或重復(fù)傳輸?shù)膯栴}。
MQTT 是為低帶寬和高延遲網(wǎng)絡(luò)環(huán)境設(shè)計(jì)的，適用于傳感器設(shè)備等物聯(lián)網(wǎng)設(shè)備的通信。但在大規(guī)模消息傳輸或高吞吐量需求的情況下，可能會(huì)面臨性能瓶頸。
雖然 MQTT 提供了即時(shí)的消息傳輸能力，但并不保證實(shí)時(shí)性，因?yàn)橄鬏數(shù)乃俣仁艿骄W(wǎng)絡(luò)延遲和各種 QoS 級(jí)別的影響。
適用于 低功耗，延遲高，不穩(wěn)定網(wǎng)絡(luò)。
為物聯(lián)網(wǎng)行業(yè)推薦協(xié)議之一，廣泛應(yīng)用于智能硬件、車聯(lián)網(wǎng)、能源、電力等場景。如果設(shè)備支持，可優(yōu)先選用。
小結(jié)
在行業(yè)中還有較多用到的協(xié)議，筆者水平有限便不一一列舉，其中不足望廣大讀者留言指正。
以上四種協(xié)議其中UDP，TCP為傳輸層協(xié)議，MQTT，HTTP為應(yīng)用層協(xié)議。傳輸層為數(shù)據(jù)傳輸?shù)母?，?yīng)用層使數(shù)據(jù)在傳輸?shù)倪^程中更方便，快捷，規(guī)范。
傳輸層和應(yīng)用層的區(qū)別
傳輸層和應(yīng)用層的區(qū)別，傳輸層是通過連接或者無連接的方式通過網(wǎng)絡(luò)將數(shù)據(jù)直接由一個(gè)位置傳輸?shù)搅硪粋€(gè)位置，應(yīng)用層則是在傳輸層的基礎(chǔ)上對(duì)數(shù)據(jù)進(jìn)行包裝，其更規(guī)范，更標(biāo)準(zhǔn)。我們將協(xié)議比作貨物的話，應(yīng)用層協(xié)議就好比火車，但我們想讓貨物完好運(yùn)到目的地，就需要做打包、裝車、驗(yàn)貨、入庫、簽回單等工作。這些工作也就是應(yīng)用層協(xié)議要做的工作。
