EMQ IoT物聯(lián)網(wǎng)技術 2022-07-24 19:16 發(fā)表于上海 引言：首個將 QUIC 引入 MQTT 的開創(chuàng)性產(chǎn)品 在最新發(fā)布的 5.0 版本中，EMQX 開創(chuàng)性地引入了 QUIC 支持。 QUIC 是下一代互聯(lián)網(wǎng)協(xié)議 HTTP/3 的底層傳輸協(xié)議，與 TCP/TLS 協(xié)議相比，它在減少連接開銷與消息延遲的同時，為現(xiàn)代移動互聯(lián)網(wǎng)提供了有效靈活的傳輸層。 本文將通過對 MQTT over QUIC 的詳細解析，為大家展現(xiàn)這一領先技術實現(xiàn)對于物聯(lián)網(wǎng)場景的優(yōu)勢與價值，幫助大家更有效地借助 EMQX 5.0 對 QUIC 的支持能力，在各類 MQTT 應用場景中進行更加高效、低成本的物聯(lián)網(wǎng)數(shù)據(jù)傳輸。QUIC 是一種建立在 UDP 之上通用的傳輸層網(wǎng)絡協(xié)議，最初由 Google 提出，作為 TCP+TLS 的替代方案，旨在改善用戶體驗。 與現(xiàn)有的 TLS over TCP 方案相比，QUIC 有很多優(yōu)勢：- 快速建立低延遲連接（1 RTT 或者 0 RTT）
- 端到端加密，握手通過 TLS 1.3 進行身份驗證
- 現(xiàn)有網(wǎng)絡無需改造升級即可支持
因其高效的傳輸效率和多路并發(fā)的能力，QUIC 已經(jīng)成為下一代互聯(lián)網(wǎng)協(xié)議 HTTP/3 的底層傳輸協(xié)議。HTTP/3 協(xié)議介紹 2018 年 10 月，IETF 的 HTTP 和 QUIC 工作組聯(lián)合決定將 QUIC 上的 HTTP 映射稱為 HTTP/3，以提前使其成為全球標準。2022 年 6 月 6 日，IETF 將 HTTP/3 標準化為RFC 9114。 HTTP/3 的目標是通過解決 HTTP/2 的傳輸相關問題，在所有形式的設備上提供快速、可靠和安全的 Web 連接。HTTP/3 使用與 HTTP/2 版本類似的語義，包括相同的請求方法、狀態(tài)代碼和消息字段，兩者根本區(qū)別在于，HTTP/2 底層使用的是 TCP/TLS 協(xié)議，而 HTTP/3 使用的是 QUIC 協(xié)議。 根據(jù) W3Techs 統(tǒng)計，互聯(lián)網(wǎng)至少 40% 的流量是基于 QUIC 的，前 1000 萬個網(wǎng)站中的 25% 已經(jīng)支持 HTTP/3 協(xié)議，包括 Google，Youtube，F(xiàn)acebook 等頂流站點。 MQTT 是基于 TCP 的物聯(lián)網(wǎng)通信協(xié)議，緊湊的報文結構能夠在嚴重受限的硬件設備和低帶寬、高延遲的網(wǎng)絡上實現(xiàn)穩(wěn)定傳輸；心跳機制、遺囑消息、QoS 質(zhì)量等級等諸多特性能夠應對各種物聯(lián)網(wǎng)場景。盡管如此，由于底層 TCP 傳輸協(xié)議限制，某些復雜網(wǎng)絡環(huán)境下 MQTT 協(xié)議存在固有的弊端：- 網(wǎng)絡切換導致經(jīng)常性連接中斷
- 斷網(wǎng)后重新建立連接困難：斷網(wǎng)后操作系統(tǒng)釋放資源較慢，且應用層無法及時感知斷開狀態(tài)，重連時 Server/Client 開銷較大
- 弱網(wǎng)環(huán)境下數(shù)據(jù)傳輸受限于擁塞、丟包偵測和重傳機制
例如車聯(lián)網(wǎng)用戶通常會面對類似的問題：車輛可能會運行在山區(qū)、礦場、隧道等地方，當進入到信號死角或被動切換基站時會導致連接中斷，頻繁連接中斷與較慢的連接恢復速度會導致用戶體驗變差。在一些對數(shù)據(jù)傳輸實時性和穩(wěn)定性要求較高的業(yè)務，如 L4 級別的無人駕駛中，客戶需要花費大量的成本來緩解這一問題。在上述這類場景中，QUIC 低連接開銷和多路徑支持的特性就顯示出了其優(yōu)勢。經(jīng)過更深入的探索，我們認為 MQTT Over QUIC 可以非常好地解決這一困境 —— 基于 QUIC 0 RTT/1 RTT 重連/新建能力，能夠在弱網(wǎng)與不固定的網(wǎng)絡通路中有效提升用戶體驗。EMQX 5.0 的 MQTT over QUIC 實現(xiàn) EMQX 目前的實現(xiàn)將傳輸層換成 QUIC Stream，由客戶端發(fā)起連接和創(chuàng)建 Stream，EMQX 和客戶端在一個雙向 Stream上實現(xiàn)交互。考慮到復雜的網(wǎng)絡環(huán)境，如果客戶端因某種原因未能通過 QUIC 握手，建議客戶端自動退回到傳統(tǒng) TCP 上，避免系統(tǒng)無法建立跟服務器的通信。
目前 EMQX 5.0 中已經(jīng)實現(xiàn)了以下特性：- 更高級的擁塞控制：有效降低數(shù)據(jù)丟包率，在測試中在網(wǎng)絡波動的情況下仍能持續(xù)穩(wěn)定傳輸數(shù)據(jù)
- 運維友好：減少大規(guī)模重連導致的開銷（時間開銷、客戶端/服務器性能開銷），減少不必要的應用層狀態(tài)遷移而引發(fā)的系統(tǒng)過載（0 RTT）
- 更靈活的架構創(chuàng)新：比如 Direct server return (DSR，服務器直接返回模式)，只有入口/請求流量經(jīng)過 LB，出口和響應流量繞過 LB 直接回到客戶端，減少 LB 的瓶頸
- 多路徑支持，連接平滑遷移：從 4G 切換到 WIFI, 或者因為 NAT Rebinding 導致五元組發(fā)生變化，QUIC 依然可以在新的五元組上繼續(xù)進行連接狀態(tài)，尤其適用于網(wǎng)絡經(jīng)常性變化的移動設備
- 更敏捷的開發(fā)部署：協(xié)議棧的實現(xiàn)在 userspace，能夠開發(fā)快速迭代
- 端到端加密：未加密的包頭帶有極少信息， 減少傳輸路徑中中間節(jié)點的影響，帶來更好的安全性和更可控的用戶體驗
- 不同主題的流：對于獨立主題，每個主題可以有獨立的 Streams 以消除其他主題長阻塞帶來的影響，比如接收端長阻塞或流量控制，亦可以實現(xiàn)優(yōu)先級主題功能。
- 不同 QoS 的流：比如在「流量控制」中，QoS 0 傳輸應該讓位給高 QoS 傳輸。
- 將控制消息分成不同的流：MQTT 控制消息可以單向或雙向發(fā)送。如客?端可以通過「控制流」異步發(fā)送 UNSUBSCRIBE 請求，以要求服務器端停?發(fā)送不再感興趣的數(shù)據(jù)。
- 更細粒度的收發(fā)端協(xié)同流量控制：面對每一個流進行流控且對整個連接進行流控，實現(xiàn)更細粒度的流量控制。
我們在實驗室環(huán)境下，基于 EMQX 5.0 版本對不同的場景下 QUIC 與 TCP/TLS 的性能表現(xiàn)進行了模擬測試。測試在不同網(wǎng)絡時延下握手、建立連接、完成訂閱的時延。相較于 TLS，在網(wǎng)絡時延較高時 QUIC 有一定的優(yōu)勢。測試斷開連接后，重新發(fā)起連接并恢復重連所需的時延。由于 QUIC 在 0 RTT 場景下可以在第一個包上帶上應用層的數(shù)據(jù)包， 應用層相較于 TCP 一個來回握手響應更快。QUIC 協(xié)議支持0 RTT 握手，當客戶端和服務端完成初次握手后，服務端可向客戶端發(fā)送 NST 包?？蛻舳嗽谶B接斷開后可用 NST 跳過 1 RTT 中的很多步驟快速重建連接。0 RTT 的好處是可有效降低客戶端和服務端握手開銷和提高性能（握手延遲），EMQX 默認給客戶端發(fā)送 NST 包， 有效時性為 2 小時。0 RTT 也支持 early data，相比于 1 RTT 需要握手完成后才可進行應用層傳輸，0 RTT 的 early data 可以在第一個包上帶上應用層數(shù)據(jù)，用于快速恢復或重啟應用層業(yè)務。但由于 0 RTT 的 early data 不能防范重放攻擊， 因此 QUIC 建議不要在 0 RTT 上攜帶會改變應用狀態(tài)的數(shù)據(jù)。* 注：EMQX 默認不支持 early data，此測試只用于對比驗證。測試結果表明如果 MQTT 層協(xié)議設計得當，在完成首次握手后，QUIC 表現(xiàn)優(yōu)于純 TCP。
測試新連接與斷線重新連接不同過程中服務器 CPU 和內(nèi)存的占用情況，以對比 TLS，QUIC 1 RTT 和 0 RTT 握手時資源開銷。測試結果表明 QUIC 的 CPU 和內(nèi)存使用均優(yōu)于 TLS，但是重建連接耗費帶寬比 TLS 多。
* 注 1：主要為 MQTT 清除會話，踢開舊連接的額外開銷 注 2：主要為傳輸路徑 MTU 驗證導致的大量 QUIC 初始化握手數(shù)據(jù)包
此測試模擬大規(guī)?？蛻舳说刂愤w移時業(yè)務層消息傳輸?shù)淖兓?/span>傳統(tǒng) TCP/TLS 客戶端必須在應用層感知到斷線才進行重連，此過程響應非常慢并伴有許多不必要的重傳。QUIC 的處理更加平順，在傳輸層做到了保持連接不要求重連且讓應用層無感（如果有需要應用層也可以訂閱地址的變化）。QUIC 在客戶端源 IP 地址/端口變化情況下，消息發(fā)送無任何影響。而 TLS 連接在變化后出現(xiàn)消息發(fā)送中斷現(xiàn)象，即使客戶端可以通過重連機制重新連接到 EMQX 上，但中間時間窗口將無法進行任何操作。這一結果表明 QUIC 非常適合用在網(wǎng)絡經(jīng)常需要切換的環(huán)境。
測試在弱網(wǎng)條件下數(shù)據(jù)傳輸情況。我們分別做了 3 次測試：EMQX terminated TCP/TLS，QUIC 以及 nginx terminated TCP/TLS。測試場景：EMQX 以 20K/s 的速率發(fā)布 QoS 1 消息，在此過程中注入網(wǎng)絡錯誤：20% 亂序（發(fā)送端與接受端包的順序不一致），10% 丟包，QUIC 測試中還額外增加每 30 秒一次的網(wǎng)絡切換干擾。在此情況下 QUIC 服務端接收的數(shù)據(jù)稍微有所抖動，但不丟失消息；而 TLS 出現(xiàn)因網(wǎng)絡環(huán)境差而導致的擁塞、丟包。此項結果表明 QUIC 在弱網(wǎng)環(huán)境下可以提供可靠的傳輸。
* 注：黃圈標記中我們?nèi)コ司W(wǎng)絡錯誤，可以看到 TLS 的收發(fā)恢復正常收發(fā)，包數(shù)量一致沒有堆積，而 QUIC 只是從輕微抖動變得更平滑。更便捷的使用：MQTT over QUIC SDK NanoSDK 0.6.0 （https://github.com/nanomq/NanoSDK/）基于 MsQuic 項目率先實現(xiàn)了第一個 C 語言的 MQTT over QUIC SDK。NanoSDK 通過為 NNG 的傳輸層增加 QUIC 支持，使 MQTT、nanomsg 等協(xié)議能夠從 TCP 轉為 UDP，從而提供更好的物聯(lián)網(wǎng)連接體驗。其內(nèi)部將 QUIC Stream 和 MQTT 連接映射綁定，并內(nèi)置實現(xiàn)了 0 RTT 快速握手重連功能。* 消息示例代碼請參考 NanoSDK QUIC Demo: https://github.com/nanomq/NanoSDK/blob/main/demo/quic/client.c我們近期也將基于 NanoSDK 進行封裝并陸續(xù)推出 Python、Go 等語言的 SDK，方便更多用戶盡快體驗到 MQTT over QUIC 的優(yōu)勢能力。同時，相關的 SDK 將支持 QUIC fallback，當 QUIC 不可用時，連接層將自動切換為 TCP/TLS 1.2，確保各類網(wǎng)絡環(huán)境下業(yè)務都能正常運行。
NanoSDK 與 EMQX 之間通過 QUIC 進行消息收發(fā)
結合 QUIC 特性和物聯(lián)網(wǎng)場景，我們?yōu)?MQTT over QUIC 規(guī)劃了諸多特性，如通過區(qū)分控制通道實現(xiàn)主題優(yōu)先級設置，實現(xiàn)非可靠實時流傳輸以應對高頻數(shù)據(jù)傳輸場景，以及靈活的主題和數(shù)據(jù)通道（Stream）映射以降低主題之間的干擾。未來的版本中將陸續(xù)呈現(xiàn)。EMQ 也正在積極推進 MQTT over QUIC 的標準化落地。繼 2018 年成為 OASIS MQTT 技術委員會中目前為止唯一擁有投票權的中國公司并參與 5.0 協(xié)議標準制定后，EMQ 目前也已提交了 MQTT over QUIC 的相關草案。相信在不久的將來，MQTT 的底層協(xié)議將同時支持 TCP 與 QUIC，使整個物聯(lián)網(wǎng)行業(yè)從中獲益。可以看到，QUIC 非常適用于傳統(tǒng) TCP/IP 網(wǎng)絡 UDP MTU 大小能夠保證的弱網(wǎng)環(huán)境或者網(wǎng)絡經(jīng)常切換的環(huán)境。對于設備時刻處在移動中的物聯(lián)網(wǎng)場景（如車聯(lián)網(wǎng)、移動采集等），或是需要頻繁斷連不適合做長連接的場景（如設備需要定期休眠）來說，QUIC 都擁有巨大的潛力，是更為適合的底層協(xié)議選擇，這也是 EMQX 5.0 引入 QUIC 支持的原因。MQTT over QUIC 在 EMQX 5.0 中的率先實現(xiàn)，讓 EMQ 再次走在全球物聯(lián)網(wǎng)消息服務器領域的前沿。EMQ 將始終堅持以不斷的技術革新驅(qū)動產(chǎn)品持續(xù)的迭代升級，期待通過領先的產(chǎn)品為物聯(lián)網(wǎng)領域帶來基礎設施保障和業(yè)務創(chuàng)新動力。 |
