MQTT over QUIC

MQTTは、双方向で信頼性が高く順序が保証され、損失のないバイトストリームを提供するTCPプロトコルの上で動作するよう設計されています。しかし、モノのインターネット（IoV: Internet of Vehicles）の分野では、リアルタイムかつ効率的なメッセージ伝送の需要が高まっており、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と比較して、QUICは接続のオーバーヘッドとメッセージのレイテンシを大幅に削減し、全体的なスループットとモバイル接続の安定性を大幅に向上させます。そのため、複雑なネットワーク環境における通信課題の解決にも適しています。

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標準化も期待されています。

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