誕生時間

TCP協議誕生于1974年冷戰期間。 MQTT誕生于1999年互聯網初期，TCP協議比MQTT協議誕生早了25年。 Ashton提出IoT概念也是在1999年，因此MQTT協議生逢其時。當時MIT Auto-ID Labs的Kevin Ashton為了把寶潔的供應鏈上的RFID標簽和互聯網連接起來，在1999年第一個提出了IoT這個概念。

發明起因

TCP協議和MQTT協議的設計都與衛星通信有著直接的聯系。 1972年時，Kahn在IPTO公司參與了一個衛星通信網絡項目，他就搞了個子項目來搭建衛星基站的無線電數據包通信網絡。 有了這個項目的經驗，他發現有必要開發一個通用的開放架構的網絡模型，從而讓不同軟硬件的網絡都可以互相通信。

在1973年Vinton Cerf也參與了這個項目，他們倆于同年實現了TCP的第一個版本。1974年的時候，TCP協議規范正式發布，編號為RFC 675。 在20世紀90年代中期IBM在幫助石油和天然氣公司客戶設計有效的數據傳輸協議時，就出現了對MQTT這種物聯網環境下的數據傳輸協議的需求。

當時，為了實現數千英里長的石油和天然氣管道的無人值守監控，采取的設計方案是將管道上的傳感器數據通過衛星通信傳輸到監控中心。

這種應用場景有如下幾個特點：

• 石油天然氣管道線路非常長，要接許多沿線的數據采集網關；
• 服務器要能接成千上萬個通信客戶端；
• 石油管道傳感器的數據采集頻率不高，
• 不需要一下子傳輸大量數據；
• 現場采集網關由于量大，考慮到采購成本，CPU和存儲等計算資源都很有限；
• 石油管道會穿越很多無人區，附近沒有網絡設施，因此使用衛星通訊最為經濟；
• 高軌道的GEO衛星站得高看得遠，覆蓋范圍廣，但軌道高延遲就大了。中低軌道的LEO/MEO衛星延遲小，但是覆蓋區域有限，每天都會出現衛星切換時的網絡中斷。因此需要客戶端和服務器端都能夠保留消息收發狀態，在網絡恢復正常后繼續發送；
• 衛星鏈路帶寬低（當然也有高帶寬的），通信流量費用高昂；因此需要盡量節省傳輸的消息的流量開銷；
• 有些數據發送失敗，不需要重發。但是有些消息比如閥門泄露告警或控制石油管道閥門的命令，就必須要在網絡有問題的情況下也要能確保發送成功。

因此，針對石油管道傳感器和控制裝置數據采集和控制設計的傳輸協議，需要滿足如下要求：

• 服務器要能接成千上萬個客戶端；每次消息傳輸的數據量不大；
• 協議客戶端軟件要能在CPU和存儲等計算資源都很有限的單片機、單板機、RTU等上運行；
• 并能方便的實現移植到不同的硬件上；
• 帶寬低，通信流量費用高昂；需要最大限度地減少傳輸消息大小；
• 衛星不會24小時都覆蓋得到，會有段時間發生衛星通信中斷；
• 預期會遇到頻繁的網絡中斷（低帶寬，高延遲，不可靠，高成本運行的網絡），需要傳輸協議能夠異步管理消息。
• 在衛星通信中斷時：MQTT網絡中的服務器/代理可以保存和轉發從客戶端到客戶端的消息，如果斷開連接，它將能夠在以后重新連接時獲取消息。
• 在環境允許的情況下提供傳統的消息服務質量。提供不同等級的“服務質量”。

協議位置

TCP是OSI第四層的傳輸層協議。 MQTT是基于TCP的七層應用層協議。

協議定位

TCP設計考慮的是面向連接的、可靠的、基于字節流的傳輸層通信協議。 MQTT則是在低帶寬高延遲不可靠的網絡下進行數據相對可靠傳輸的應用層協議。

設計思想

TCP的核心思想是分組交換。 MQTT的核心思想是簡單并適應物聯網環境。

傳輸單位

TCP的傳輸單位是packet，當應用層向TCP層發送用于網間傳輸的、用8位字節表示的數據流，TCP則把數據流分割成適當長度的報文段，最大傳輸段大小（MSS）通常受該計算機連接的網絡的數據鏈路層的最大傳送單元（MTU）限制。 MQTT的傳輸單位是消息，每條消息字節上限在MQTT Broker代理服務器上進行設置，可以設置超過1M大小的消息上限。

技術挑戰

TCP需要解決的問題是在IP包傳輸過程中，處理異構網絡環境下的網絡擁塞、丟包、亂序、重復包等多種問題。 MQTT解決的問題是，在低帶寬高延遲不可靠的網絡下和資源有限的硬件環境內，進行相對可靠的數據傳輸。

服務質量

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