MQTT over QUIC：次世代のIoT標準プロトコル
EMQX Team
目次
EMQX 5.0では、MQTTメッセージをQUICプロトコル上で中継することにより、最新バージョン5.0での大幅な進歩を遂げました。
QUIC（RFC 9000）は、現代のモバイルインターネットに接続性を提供する次世代インターネットプロトコルHTTP/3の基礎トランスポートプロトコルであり、TCP/TLSプロトコルと比較して、接続オーバーヘッドとメッセージレイテンシが少なくなります。
IoTメッセージングシナリオに非常に適しているQUICの利点を基に、EMQX 5.0ではQUICサポート（MQTT over QUIC）を導入し、ユニークなメッセージングメカニズムと管理アプローチを設計しています。 この記事では、IoTシナリオのためのリーディングテクノロジー実装であるMQTT over QUICの利点と価値を詳しく説明し、読者はこの記事を通じてEMQX 5.0のQUICサポートを活用し、さまざまなMQTTアプリケーションシナリオでIoTデータ転送を効率的、安定、低コストにすることができます。
QUICとは何ですか？
QUICは、GoogleがTCP+TLSの代替として提案した、UDPの上に構築された一般的なトランスポート層ネットワークプロトコルです。エンドツーエンドのユーザーエクスペリエンスを改善するために開発されました。
QUICは、既存のTCP上のTLS実装よりも多くの利点があります。1つのラウンドトリップまたはゼロラウンドトリップで接続ハンドシェイクの高性能低レイテンシー。QUICは、接続設定中のオーバーヘッドを削減します。ほとんどのネットワーク接続がTLSを要求するため、QUICは最初のハンドシェイクプロセスでTLSキーを交換します。クライアントが接続を開くと、応答にはさらなる暗号化に必要なデータが含まれています。これにより、TCP接続を設定してからTLSでセキュリティプロトコルを交渉する必要がなくなります。そして、最も重要なことは、接続設定中のラウンドトリップを削減し、全体的な接続設定レイテンシーを低減することです。
QUICはUDPではなくTCP上で実行されます。QUICストリームは、個別にフロー制御され、データの再送信はUDPではなくQUICレベルで行われます。これは、1つのストリームでエラーが発生した場合でも、同じ接続内の他のストリームに影響を与えないことを意味します。QUICレイヤー上のアプリケーションでは、単一のマルチプレックスストリームのエラーによってデータ処理がブロックされることはなく、並列処理と全体的なパフォーマンスが改善されます。
エンドツーエンドの暗号化、TLS 1.3を介したハンドシェイク認証可能。
マルチプレックス接続。1つの接続で複数のストリームを並列化することを許可します。
改善された輻輳制御、プラグ可能な輻輳制御ポリシー。QUIC上のアプリケーションは、自己のフロー制御を行うことができ、過負荷状況を管理するために輻輳制御にも関与できます。これにより、アプリケーションは、優先トラフィック、レート制限、オーバーロード状況の管理に非常に柔軟に対応できます。
スムーズな接続移行のためのマルチパスサポート。QUICは、サーバー側とクライアント側の両方で接続の移行をサポートしているため、クライアントがWiFiアクセスネットワークからセルラーネットワーク（4G、5G）に移動するなど、下位層ネットワークが切り替わっても接続を維持できます。
既存のネットワークを後付けやアップグレードなしでサポートできます。QUICは、次世代インターネットプロトコルHTTP/3の基礎となるトランスポートプロトコルになっています。
HTTP/3プロトコルの紹介
2018年10月、IETFのHTTPおよびQUICワーキンググループは、HTTPマッピングをQUIC上で行うことをHTTP/3と命名し、グローバルな標準化を加速することを決定しました。2022年6月6日、IETFはRFC [9114]でHTTP/3を標準化しました。
HTTP/3の目的は、HTTP/2の輸送関連の問題を解決することにより、すべての種類のデバイスで高速で信頼性の高いWeb接続を提供することです。HTTP/3は、HTTP/2バージョンと同様のセマンティクスを使用し、同じリクエストメソッド、ステータスコード、およびメッセージフィールドを含みます。根本的な違いは、HTTP/2がTCP/TLSを基礎プロトコルとして使用するのに対し、HTTP/3がQUICを使用することです。
W3Techsによると、少なくとも40％のインターネットトラフィックがQUICを介して行われており、トップ10万サイトのうち25％がHTTP/3プロトコルをサポートしています。Google、Youtube、Facebookなどのトップストリーミングサイトも含まれます。
MQTT通信シナリオにおけるQUICの展望
MQTTは、コンパクトなメッセージ構造を持つ接続ベースのIoT通信プロトコルであり、厳しい制約を持つハードウェアデバイスや低帯域幅、高遅延ネットワーク上で安定した伝送を可能にします。キープアライブメカニズム、ウィルメッセージ、QoSなどの多くの機能が、さまざまなIoTシナリオに対応できます。
しかし、MQTTプロトコルには、基礎となるTCP輸送プロトコルの制限による、特定の複雑なネットワーク環境での固有の欠点があります。
ネットワーク切り替えによる頻繁な接続中断 切断後の接続再確立が困難
オペレーティングシステムは切断後にリソースを解放するのが遅く、アプリケーション層は切断状態を適時に感知できず、再接続時のServer/Clientオーバーヘッドが高い
弱いスポットネットワーク環境では、輻輳、パケットロス、再送信によってデータ伝送がブロックされる
例えば、接続された車両ユーザーは通常、山岳地帯、鉱山、トンネルなどで走行するため、信号のないゾーンに入ったり、受動的に基地局を切り替えたりすると接続が中断することがあります(スポットネットワークとも呼ばれます)。頻繁な接続中断や遅い接続確立は、ユーザー体験の悪化につながる可能性があります。L4ドライバーレス車両などのリアルタイムデータ伝送と安定性に高い要件があるサービスでは、この問題を緩和するために顧客に多大なコストがかかる可能性があります。
これらのシナリオでは、QUICの低接続オーバーヘッドとマルチパスサポートがその強みを発揮します。より深い探求の結果、MQTT over QUICがこのジレンマの素晴らしい解決策であると考えています-QUICの0 RTT/1 RTTの再接続/新機能と移行サポートに基づいて、弱いネットワークと不規則なネットワークパスでのユーザー体験を効果的に改善できます。
EMQX 5.0によるMQTT over QUICの実装
現在のEMQXの実装は、トランスポート層をQUICストリームに置き換え、クライアントが接続を開始し、双方向ストリームを作成するところから始まります。EMQXとクライアントは、それを介して相互作用します。
複雑なネットワーク環境を考慮すると、クライアントがQUIC接続ハンドシェイクを完了できない場合は、何らかの理由で、クライアントが自動的に従来のTCP接続にフォールバックすることをお勧めします。
MQTTプロトコルは、以下のように、QUICをそのトランスポートに使用することで利益を得ることができます。
- ネットワークスイッチ、NATの再バインド後も接続を維持します。
- 高速な接続確立により、ハンドシェイクの遅延を減らします。
- 頻繁な接続/再接続の緩和 クイックな接続回復
- より高度な輻輳制御：テストでは、パケットロスを効果的に減少させ、ネットワークの変動にもかかわらず連続的で安定したデータ伝送を可能にします。
- 運用、メンテナンスにやさしい：大量の再接続によって引き起こされるオーバーヘッド(時間オーバーヘッド、クライアント/サーバーパフォーマンスオーバーヘッド)を減らし、不必要なアプリケーション層状態移行によって引き起こされるシステムの過負荷を減らします(0 RTT)
- より柔軟なアーキテクチャイノベーション：例えば、直接サーバーリターン(DSR, 直接サーバーリターンモード)など、イネス/リクエストトラフィックのみがLBを通過し、イーグレス/レスポンストラフィックがLBをバイパスしてクライアントに直接戻ることで、Lのボトルネックを減らすことができます。
- スムーズな接続移行のマルチパスサポート：4GからWIFIへのハンドオーバー、またはNAT再バインドによるクインテットの変更の場合、QUICは新しいクインテットで接続を維持することができます。特に、モバイルデバイスではネットワークが頻繁に変更されるためです。
- よりアジャイルな開発と展開：QUICプロトコルスタックをユーザースペースで実装することをお勧めし、迅速なイテレーション、QUICバグフィックスの展開、PoCからプロダクションへのリードタイムを短縮することができます。
- エンドツーエンドの暗号化：QUICパケットは、通信をセキュアで中間ボックスによって傍受されないように、ヘッダーに最小限の情報を残します。
また、探求する機会があります：
- 異なるトピックを持つストリーム：同じ接続内で並列ストリームを使用して、異なるトピックを運ぶことができます。これにより、送信/受信プロセスを異なる優先順位で並列化し、HOL (Head Of Line)ブロッキング問題を緩和することができます。
- 異なるQoSを持つストリーム：例えば、「フロー制御」では、QoS 0メッセージは高QoSメッセージに優先する必要があります。
- 異なるストリームに制御メッセージを分割する：MQTT制御メッセージは、片方向または双方向に送信できます。例えば、クライアントは、サーバーに対して不要になったデータを送信しないように要求するために、短時間の片方向ストリームを介して非同期でUNSUBSCRIBEリクエストを送信することができます。
- より細かい粒度の送信および受信の共同フロー制御：フロー制御は、各フローまたは接続全体で実行され、より細かいグレインのフロー制御を可能にします。
QUIC vs TCP/TLS
EMQX v5.0を基に、QUICとTCP/TLSのパフォーマンスを、異なるシナリオで実験室環境でシミュレーションしました。
テスト環境
- テストプラットフォーム：単一ノードを持つEMQX 5.0
- サーバー仕様：AWS EC2 M4.2xlarge(8コア32GB)
- オペレーティングシステム：Ubuntu 20.04
- クライアント数：5000
- ロードジェンの並列数：8 レイテンシー測定：P95 (パーセンタイル)
クライアント接続のレイテンシー
これは、異なるネットワークレイテンシー（pingラウンドトリップ）でのハンドシェイク性能、MQTT接続設定確立、およびサブスクリプション完了を比較するためのものです。
ラウンドトリップタイムが1msの場合、QUICとTLSではレイテンシー性能に大きな違いは見られません。
レイテンシーが増加するにつれて、ラウンドトリップタイムが30msの場合、QUICはTLSを大幅に上回ります。
MQTT over QUICは、レイテンシーが高いネットワークに適していると結論付けることができます。
0 RTT再接続レイテンシー
これは、接続を再開し、切断後に再接続するために必要なレイテンシーをテストするためのものです。
1-RTTシナリオの後、EMQXはクライアントにNST（新しいセッションチケット）を送信して再入力させます。クライアントはこのセッションチケットを使用して最初のパケットを暗号化してサーバーに接続を再確立することができます。これを0-RTTシナリオと呼びます。QUICは、0 RTTシナリオで最初のパケットにアプリケーション層パケットを運ぶこともできます。
TCP / TLSでは、ハンドシェイクを完了してからアプリケーションデータの交換を開始するために少なくとも2つのラウンドトリップが必要ですが、アプリケーション層ははるかに早くデータを交換できます。
0 RTTの利点は、ハンドシェイクのオーバーヘッドを実質的に削減し、クライアントとサーバーの両方のパフォーマンス（ハンドシェイクのレイテンシー）を改善することです。EMQXは、有効期間が2時間のデフォルトでNSTパケットをクライアントに送信します。
ただし、0 RTTの早期データは再生攻撃に対して保護されていないため、QUICはアプリケーションの状態を変更するデータを0 RTTで運ぶことを推奨していません。
EMQXは早期データをデフォルトでサポートしておらず、このテストは比較と検証にのみ使用されます。
テスト結果は、MQTTレイヤープロトコルが適切に設計されている場合、QUICが最初のハンドシェイク後に純粋なTCPを上回ることを示しています。
接続/再接続時のサーバーリソース使用量
このテストは、大量のクライアントが接続し、切断してから再接続するシナリオでのリソース使用量の比較です。結果は、CPUおよびメモリ使用量においてQUICがTLSを上回りますが、再接続時にはTLSよりも帯域幅を消費します。異なる実装により、ここではEMQXで2つの実装（TCP / TLSおよびQUIC）のパフォーマンスを比較します。
| テスト項目 | QUIC | TLS |
|---|---|---|
| CPU (first connection) | ~60% | ~80% |
| CPU (reconnect) | ~65% ¹ | ~75% |
| Maximum memory usage | 9 GB | 12 GB |
| Network bandwidth usage (Trans+Recv) | Peak value 100Mb ² | Peak value 30Mb |
注1：主にMQTTセッションのクリアや古い接続の切断による追加のオーバーヘッドを指します。
注2：輸送経路MTU検証によるQUIC初期ハンドシェイクパケットの大量発生を主に指します。
クライアントアドレスの移行
このテストは、大規模なクライアントアドレスの移行中にビジネスレイヤーメッセージングの変更をシミュレートします。
クライアントのソースアドレス（アドレスとポート）が変更されると、従来のTCP/TLSクライアントは、再接続する前にアプリケーションレイヤーで切断、ルーティングの失敗、またはパケットロスを検出する必要があります。このプロセスは、さまざまなタイマーがあり、多数の不必要な再送信、ロスリカバリなどが含まれるため、非常に遅く、TLS上のアプリケーションはブロッキング状態になり、アプリケーションデータの交換がブロックされます。
QUICの処理はスムーズで、アドレスが切り替わっても再接続を必要とせず、アプリケーションは認識しないままにします（ただし、必要に応じてアプリケーションレイヤーはアドレス変更にサブスクライブすることができます）。
この結果は、ネットワークが頻繁に切り替わる環境には、QUICが適していることを示しています。
ネットワークパケットロステスト
これは、弱いネットワーク条件でのデータ転送をテストするものです。我々は3つの別々のテストを行いました：EMQX終了TCP/TLS、QUIC、およびNgnix終了TCP/TLS。
テストシナリオ：EMQXは20K/sのQoS 1メッセージを発行し、プロセス中にネットワークエラーが注入されます：20％の順序不正（送信側と受信側のパケットの順序が一致しない）、10％のパケットロス。 QUICテストでは、30秒ごとに追加のネットワーク切り替えの干渉が追加されます。
この場合、QUICサーバに受信されたデータはわずかに不安定ですが、メッセージは失われません。一方、TLSは、ネットワーク環境が悪いため、混雑やパケットの損失が発生します。この結果は、QUICが弱い不安定なネットワーク環境で信頼性のある転送を提供できることを示しています。
ネットワークエラーを削除した場合、黄色い円でTLSの送受信が正常に戻り、パケット数がスタックせず一貫していることがわかります。一方、QUICはわずかに不安定からスムーズに変化しました。
使いやすく：MQTT over QUIC SDK
NanoSDK 0.6.0は、MsQuicプロジェクトに基づく最初のC言語MQTT over QUIC SDKをリリースしました。
NanoSDKは、NNGのトランスポート層にQUICサポートを追加することで、MQTTやnanomsgなどのプロトコルをTCPからUDPに移行することにより、より良いIoT接続体験を提供します。内部的には、QUICストリームをMQTT接続マッピングにバインドし、0 RTT高速ハンドシェイク再接続の内蔵関数を持っています。
将来的には、NanoSDKをベースにしたPython、Go、その他の言語のSDKもリリースし、より多くのユーザーがMQTT over QUICの利点を可能な限り早く体験できるようにします。
同時に、関連するSDKはQUICからTCPのフォールバックをサポートします。QUICが利用できない場合、接続層は自動的にTCP/TLS 1.2に切り替わり、すべての種類のネットワーク環境でサービスが正常に動作することを保証します。
将来のEMQX QUIC
QUICの機能をIoTシナリオと組み合わせることで、私たちはMQTT over QUICのために多くの機能を計画しています。これには、制御チャネルの区別によるトピックの優先順位付け、高頻度データ転送シナリオの非信頼性リアルタイムストリーミング、トピックおよびデータチャネル（ストリーム）マッピングの柔軟性によるトピック間の干渉の削減などが含まれます。これらは、コミュニティとお客様のフィードバックに応じて将来のリリースで発表される可能性があります。
EMQはまた、MQTT over QUICの標準化を積極的に推進しています。2018年にOASIS MQTT技術委員会で投票権を持つ唯一の中国企業となり、5.0プロトコル標準の開発に参加した後、MQTT over QUICに関する草案提案を準備しています。私たちは、近い将来、MQTTの基礎プロトコルがTCPとQUICの両方をサポートするようになり、IoT業界全体に利益をもたらすと信じています。
エピローグ
明らかに、QUICは従来のTCP/IPネットワークのUDP MTUサイズが保証されるか、ネットワークが頻繁に切り替わるような弱い、ロスの多い、スポット的なIoTネットワーク環境に非常に適しています。 QUICは、デバイスが常に移動している（自動車のインターネット、モバイルコレクションなど）場合や、デバイスが周期的にスリープする必要がある場合でも、長時間のMQTTセッションを維持することができます。
EMQX 5.0のMQTT over QUICは、世界で最初の実装であり、再びEMQがMQTTブローカーのグローバルトレンドをリードしています。 EMQは、製品の継続的なイテレーションアップグレードを推進するための技術革新を継続し、ビジネスイノベーションを推進する信頼性の高いインフラストラクチャを提供します。