一、概要

MQTT（Message Queuing Telemetry Transport、メッセージキューイングテレメトリ転送プロトコル）は、発行/購読（publish/subscribe）モデルに基づく「軽量級」通信プロトコルであり、TCP/IPプロトコルの上に構築され、1999年にIBMによって公開されました。MQTTの最大の利点は、非常に少ないコードと限られた帯域幅で、リモートデバイスにリアルタイムで信頼性の高いメッセージサービスを提供できることです。低オーバーヘッド、低帯域幅消費のインスタントメッセージングプロトコルとして、IoT、小型デバイス、モバイルアプリケーションなどで広く応用されています。

MQTTは、クライアントとサーバーに基づくメッセージ発行/購読転送プロトコルです。MQTTプロトコルは軽量で、シンプルで、オープンで、実装が容易であり、これらの特徴により適用範囲が非常に広くなっています。多くの場合、制約のある環境、例えばマシンツーマシン（M2M）通信やモノのインターネット（IoT）を含みます。衛星リンクを介して通信するセンサー、時々ダイヤルアップする医療機器、スマートホーム、および一部の小型化されたデバイスで広く使用されています。

二、設計規範

IoTの環境は非常に特殊であるため、MQTTは以下の設計原則に従っています：

  • （1）簡潔であること。あってもなくてもよい機能を追加しない。
  • （2）発行/購読（Pub/Sub）モデルにより、センサー間でのメッセージ転送が容易になる。
  • （3）ユーザーがトピックを動的に作成できるようにし、運用コストをゼロにする。
  • （4）転送量を最小限に抑え、伝送効率を高める。
  • （5）低帯域幅、高遅延、不安定なネットワークなどの要因を考慮する。
  • （6）継続的なセッション制御をサポートする。
  • （7）クライアントの計算能力が非常に低い可能性があることを理解する。
  • （8）サービス品質管理を提供する。
  • （9）データは未知であると想定し、転送データの型と形式を強制せず、柔軟性を保つ。

三、主な特徴

MQTTプロトコルは、低帯域幅で信頼性の低いネットワークにおけるリモートセンサーおよび制御デバイス通信用に設計されたプロトコルであり、以下の主な特性があります。

  • （1）発行/購読メッセージモデルを使用し、1対多のメッセージ発行を提供して、アプリケーション間の結合を排除します。

    これはXMPPに非常に似ていますが、MQTTの情報冗長性はXMPPよりはるかに小さくなっています。なぜなら、XMPPはXML形式のテキストを使用してデータを転送するからです。

  • （2）ペイロードの内容に依存しないメッセージ転送。

  • （3）TCP/IPを使用してネットワーク接続を提供する。

    主流のMQTTはTCP接続に基づいてデータをプッシュしますが、UDPベースのバージョンもあり、MQTT-SNと呼ばれます。この2つのバージョンは異なる接続方式に基づいているため、長所と短所も当然それぞれ異なります。

  • （4）メッセージ発行のサービス品質には3つのレベルがあります：

    「最大1回」は、メッセージ公開が完全に基盤のTCP/IPネットワークに依存します。メッセージの喪失や重複が発生する可能性があります。このレベルは、環境センサーデータのように、1回の読み取り記録を失っても問題ない場合に使用できます。すぐに2回目の送信があるからです。この方式は主に通常のAPPのプッシュに使用されます。スマートデバイスがメッセージプッシュ時にネットワークに接続されていない場合、プッシュが届かず、再びネットワークに接続しても受信できません。

    「少なくとも1回」は、メッセージの到達を保証しますが、メッセージの重複が発生する可能性があります。

    「ちょうど1回」は、メッセージが1回届くことを保証します。厳格な要件を持つ一部の課金システムでは、このレベルを使用できます。課金システムでは、メッセージの重複や喪失は不正な結果を引き起こします。この最高品質のメッセージ公開サービスは、インスタントメッセージングAPPのプッシュにも使用でき、ユーザーが確実に受信し、かつ1回だけ受信することを保証します。

  • （5）小型の転送で、オーバーヘッドが非常に小さく（固定長のヘッダーは2バイト）、プロトコル交換を最小限に抑え、ネットワークトラフィックを削減します。

    これが、紹介の中で「IoT分野におけるセンサーとサーバーの通信、情報の収集」に非常に適していると言われる理由です。組み込み機器の計算能力と帯域幅は比較的弱いため、このプロトコルを使用してメッセージを転送するのが最適です。

  • （6）Last WillとTestamentの特性を使用して、関係者にクライアントの異常中断を通知するメカニズム。

    Last Will：すなわち遺言メカニズムであり、同じトピックの下にある他のデバイスに、遺言を送信したデバイスが接続を切断したことを通知するために使用されます。

    Testament：遺言メカニズムであり、機能はLast Willに似ています。

