如下參考于成都縱橫智控-https://www.iotrouter.com/news/2009.html 或(蘇州穩(wěn)聯)
物聯網(IoT)的快速發(fā)展離不開數據傳輸技術的進步。在眾多的數據傳輸協(xié)議中,TCP、HTTP、和MQTT各有其獨特的優(yōu)勢和應用場景。本文將詳細解析這三種協(xié)議的特點、應用及其相互之間的區(qū)別,以幫助開發(fā)者在不同的物聯網應用中選擇最合適的傳輸協(xié)議。
依據OSI網絡分層模型,TCP屬于傳輸層協(xié)議,HTTP和MQTT屬于應用層協(xié)議。TCP是HTTP和MQTT的底層協(xié)議。

TCP、HTTP、MQTT協(xié)議
TCP:傳輸控制協(xié)議
TCP是一種基于連接的可靠傳輸協(xié)議。這是互聯網協(xié)議套件的一部分,用于在網絡中的2個運用中間建立一個靠譜的數據傳輸通道。TCP增強了數據分割、重組、流量管理和擁塞控制等業(yè)務,以確保數據的穩(wěn)定性和次序傳送。這是一項面對連接的協(xié)議,規(guī)定在傳輸數據以前建立一個連接。TCP適用文件傳送、電子郵箱和網頁瀏覽對傳輸數據可靠性要求高的運用。建立一個TCP連接需要三次握手,斷開一個TCP連接需要四次揮手。TCP協(xié)議可以對上層網絡提供接口,使上層網絡數據的傳輸建立在“無差別”的網絡之上。
1.三次握手:是TCP協(xié)議建立連接的過程,確保雙方都已準備好進行數據傳輸。以下是三次握手的步驟和示意圖:
| 步驟 | 描述 | 示意圖 |
|---|---|---|
| 1 | 客戶端發(fā)送SYN:客戶端向服務器發(fā)送一個SYN(同步序列編號)請求,以初始化連接。 |
![]() TCP:三次握手 |
| 2 | 服務器發(fā)送SYN-ACK:服務器收到SYN請求后,回復一個SYN-ACK(同步序列編號-確認)包,表示同意建立連接,并告知客戶端已收到其請求。 | |
| 3 | 客戶端發(fā)送ACK:客戶端收到SYN-ACK后,再發(fā)送一個ACK(確認)包,表示確認連接已建立,雙方可以開始數據傳輸。 |
2.四次揮手:是TCP協(xié)議斷開連接的過程,確保雙方都已完成數據傳輸并同意斷開連接。以下是四次揮手的步驟及示意圖:
| 步驟 | 描述 | 示意圖 |
|---|---|---|
| 1 | 客戶端發(fā)送FIN:客戶端向服務器發(fā)送一個FIN(終止連接)請求,表示其已經完成數據發(fā)送,準備斷開連接。 |
![]() TCP:四次揮手 |
| 2 | 服務器發(fā)送ACK:服務器收到FIN請求后,回復一個ACK(確認)包,表示已收到客戶端的斷開請求,但可能還有未完成的數據需要發(fā)送。 | |
| 3 | 服務器發(fā)送FIN:服務器完成數據發(fā)送后,向客戶端發(fā)送一個FIN請求,表示其也準備斷開連接。 | |
| 4 | 客戶端發(fā)送ACK:客戶端收到服務器的FIN請求后,回復一個ACK包,表示確認斷開連接,連接正式斷開。 |
HTTP:超文本傳輸協(xié)議
HTTP用于在Web上傳送超文本(如HTML)和其他資源應用層協(xié)議。TCP的穩(wěn)定性和連接性是根據TCP。HTTP挑選客戶端-服務器模型,客戶端向服務器推送HTTP規(guī)定,服務器回到HTTP回應,以傳送需要資源。HTTP是一種無狀態(tài)協(xié)議,每個請求和響應都是獨立的,服務器不會儲存客戶端狀態(tài)信息。
| HTTP 請求/響應流程示意圖 | HTTP 請求示例 |
![]() HTTP 請求/響應流程示意圖 |
![]() HTTP 請求示例 |
HTTP連接是一種“短連接”,由于HTTP在每個規(guī)定結束后都會主動釋放連接。為保持客戶端流程的在線狀態(tài),務必再次連接到服務器。一般來說,即便不用獲得所有數據,客戶端還會每隔一段時間向服務器推送一次“維護連接”規(guī)定。服務器接到要求之后回復客戶端,表明客戶端是“線上”的。假如服務器長期接受不了客戶端的需求,但認為客戶端“撤出”,假如客戶端長期接受不了云服務器的回應,卻認為網絡已經斷開。
MQTT:遠程傳輸消息隊列
MQTT是一種基于公示/定閱的MQTT(publish/subscribe)1999年IBM發(fā)布的TCP/IP協(xié)議中創(chuàng)立了該模式的“輕”通訊協(xié)議。MQTT最大的優(yōu)點是可以為連接遠程設備提供實時可靠的信息服務,編號少,帶寬有限。它作為一種低成本、低帶寬的即時通信協(xié)議,廣泛用于物聯網、小型機器和移動應用。

