誕生時(shí)間

TCP協(xié)議誕生于1974年冷戰(zhàn)期間。 MQTT誕生于1999年互聯(lián)網(wǎng)初期，TCP協(xié)議比MQTT協(xié)議誕生早了25年。 Ashton提出IoT概念也是在1999年，因此MQTT協(xié)議生逢其時(shí)。當(dāng)時(shí)MIT Auto-ID Labs的Kevin Ashton為了把寶潔的供應(yīng)鏈上的RFID標(biāo)簽和互聯(lián)網(wǎng)連接起來，在1999年第一個(gè)提出了IoT這個(gè)概念。

發(fā)明起因

TCP協(xié)議和MQTT協(xié)議的設(shè)計(jì)都與衛(wèi)星通信有著直接的聯(lián)系。 1972年時(shí)，Kahn在IPTO公司參與了一個(gè)衛(wèi)星通信網(wǎng)絡(luò)項(xiàng)目，他就搞了個(gè)子項(xiàng)目來搭建衛(wèi)星基站的無線電數(shù)據(jù)包通信網(wǎng)絡(luò)。 有了這個(gè)項(xiàng)目的經(jīng)驗(yàn)，他發(fā)現(xiàn)有必要開發(fā)一個(gè)通用的開放架構(gòu)的網(wǎng)絡(luò)模型，從而讓不同軟硬件的網(wǎng)絡(luò)都可以互相通信。

在1973年Vinton Cerf也參與了這個(gè)項(xiàng)目，他們倆于同年實(shí)現(xiàn)了TCP的第一個(gè)版本。1974年的時(shí)候，TCP協(xié)議規(guī)范正式發(fā)布，編號為RFC 675。 在20世紀(jì)90年代中期IBM在幫助石油和天然氣公司客戶設(shè)計(jì)有效的數(shù)據(jù)傳輸協(xié)議時(shí)，就出現(xiàn)了對MQTT這種物聯(lián)網(wǎng)環(huán)境下的數(shù)據(jù)傳輸協(xié)議的需求。

當(dāng)時(shí)，為了實(shí)現(xiàn)數(shù)千英里長的石油和天然氣管道的無人值守監(jiān)控，采取的設(shè)計(jì)方案是將管道上的傳感器數(shù)據(jù)通過衛(wèi)星通信傳輸?shù)奖O(jiān)控中心。

這種應(yīng)用場景有如下幾個(gè)特點(diǎn)：

石油天然氣管道線路非常長，要接許多沿線的數(shù)據(jù)采集網(wǎng)關(guān)；

服務(wù)器要能接成千上萬個(gè)通信客戶端；

石油管道傳感器的數(shù)據(jù)采集頻率不高，

不需要一下子傳輸大量數(shù)據(jù)；

現(xiàn)場采集網(wǎng)關(guān)由于量大，考慮到采購成本，CPU和存儲等計(jì)算資源都很有限；

石油管道會穿越很多無人區(qū)，附近沒有網(wǎng)絡(luò)設(shè)施，因此使用衛(wèi)星通訊最為經(jīng)濟(jì)；

高軌道的GEO衛(wèi)星站得高看得遠(yuǎn)，覆蓋范圍廣，但軌道高延遲就大了。中低軌道的LEO/MEO衛(wèi)星延遲小，但是覆蓋區(qū)域有限，每天都會出現(xiàn)衛(wèi)星切換時(shí)的網(wǎng)絡(luò)中斷。因此需要客戶端和服務(wù)器端都能夠保留消息收發(fā)狀態(tài)，在網(wǎng)絡(luò)恢復(fù)正常后繼續(xù)發(fā)送；

衛(wèi)星鏈路帶寬低（當(dāng)然也有高帶寬的），通信流量費(fèi)用高昂；因此需要盡量節(jié)省傳輸?shù)南⒌牧髁块_銷；

