MQTT服務質量等級及抓包分析

2022-08-04 18:27:13 字數 2924 閱讀 1020

什麼是服務質量?

服務質量(qualityofservice,qos)等級是訊息傳送方與訊息接收方之間的協議,對應著訊息傳遞時不同的可靠程度。

mqtt有三種qos等級:

mqtt中訊息的發布和訂閱都有qos等級的設定,我們需要將其分開理解

1.publish的qos等級

1.1 qos 0

當client1 publish一條訊息時,如果設定的qos等於0,那麼client1只會傳送一次這條訊息,就算broker沒有收到,client1也不會管。對於broker來說,它收到client1 publish的訊息,就會publish給眾多客戶端,收不到自然也不會publish。產生的效果:broker最終會publish 0條或1條訊息,即至多一次。

1.2 qos 1

上面那個例子,如果設定qos等於1,那麼client1傳送一條訊息,broker收到後會發給client1乙個應答puback,client1如果收到應答就會停止傳送,否則,繼續傳送。broker做的事情也很簡單,收到一次訊息,就將訊息publish給眾多客戶端,同時發現qos等級為1,就向剛剛給自己publish訊息的client1傳送乙個響應puback。但是在這種互動中存在兩個問題,1:client1 publish的訊息有可能broker沒能收到,2:broker回覆的puback client1沒能收到。這樣會造成:broker收到訊息,將訊息publish出去後,client1沒能收到puback,就會繼續傳送訊息,broker就會繼續publish,直到client1收到puback為止。產生效果:broker最終會publish 至少1條訊息,即至少一次。

1.3 qos 2

還是上面的例子,如果設定qos等於2,那麼client1傳送一條訊息後,broker會回乙個pubrec(publish recevied)(但是這裡注意broker雖然已經收到了訊息但是它不會立馬publish給眾多客戶端,還要等待後續步驟),client1收到pubrec會回應乙個pubrel(publish release)(即既然你broker收到了,我client1就把這條訊息釋放了,儲存起來太佔地方),client1也不會再重**這條訊息了,因為都已經釋放這個包了,broker收到pubrel後會回覆client1乙個pubcomp(publish complete)(即這次訊息傳遞完畢),broker發完pubcomp後,才會將剛才的訊息publish給眾多客戶端。在pubcomp之前的互動中,如若有丟包同樣會重傳。產生效果:broker最終會publish 1條訊息,不會多於1條,也不會少於1條。

應用場景:

為什麼要有這三種服務質量等級呢?我們結合具體需求來思考一下

qos 0 適合什麼場景呢?適合那種訊息很頻繁但又不那麼重要的應用,如每隔幾分鐘上報一次氣溫,資料丟了就丟了,反正待會還會上報,並且丟失一次資料也不會產生多大影響。

但是,如果訊息對你很重要,你寧願收到重複的也不願意丟失一條,那你就採用qos 1

但是,如果像支付類的應用也採用qos 1的話,會產生重複支付的問題(其實已經支付成功了,只是手機沒有收到回應,又再次發起支付),這時候就需要使用qos 2了,它保證有且僅有一次訊息成功傳遞。

2.subscribe的qos等級

說完了publish的qos,我們再來談談subscribe的qos。其實我們完全可以使用上面三個例子的分析,因為clienta、clientb、clientc 訂閱 broker的訊息就相當於broker發布訊息給他們(這點從後面的抓包分析也可得以驗證),我們仍然可用publish的那一套去理解subscribe的qos,即client a subscribe訊息時設定的qos等於0,那麼broker最多隻會發一次訊息給clienta。qos設定為1,那麼broker至少會發一次訊息給到clienta,給不到就重發。qos設定為2,那麼broker保證有且只有一次訊息給到clienta。

但是有乙個問題需要注意一下,對於同乙個topic,如果client1以qos 2等級發布,clienta以qos 0等級訂閱,那麼clienta最多隻會收到一條訊息,即兩者質量等級取最低。同樣的,如果clinet1以qos 0發布一條訊息,clienta以qos 2等級去訂閱,clienta仍然最多隻會收到一條訊息,因為原則是兩者qos取最低。所以如果要想達到真正的qos 2質量,就要保證publish和subscribe都設定為 qos 2

3.抓包

下面結合抓包做一些直觀的展示

192.168.2.195為客戶端

211.159.189.50為服務端

3.1 connect 連線請求報文

從截圖中可以看出,mqtt是基於tcp的,mqtt連線前先進行的是tcp的三次握手建立tcp連線

客戶端通過傳送mqtt連線控制報文向服務端發起連線請求,控制報文型別為0x10,可變長報頭包含協議名、保活時間等資訊,有效載荷包含客戶端id資訊

3.2 connack – 確認連線請求

服務端給客戶端傳送確認資訊

3.3 訂閱請求

3.4 訂閱請求應答

3.5 發布訊息

因為發布的訊息服務質量等級為 qos 0,所以無響應

現在我們將publish 的服務質量等級設為 qos 1

再次抓包

發現每乙個publish的訊息服務端都會有乙個回應

再將服務質量等級提公升到 qos 2

抓包 和上面分析的qos 2一致,每次訊息傳遞都需要四次互動,即(publish)publish message、(pubrec)publish received、(pubrel)publish release、(pubcomp)publish complete

3.6 還想看一下subscribe的qos

我在客戶端同時發布和訂閱了相同的topic,服務質量等級都設為qos 2,

截圖中,方框框住的上面四條為客戶端向服務端publish訊息時產生的互動,滿足上面的qos 2等級的分析。下面四條為客戶端訂閱了topic而收到訊息時的互動,同時也驗證了客戶端訂閱就相當於服務端發布的猜想。

參考文章:

MQTT入門(7) 服務質量QoS

為了確保客戶端和伺服器端之間訊息的送達,mqtt支援三種訊息發布服務質量 qos quality of service b 1 qos 0 at most once 至多一次 b 訊息發布完全依賴底層 tcp ip 網路。會發生訊息丟失或重複。這一級別可用於如下情況,環境感測器資料,丟失一次讀記錄無...

分析SEO服務質量好壞方法

隨著seo在業界的關注,越來越多的人了解到搜尋引擎優化的重要性,某些網際網路企業因沒有自己的seo團隊唯有通過外單的形式請專門的人員優化,但奈於對seo的了解不深往往選擇不到真正有實力的www.cppcns.comseo團隊,所以在網上我們經常看到 某某優化公司是 原本比較正常的站點經某公司優化後就...

訪問控制列表及服務質量 QACL

一 定義 acl access control list 訪問控制列表 主要是指通過一定的訪問控制規則來實現防火牆的功能,增加安全特性的同時也通過一些擴充套件的控制規則來對網路流量進行更加有效的管理,比如流量統計 流量監控 報文重定向等等特性。qos quality of service 服務質量 ...