MQTTガイド 2024

時にはサーバーを直接ブローカーと呼ぶこともあります。これら2つの用語は互換的に使用されます。

クライアントは接続時にこのフィールドを使用して、既存のセッションから通信を再開するか、完全に新しいセッションを作成するかを指定できます。これはMQTT v5.0でのみ適用されます。

MQTTプロトコルを使用してサーバーに接続し、サーバーを通じてパブリッシュおよびサブスクライブを行うデバイスまたはアプリケーションです。

クライアントIDはクライアントの接続とセッションを一意に識別するために使用されます。MQTTではクライアントが自身でクライアントIDを指定することも、サーバーがクライアントにクライアントIDを一様に割り当てることもサポートしています。

MQTTクライアントとMQTTブローカー間のネットワーク接続を意味します。MQTTクライアント間で直接接続されることはありません。

メッセージのコンテンツタイプを記述して、受信者がメッセージをより簡単に処理できるようにするために使用されます。text/plainなどのMIMEタイプや、メッセージコンテンツを記述するカスタム文字列を使用できます。 MQTT v5.0でのみ適用できます。

"MQTT v5.0は、パスワードベースおよびトークンベースの認証を拡張する高度な認証をサポートするために、AUTHパケットを導入しました。 ユーザー名とパスワードフィールドによって提供されます。

これは、様々なより安全な認証メカニズムを使用できる認証フレームワークのようなものです。 たとえば、SCRAM認証は、中間者攻撃に対抗するために、サーバーとクライアントの間のアイデンティティの相互確認をサポートしています。"

MQTT v5.0はフロー制御メカニズムを導入し、クライアントとサーバーが相手方の最大メッセージ送信レートを自身の受信能力に応じて合意することができます。これにより、一方が速すぎる送信によるネットワークの混雑や受信側の過負荷などの問題を回避できます。

Keep Aliveは、クライアントからのMQTT制御パケットの送信間隔の最大値を示します。他の制御パケットを送信できない場合、クライアントはPINGREQパケットを送信する必要があります。

通常はPUBLISHパケットを意味します。

MQTT v5.0を使用すると、クライアントはメッセージの有効期限を設定して、長期間サーバーに保存されたメッセージが購読者に転送されるのを回避できます。

「MQTT over...」は、MQTTが上位のどのプロトコルで動作しているかを意味します。一般的な例はMQTT over TCP、MQTT over TLSなどです。MQTTプロトコルは、順序付けられた信頼性のある双方向のバイトストリームを提供する基礎となるトランスポート層を必要とするだけで、特定のトランスポートプロトコルの使用を強制するものではありません。MQTT over QUICは、EMQXによるMQTTの拡張です。TCPと比較して、QUICは接続のオーバーヘッドを大幅に削減し、弱いネットワーク環境でのメッセージ遅延を効果的に削減することができます。また、マルチプレクシング、接続移行、エンドツーエンドの暗号化などの特性を持つことにより、現代のモバイルインターネットに対してより柔軟で信頼性のあるトランスポート層を提供します。

2014年10月にOASIS技術委員会によってリリースされたMQTT仕様です。

2019年3月にOASIS技術委員会によってリリースされた最新のMQTT仕様です。新機能を多数導入しながらも、MQTT v5.0はv3.1.1と後方互換性があります。

MQTT制御パケットを一般に意味します。MQTTプロトコルは、事前に定義されたMQTT制御パケットを交換することで通信を行います。

パケット識別子は、クライアントとサーバー間でQoSが0より大きいメッセージまたはサブスクライブ/アンサブスクライブリクエストを一意に識別するために使用されます。

MQTTパケットのペイロード部分は、パケットタイプによって異なります。

メッセージコンテンツ(ウィルメッセージを含む)がUTF-8でエンコードされた文字列であるかどうかを示すために使用されます。MQTT v5.0でのみ適用できます。

"クライアントは、接続中としていることをサーバーに通知するために、適時PINGREQパケットをサーバーに送信する必要があります。

サーバーも、クライアントがネットワークとサーバーのアクティビティステータスを判断できるように、適時PINGRESPパケットで応答する必要があります。"

MQTTは、ほとんどの制御パケットに一連のオプショナルなプロパティを定義しています。異なるタイプの制御パケットには異なるオプショナルなプロパティがあります。

パブリッシュ/サブスクライブメカニズムはMQTTプロトコルの核心です。これは、メッセージの送信者（パブリッシャー）と受信者（サブスクライバー）を分離し、中間エージェント（ブローカー）がメッセージのルーティングと配信を担います。

"MQTTは、異なるレベルのメッセージ信頼性保証を提供するために、3つのレベルのQoSを定義しています。 各メッセージは、発行時に独自のQoSを個別に設定できます。

QoS 0: 最高1回の配信、メッセージが失われる可能性があります。

QoS 1: 少なくとも1回の配信、メッセージの到着が保証されますが、複数回到着する可能性があります。

QoS 2: 完全に1回の配信、メッセージが到着および重複しないことが保証されます。"

MQTTはCONNACKなどの応答パケットのReason Codeフィールドを通じて操作の結果を示します。

Reason Codeは通常機械が読み取り可能ですが、MQTTはReason Stringも提供しており、Reason Codeに基づいて結果をさらに示すことができます。MQTT v5.0でのみ利用可能です。

