MQTT over QUIC

MQTTは、双方向に信頼性が高く順序が保証されたロスレスのバイトストリームを提供するTCPプロトコルの上で動作するよう設計されています。しかし、モノのインターネット（IoV）の分野では、リアルタイムかつ効率的なメッセージ伝送の需要が高まっており、TCPの限界が顕在化しています。車両、センサー、インフラの相互接続が進む中で、TCP伝送のボトルネックを克服することは、安全でスマートかつ柔軟な交通エコシステムを構築するために不可欠です。

これに対応するため、EMQX 5.0ではQuick UDP Internet Connections（QUIC）プロトコル上のMQTTを導入しました。MQTTのすべてのプロトコル機能との互換性を保ちつつ、IoTクライアントがQUICを介してEMQXと接続・通信できるようにしています。これによりクライアント接続に大きな利点がもたらされます。QUICを使用するクライアントは、特に弱いネットワーク、頻繁に変化するリンク、不安定なネットワーク環境が多いモノのインターネット（IoV）などの一般的なシナリオにおいて、接続およびメッセージのスループット性能を向上させつつ、レイテンシを低減できます。

本章では、なぜMQTT over QUICがEMQXに実装されたのか、そしてどのように実装されているかを説明します。Features and Benefitsでは、QUICストリーム上でのクライアントとEMQX間の2つの相互作用モードと、それぞれの特徴および利点を紹介します。Use MQTT over QUICでは、クライアントSDKやツールを用いてEMQXでMQTT over QUICを有効にする方法を示します。

TIP

現時点では、MQTT over QUICはまだMQTTの標準プロトコルではありませんが、本番環境での展開が可能であり、EMQはOASIS内での標準化プロセスを積極的に推進しています。

QUICの紹介

QUICは、より高速な接続確立速度を提供する新しいトランスポートプロトコルです。もともとはGoogleによって開発され、従来のネットワーク通信の基盤であるTCPおよびTLSの特定の非効率性を克服し、クライアントからのより効率的で安全かつ低レイテンシなプロトコルへの需要に応えるために設計されました。その後、インターネット技術タスクフォース（IETF）によってグローバル標準として採用されました。

QUICは、データ送信速度の迅速な立ち上げを可能にするより効率的なアルゴリズムを用いて輻輳制御を改善しています。さらに、ストリームベースの多重化アーキテクチャを採用しており、データストリームを独立して送信できるため、ヘッドオブラインブロッキングを回避し、高いパケット損失や遅延のシナリオでの性能向上に寄与します。

次世代のインターネットトランスポートプロトコルとして、HTTP/3の基盤となるトランスポートプロトコルです。TCPと比較して、接続のオーバーヘッドやメッセージのレイテンシを大幅に削減し、全体的なスループットやモバイル接続の安定性を大きく向上させます。したがって、複雑なネットワーク環境における通信課題の解決にも適しています。

MQTT over TCPの適用シナリオ

MQTT over QUICは、リアルタイムかつ安定したデータ伝送に高い要求があるビジネスに特に適しています。例えば、山間部、鉱山、トンネル内を走行するコネクテッドカーでは、信号の死角に入ったり基地局を受動的に切り替えたりする際に接続が途切れることがあります。QUICの利点により、MQTT over QUICは以下のような従来のMQTT over TCPの欠点を克服できます。

• TCP/TLSの接続確立が遅い
  クライアントとサーバー間の初期ハンドシェイクには複数の往復が必要であり、往復時間（RTT）が接続確立速度に大きく影響します。RTTが長いとレイテンシが増加し、接続確立が遅くなります。
• 輻輳ウィンドウによるトラフィックの立ち上がりが遅い
• ヘッドオブラインブロッキング
  パケットが失われると、回復されるまで全体の伝送がブロックされます。これによりレイテンシが大幅に増加します。
• 上位層プロトコルの認識がない
  TCPはすべてのデータ伝送を同等に扱い、同じネットワーク接続を使用する異なる種類のデータやビジネスを区別しません。

弱く不安定なネットワーク環境でのユーザー体験を向上させるMQTT over QUICの特徴と利点の詳細は、Features and Benefitsをご覧ください。

QUICとTCP/TLSのテスト比較

TCP/TLSとの比較テストにおいて、MQTT over QUICの性能は以下のようにまとめられます。

• ネットワークレイテンシが高い場合、QUICは接続確立およびサブスクライブがより高速です。
• 切断後、0-RTTを用いることでTCP/TLSよりもはるかに速く接続を再確立できます。
• 大規模な接続・再接続時において、QUICはサーバーのCPUおよびメモリ使用率でTLSより優れています。
• NATリバインディング時、TCP/TLSではクライアントの再接続応答が非常に遅くメッセージ伝送が途切れますが、QUICはよりスムーズに処理し、メッセージ送信に影響を与えません。
• 弱いネットワークでのパケット損失やパケット伝送の乱れがある環境では、TLSはネットワーク環境の悪さによりメッセージの輻輳や損失が発生しますが、QUICサーバーは多少のジッターはあるもののメッセージ損失はありません。

制限事項

現時点でMQTT over QUICには以下の制限があります。

• セッション状態の保持はサポートされていません。つまり、クライアントが再接続する必要がある場合、以前にサブスクライブしていたトピックに対して再度サブスクライブする必要があります。
• いずれかのピアによってデータストリームが予期せず閉じられた場合、QoS 1およびQoS 2のメッセージ状態は保持されません。

今後の展望

現在、MQTT over QUICは本番環境対応が完了しており、ユーザーによる詳細なテストと良好なフィードバックが寄せられています。今すぐ体験したい方はGetting Startedをご覧ください。

ただし、EMQXはまだQUICが提供するすべての機能、例えばブローカー側のストリーム優先制御、ブローカー側のフロー制御、不確実なデータグラムなどを活用していません。これらの機能は今後のリリースで対応し、将来的にはOASIS標準になることを目指しています。

また、制限事項で述べたように、メッセージ状態の保持や再接続なしでのサブスクリプションの再開方法についてもさらなる検討が必要です。