您好,登錄后才能下訂單哦!
這篇文章主要講解了“MQTT 5.0流量控制有什么作用”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“MQTT 5.0流量控制有什么作用”吧!
通常服務端的資源都是固定且有限的,而客戶端的流量則可能是隨時隨地變化的。正常業務(用戶集中訪問、設備大量重啟)、被惡意攻擊、網絡波動,都會導致流量出現激增,如果服務端沒有對其進行任何限制,就會導致負載迅速上升,進而導致響應速度下降,影響其他業務,甚至導致系統癱瘓。
因此,我們需要流量控制,可以是限制發送端的發送速率,也可以是限制接收端的接收速率,但最終目的都是保證系統的穩定。常用的流控算法有滑動窗口計數法、漏桶算法以及令牌桶算法。
MQTT v3 沒有規范流量控制行為,導致客戶端和服務端在實現上百花齊放,進而影響了設備的接入和管理。不過現在,MQTT v5 已經引入了流量控制功能,這也是我們接下來將要探討的內容。
在 MQTT v5 中,發送端會有一個初始的發送配額,每當它發送一個 QoS 大于 0 的 PUBLISH 報文,發送配額就相應減一,而每當收到一個響應報文(PUBACK、PUBCOMP 或 PUBREC),發送配額就會加一。如果接收端沒有及時響應,導致發送端的發送配額減為 0,發送端應當停止發送所有 QoS 大于 0 的 PUBLISH 報文直至發送配額恢復。我們可以將其視為變種的令牌桶算法,它們之間的區別僅僅是增加配額的方式從以固定速率增加變成了按實際收到響應報文的速率增加。
這種算法能夠更加積極和充分地利用資源,因為它沒有在發送速率的層面上進行限制,發送速率完全取決于對端的響應速率和網絡情況,如果接收端空閑且網絡良好,那么發送端可以得到比較高的發送速率,反之則會被限制到一個比較低的發送速率上。
為了支持流量控制,MQTT v5 新增了一個 Receive Maximum 屬性,它存在于 CONNECT 報文與 CONNACK 報文,表示客戶端或服務端愿意同時處理的 QoS 為 1 和 2 的 PUBLISH 報文最大數量,即對端可以使用的最大發送配額。如果接收端已收到但未發送響應的 QoS 大于 0 的 PUBLISH 報文數量超過 Receive Maximum 的值,接收端將斷開連接避免受到更嚴重的影響。
也許你已經發現,前文所有提到 PUBLISH 報文的地方都使用了定語: QoS 大于 0。QoS 0 消息的特性決定了它不存在響應報文,也許是覺得 QoS 0 消息的重要性不高,接收端可以通過強制的接收速率限制來約束 QoS 0 消息,也許是其他原因,總之最后我們看到的 MQTT v5 的流量控制機制完全依賴響應報文,這就導致它的流量控制只能局限在 QoS 1,2 消息中。
聊勝于無,MQTT v5 給出了一個并不完美的解決方案,或者說僅僅只是一個建議:當發送配額減為 0 時,發送端可以選擇繼續發送 QoS 為 0 的 PUBLISH 報文,也可以選擇暫停發送。其中暫停發送的行為邏輯是,如果 QoS 1,2 的 PUBLISH 報文的應答速度變慢,通常意味著接收端的消費能力已經下降,繼續發送 QoS 0 消息只會令情況變得更糟。
感謝各位的閱讀,以上就是“MQTT 5.0流量控制有什么作用”的內容了,經過本文的學習后,相信大家對MQTT 5.0流量控制有什么作用這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。