# 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](./features-mqtt-over-quic.md)では、QUICストリーム上でのクライアントとEMQX間の2つの相互作用モードと、それぞれの特徴・利点を紹介しています。[Use MQTT over QUIC](./getting-started.md)では、クライアント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](./features-mqtt-over-quic.md)をご覧ください。 ## 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](./getting-started.md)をご覧ください。 なお、EMQXはまだQUICが提供するすべての機能、例えばブローカー側のストリーム優先制御、ブローカー側のフロー制御、信頼性のないデータグラムなどを活用していません。これらの機能は今後のリリースで対応し、OASIS標準化も期待されています。 また、[制限事項](#制限事項)で述べたように、メッセージ状態の保持や再接続なしでのサブスクリプション再開方法についてもさらなる検討が必要です。