以下是MQTT消息傳輸過程的示意圖:
1.客戶端連接到Broker:
CONNECT 請求:客戶端向MQTT Broker發(fā)起連接請求。
CONNACK 響應:Broker確認連接請求。
2.客戶端發(fā)布消息到主題:
PUBLISH 請求:客戶端將消息發(fā)布到特定主題。
Broker 將消息轉發(fā)給訂閱該主題的客戶端。
3.Broker 轉發(fā)消息:
PUBLISH 請求:Broker 將消息轉發(fā)給所有訂閱了該主題的客戶端。
4.客戶端確認消息接收:
PUBACK 響應:客戶端確認接收到消息,適用于QoS 1等級。
5.客戶端斷開連接:
DISCONNECT 請求:客戶端請求斷開與Broker的連接。
DISCONNECT 響應:Broker 確認斷開連接。
TCP、HTTP與MQTT的對比表格
| 特性 | TCP | HTTP | MQTT |
|---|---|---|---|
| 協(xié)議類型 | 傳輸層協(xié)議 | 應用層協(xié)議 | 應用層協(xié)議 |
| 連接建立 | 面向連接(三次握手) | 無狀態(tài)請求-響應 | 面向連接(連接保持) |
| 數據傳輸模式 | 可靠傳輸,順序保證 | 請求-響應 | 發(fā)布-訂閱 |
| 可靠性 | 高 | 取決于應用層實現 | 支持QoS等級確保可靠性 |
| 數據頭開銷 | 較大 | 較大 | 較小 |
| 傳輸效率 | 較低 | 中等 | 高 |
| 適用場景 | 可靠傳輸需求的場景 | Web瀏覽、API通信、RESTful服務 | 物聯網、實時數據傳輸 |
| 典型應用 | 文件傳輸、電子郵件、遠程登錄 | 網頁瀏覽、Web API | 物聯網設備通信、消息傳輸 |
總結
TCP、HTTP 和 MQTT 是三種不同層級和用途的協(xié)議是進行設備互聯和傳送數據的重要組成部分;TCP適用高可靠性傳送,HTTP適用Web服務與API打開,MQTT是物聯網設備通訊的不二之選。了解它們的特點和適用場景有助于在設計和實現網絡通信時做出最佳選擇。
審核編輯 黃宇
-
HTTP
+關注
關注
0文章
531瀏覽量
34689 -
TCP
+關注
關注
8文章
1417瀏覽量
82873 -
MQTT
+關注
關注
5文章
712瀏覽量
24663
發(fā)布評論請先 登錄
GraniStudio :MQTT 協(xié)議的深度剖析
什么是Modbus TCP協(xié)議
御控網關如何實現MQTT、MODBUS、OPCUA、SQL、HTTP之間協(xié)議轉換
MQTT為何成為物聯網協(xié)議
TCP協(xié)議的性能測試與評估方法
TCP協(xié)議的常見應用場景
如何優(yōu)化TCP協(xié)議的性能
什么是TCP協(xié)議及其工作原理
基于MQTT協(xié)議的車云通信設計

你了解清楚了嘛-TCP、HTTP、MQTT協(xié)議




評論