四、MQTTプロトコルの原理

4.1 MQTTプロトコルの実装方式

MQTTプロトコルの実装には、クライアントとサーバー側の通信が必要です。通信プロセスでは、MQTTプロトコルには3つの役割があります：パブリッシャー（Publish）、ブローカー（Broker）（サーバー）、サブスクライバー（Subscribe）です。このうち、メッセージのパブリッシャーとサブスクライバーはどちらもクライアントであり、メッセージブローカーはサーバーです。メッセージパブリッシャーは同時にサブスクライバーになることもできます。

MQTTで転送されるメッセージは、トピック（Topic）とペイロード（payload）の2つの部分に分けられます：

  • （1）Topicは、メッセージのタイプと理解できます。サブスクライバーが購読（Subscribe）すると、そのトピックのメッセージ内容（payload）を受信します。
  • （2）payloadは、メッセージの内容と理解でき、サブスクライバーが具体的に使用する内容を指します。

4.2 ネットワーク転送とアプリケーションメッセージ

MQTTは基盤となるネットワーク転送を構築します。クライアントからサーバーへの接続を確立し、両者の間に順序付けられた、損失のない、バイトストリームベースの双方向転送を提供します。

アプリケーションデータがMQTTネットワークを介して送信されるとき、MQTTはそれに関連するサービス品質（QoS）とトピック名（Topic）を関連付けます。

4.3 MQTTクライアント

MQTTプロトコルを使用するアプリケーションまたはデバイスは、常にサーバーへのネットワーク接続を確立します。クライアントは次のことができます：

  • （1）他のクライアントが購読する可能性のある情報を公開する。
  • （2）他のクライアントが公開したメッセージを購読する。
  • （3）購読を解除する、またはアプリケーションのメッセージを削除する。
  • （4）サーバーとの接続を切断する。

4.4 MQTTサーバー

MQTTサーバーは「メッセージブローカー」（Broker）とも呼ばれ、アプリケーションまたはデバイスであり得ます。メッセージのパブリッシャーとサブスクライバーの間に位置し、次のことができます：

  • （1）クライアントからのネットワーク接続を受け入れる。
  • （2）クライアントが公開したアプリケーション情報を受け入れる。
  • （3）クライアントからの購読および購読解除リクエストを処理する。
  • （4）購読しているクライアントにアプリケーションメッセージを転送する。

4.5 MQTTプロトコルにおけるサブスクリプション、トピック、セッション

一、サブスクリプション（Subscription）

サブスクリプションには、トピックフィルター（Topic Filter）と最大サービス品質（QoS）が含まれます。サブスクリプションはセッション（Session）に関連付けられます。1つのセッションには複数のサブスクリプションを含めることができます。各セッション内の各サブスクリプションには、異なるトピックフィルターがあります。

二、セッション（Session）

各クライアントがサーバーとの接続を確立すると、それが1つのセッションとなり、クライアントとサーバーの間で状態がやり取りされます。セッションは1つのネットワーク内に存在し、クライアントとサーバーの間で複数の連続したネットワーク接続にまたがることもあります。

三、トピック名（Topic Name）

アプリケーションメッセージに接続されたラベルであり、このラベルはサーバーのサブスクリプションと一致します。サーバーは、ラベルが一致するサブスクリプションを持つ各クライアントにメッセージを送信します。

四、トピックフィルター（Topic Filter）

トピック名のワイルドカードフィルターであり、サブスクリプション式で使用され、サブスクリプションが一致する複数のトピックを表します。

五、ペイロード（Payload）

メッセージのサブスクライバーが具体的に受信する内容。

4.6 MQTTプロトコルにおけるメソッド