有些數(shù)據(jù)發(fā)送失敗，不需要重發(fā)。但是有些消息比如閥門泄露告警或控制石油管道閥門的命令，就必須要在網(wǎng)絡(luò)有問題的情況下也要能確保發(fā)送成功。

因此，針對石油管道傳感器和控制裝置數(shù)據(jù)采集和控制設(shè)計(jì)的傳輸協(xié)議，需要滿足如下要求：

服務(wù)器要能接成千上萬個(gè)客戶端；每次消息傳輸?shù)臄?shù)據(jù)量不大；

協(xié)議客戶端軟件要能在CPU和存儲等計(jì)算資源都很有限的單片機(jī)、單板機(jī)、RTU等上運(yùn)行；

并能方便的實(shí)現(xiàn)移植到不同的硬件上；

帶寬低，通信流量費(fèi)用高昂；需要最大限度地減少傳輸消息大小；

衛(wèi)星不會24小時(shí)都覆蓋得到，會有段時(shí)間發(fā)生衛(wèi)星通信中斷；

預(yù)期會遇到頻繁的網(wǎng)絡(luò)中斷（低帶寬，高延遲，不可靠，高成本運(yùn)行的網(wǎng)絡(luò)），需要傳輸協(xié)議能夠異步管理消息。

在衛(wèi)星通信中斷時(shí)：MQTT網(wǎng)絡(luò)中的服務(wù)器/代理可以保存和轉(zhuǎn)發(fā)從客戶端到客戶端的消息，如果斷開連接，它將能夠在以后重新連接時(shí)獲取消息。

在環(huán)境允許的情況下提供傳統(tǒng)的消息服務(wù)質(zhì)量。提供不同等級的“服務(wù)質(zhì)量”。

協(xié)議位置

TCP是OSI第四層的傳輸層協(xié)議。 MQTT是基于TCP的七層應(yīng)用層協(xié)議。

協(xié)議定位

TCP設(shè)計(jì)考慮的是面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。 MQTT則是在低帶寬高延遲不可靠的網(wǎng)絡(luò)下進(jìn)行數(shù)據(jù)相對可靠傳輸?shù)膽?yīng)用層協(xié)議。

設(shè)計(jì)思想

TCP的核心思想是分組交換。 MQTT的核心思想是簡單并適應(yīng)物聯(lián)網(wǎng)環(huán)境。

傳輸單位

TCP的傳輸單位是packet，當(dāng)應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)?、?位字節(jié)表示的數(shù)據(jù)流，TCP則把數(shù)據(jù)流分割成適當(dāng)長度的報(bào)文段，最大傳輸段大?。∕SS）通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳送單元（MTU）限制。 MQTT的傳輸單位是消息，每條消息字節(jié)上限在MQTT Broker代理服務(wù)器上進(jìn)行設(shè)置，可以設(shè)置超過1M大小的消息上限。

技術(shù)挑戰(zhàn)

TCP需要解決的問題是在IP包傳輸過程中，處理異構(gòu)網(wǎng)絡(luò)環(huán)境下的網(wǎng)絡(luò)擁塞、丟包、亂序、重復(fù)包等多種問題。 MQTT解決的問題是，在低帶寬高延遲不可靠的網(wǎng)絡(luò)下和資源有限的硬件環(huán)境內(nèi)，進(jìn)行相對可靠的數(shù)據(jù)傳輸。

服務(wù)質(zhì)量

TCP是一個(gè)可靠的流傳輸服務(wù)，通過ACK確認(rèn)和重傳機(jī)制，能夠保證發(fā)送的所有字節(jié)在接收時(shí)是完全一樣的，并且字節(jié)順序也是正確的。 MQTT提供三種可選的消息發(fā)布的QoS服務(wù)等級。MQTT客戶端和MQTT代理服務(wù)器通過session機(jī)制保證消息的傳輸可靠性。開發(fā)人員可以根據(jù)業(yè)務(wù)需要選擇其中一種。