サーバーとクライアントが同時に処理できるQoS 1およびQoS 2メッセージの最大数を宣言するために使用され、ピアはメッセージを送信する際にこの制限に従う必要があります。MQTT v5.0のみ適応できます。

"MQTTのパブリッシュ/サブスクライブメカニズムにより、発行者はメッセージがサーバーに到達したことしか保証できず、必ずしもサブスクライバーに届くとは限りません。 したがって、要求-応答メカニズムが必要です。

MQTT v5.0は、要求-応答のサポートが強化されています。 要求者は、要求で直接応答トピックを指定できるため、要求者とレスポンダーがトピックで事前に合意する必要はありません。 また、相関データによって、要求と応答の正しい照合を確認できます。"

保持メッセージは、ブローカーが新しいサブスクライバーに最新のメッセージを配信するために保持するメッセージです。

MQTTは複数のセキュリティメカニズムをサポートしており、例えばトランスポート層でのTLSを使用してエンドツーエンドの安全な接続を提供し、メッセージの盗聴、改ざん、偽造から保護します。また、MQTTプロトコルレベルでのクライアントとサーバーの認証をサポートし、クライアントに対する認可チェックを行い、特定のトピックにのみ認証されたユーザーがアクセスできるようにします。

パブリッシングクライアントとサブスクライビングクライアントの間で中継を行うデバイスまたはアプリケーションです。主な責務は、すべての受信メッセージを対応するサブスクライビングクライアントに転送することです。

MQTT v5.0を使用すると、サーバーはDISCONNECTパケットを送信して、接続が閉じられた特定の理由をクライアントに示すことができます。

MQTT v5.0を使用すると、サーバーはCONNACKまたはDISCONNECTパケットのServer Referenceプロパティを介して、クライアントに一時的または永続的に別のサーバーに切り替えるように指示できます。

MQTTのセッションメカニズムは、QoS 1および2のメッセージのプロトコルフローを実現することを保証します。セッションはクライアントとサーバー間の状態を保持する相互作用で、QoS 1および2のメッセージの送信状態やサブスクリプション情報などを保持します。

これはクライアント接続が切断された後、サーバー上でセッションがどのくらいの期間生存するかを表します。これはMQTT v5.0でのみ適用されます。

サーバーは、このフィールドを介してクライアントに現在の接続が以前のセッションの継続であるか、まったく新しいセッションであるかを通知します。そのため、クライアントは対応する調整を行うことができます。

"MQTT v5.0を使用すると、クライアントを複数のサブスクリプショングループに分割できます。メッセージはすべてのサブスクリプショングループに転送されますが、同じサブスクリプショングループ内のクライアントは、ランダム、ラウンドロビン、または他の戦略を使用してメッセージを受信することができます。

これにより、サブスクライバーは負荷分散された方法でメッセージを消費できます。

EMQXなどの一部のMQTTサーバーは、プロトコル外で非MQTT v5.0デバイスの共有サブスクリプションをサポートしています。"

"クライアントは、サブスクライブ時にサブスクリプション識別子を指定できます。また、サーバーは、これらのサブスクリプションに一致するメッセージを転送するときに、関連するサブスクリプション識別子を含める必要があります。

特定のユースケースでは、サブスクリプション識別子により、送信する必要があるデータ量を減らしたり、クライアントがメッセージのコールバックをトリガーするかどうかを判断したりできます。"

"MQTTを使用すると、クライアントはそれぞれのサブスクリプションごとに異なるサブスクリプションオプションを使用できます。たとえば、サブスクライブ時に保持メッセージを受信するかどうか、およびサーバーがそれらに送信できるメッセージの最大QoSレベルなどです。

MQTT v3.1.1では、最大QoSの設定のみがサポートされています。"

トピックは異なるメッセージを識別し区別するために使用されるもので、MQTTメッセージルーティングの基礎です。パブリッシャーは発行時にメッセージのトピックを指定し、サブスクライバーは関心のあるトピックを購読して関連するメッセージを受け取ります。

MQTT v5.0を使用すると、送信者はトピック名を2バイトの整数で表されるエイリアスにマップできます。その後、メッセージ送信中に帯域幅消費を減らすために、元のトピック名をエイリアスで置き換えることができます。

トピックフィルターはサブスクライブ時に使用され、トピックワイルドカードを含めて複数のトピックに同時にサブスクライブすることができます。

トピック名はメッセージの発行時に使用され、トピックワイルドカードの使用は許可されていません。

MQTTは2つのトピックワイルドカード、すなわち単一レベルのワイルドカード「+」とマルチレベルのワイルドカード「#」を提供します。ワイルドカードはトピックフィルターでのみ使用できます。

MQTTは、接続パケット内のオプションのユーザー名とパスワードフィールドを使用して、パスワード認証とトークンベースの認証をサポートします。

MQTT v5.0では、クライアントとサーバーがPINGREQとPINGRESP以外のすべての制御パケットにカスタムの無制限の文字列キーバリューペアをメタデータとして追加することができます。これにより、より良いスケーラビリティが提供されます。

これはクライアントが切断した後、サーバーが遺言メッセージを送信するまでの遅延時間を示します。これはMQTT v5.0でのみ適用されます。

クライアントがブローカーから予期せず切断された場合、サーバーは接続時にクライアントが設定した遺言メッセージを他のクライアントに転送します。

「$」で始まるトピックは、その使用方法とシナリオがサーバーによって決定され、クライアントはそれらのトピックを自己の目的で任意に使用することはできません。