MQTTプロトコルでは、特定のリソースに対して操作を実行するためのメソッド（アクションとも呼ばれます）がいくつか定義されています。このリソースは、事前に存在するデータまたは動的に生成されるデータを表すことができ、サーバーの実装によって異なります。通常、リソースとはサーバー上のファイルまたは出力を指します。主なメソッドは次のとおりです：

  • （1）Connect。サーバーとの接続確立を待ちます。
  • （2）Disconnect。MQTTクライアントが行った作業を完了するのを待ち、サーバーとのTCP/IPセッションを切断します。
  • （3）Subscribe。サブスクリプションの完了を待ちます。
  • （4）UnSubscribe。サーバーがクライアントの1つ以上のトピックのサブスクリプションを解除するのを待ちます。
  • （5）Publish。MQTTクライアントがメッセージリクエストを送信し、送信完了後にアプリケーションスレッドに戻ります。

五、MQTTプロトコルのデータパケット構造

MQTTプロトコルにおいて、MQTTパケットは固定ヘッダ（Fixed header）、可変ヘッダ（Variable header）、メッセージ本体（payload）の3つの部分から構成されます。MQTTパケット構造は以下の通りです。

  • （1）固定ヘッダ（Fixed header）。すべてのMQTTパケットに存在し、パケットタイプおよびパケットのグループクラス識別子を示します。
  • （2）可変ヘッダ（Variable header）。一部のMQTTパケットに存在し、パケットタイプによって可変ヘッダの有無とその具体的な内容が決まります。
  • （3）メッセージ本体（Payload）。一部のMQTTパケットに存在し、クライアントが受信した具体的な内容を示します。

5.1 MQTT固定ヘッダー

固定ヘッダはすべてのMQTTパケットに存在し、その構造は以下の通りです。

5.1.1 MQTTパケットタイプ

位置：Byte 1のビット7〜4。

4ビットの符号なし値に相当し、タイプ、値および説明は以下の通りです。

5.1.2 フラグ

位置：Byte 1のビット3〜0。

フラグを使用しないメッセージタイプでは、フラグは予約ビットとして扱われます。無効なフラグを受信した場合、受信側はネットワーク接続を閉じなければなりません。

（1）DUP：公開メッセージの複製。メッセージの信頼性のある伝送を保証するために使用されます。1に設定された場合、次の可変ヘッダにMessageIdが追加され、メッセージ伝送の完了を保証するために確認応答が必要ですが、メッセージの重複送信を検出するためには使用できません。

（2）QoS：公開メッセージのサービス品質、すなわちメッセージ配信が保証される回数。

Ø00：最多一次，即：<=1

Ø01：至少一次，即：>=1

Ø10：一次，即：=1

Ø11：预留

（3）RETAIN：公開保持フラグ。サーバーが今回のプッシュ情報を保持することを示します。新しい購読者が現れた場合、このメッセージをその購読者にプッシュします。設定されていない場合は、現在の購読者にプッシュした後に解放します。

5.1.3 残り長さ（Remaining Length）

アドレス：Byte 2。

固定ヘッダの2バイト目は、可変ヘッダとメッセージ本体の合計サイズを保存するために使用されますが、直接保存されるわけではありません。このバイトは拡張可能であり、その保存メカニズムは、先頭の7ビットが長さの保存に使用され、残りの部分がフラグとして使用されます。最後のビットが1の場合、長さが不足していることを示し、2バイトを使用して保存を続ける必要があります。例：計算された後続のサイズが0。

5.2 MQTT可変ヘッダー

MQTTパケットには可変ヘッダが含まれ、固定ヘッダとペイロードの間に位置します。可変ヘッダの内容はパケットタイプによって異なり、一般的な用途はパケットの識別子としてです。

多くのタイプのデータパケットには2バイトのパケット識別子フィールドが含まれます。これらのタイプのパケットには、PUBLISH (QoS > 0)、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACKがあります。

5.3 Payloadメッセージ本体

Payloadメッセージ本体はMQTTパケットの3番目の部分であり、CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBEの4種類のメッセージを含みます。

  • （1）CONNECT：メッセージ本体の内容は主に、クライアントのClientID、購読するTopic、Message、およびユーザー名とパスワードです。
  • （2）SUBSCRIBE：メッセージ本体の内容は、購読する一連のトピックとQoSです。
  • （3）SUBACK：メッセージ本体の内容は、SUBSCRIBEで要求されたトピックとQoSに対するサーバーの確認と応答です。
  • （4）UNSUBSCRIBE：メッセージ本体の内容は、購読解除するトピックです。

もっと見る

原文リンク：https://blog.csdn.net/qq_28877125/article/details/78325003