MQTT (Message Queuing Telemetry Transport) は、人間の用語では、メッセージ キュー テレメトリ トランスポートを意味します。数年前、多くのエンジニアが PC 側で普及しているこの回りくどい用語を聞いたこともありませんでしたが、モノのインターネット (IoT) テクノロジーが徐々に発展するにつれて、このプロトコルは主要なエンジニアの目にますます頻繁に登場するようになりました。そのため、名前だけは知っていても意味が分からない技術者も多く、IoTの発展に伴って開発されたプロトコルの一種だと思っている人も少なくありませんでした。実際、MQTT プロトコルは 20 年以上前に初めて発明され、1999 年に IBM の Andy Stanford Clark と Cirrus Link の Alan Nippe がプロトコルの最初のバージョンを作成しました。その後、このプロトコルは ISO 標準 (ISO/IEC PRF 20922) に基づくパブリッシュ/サブスクライブ-ベースのメッセージング プロトコルとして国際標準化されました。IBM は 2013 年に MQTT バージョン 3.1 仕様を構造化情報標準化推進機構に提出し、その仕様に少数の変更のみを許可することを保証する憲章を添えて、それ以来 MQTT プロトコルは それ以来、多くのニッチな分野で使用されてきました。 IoT の技術インフラが完成すると、この古代のプロトコルが最初の春を迎え始めました。
ネットワークのトランスポート層とアプリケーション層
誰もが知っているように、モノのインターネットの急速な発展はこれまでのところ通信ネットワーク インフラストラクチャから離れることができず、室内照明のスイッチで世界のあらゆる場所を制御したり、産業用制御を行ったり、ロボットの動きを遠隔制御したりすることができるようになり、この技術の成熟度はネットワーク通信を基礎としています。現在のネットワーク技術の主要な技術は OSI 7 層モデルです。もちろん、実際のアプリケーションでは TCP/IP 4 層ネットワーク モデルが使用されています。-
TCP / IP- 3 番目のトランスポート層の 4 層ネットワーク モデルは有名な TCP / IP プロトコルです。このプロトコルの主な目的は、この層のプロトコルの主な目的は、コンピュータがネットワーク上の他のマシンの指定された IP アドレス、たとえば、IP アドレス「192.168.137.19」にデータ送信を送信するために使用されます。たとえば、IP アドレス「192.168.137.19」を持つマシンが IP アドレス「192.168.137.10」のマシンに 16 バイトのバイナリ パケットを送信すると、TCP/IP プロトコルを使用して送信できます。 TCP を使用してデータを転送する場合は、代わりにソケットを使用するのが一般的です。
しかし、「192.168.137.19」マシンの IP アドレスが「192.168.137.10」マシンにデータを送信する場合、データ内のこの TCP パケットのパケットは、実際には「192.168.137.10」マシンの受信側の IP アドレスの意味を表すものであり、このデータのパケットをどのように解析するかという問題は、その上のトランスポート層に委ねられます。 解決するプロトコルの層、つまりアプリケーション層プロトコルです。もちろん、プロトコルが通常のコンピューターのネットワークに解像度を与えたくない場合は、独自のアプリケーション層プロトコルを開発することもできます。それは問題ではありません。トランスポート層の目的は、その上でターゲット マシンにデータを渡すことだけです。
私たちの日常の仕事、娯楽では、Webページを開いたときにその位置に画像が表示され、下を向いたボタンがどのような機能を実現するかなど、さまざまなアプリケーション層のプロトコルに遭遇することがありますが、これはHTML HyperText Transfer Protocol（英語：HyperTextTransferProtocol、略称：HTTP）によって取り決められています。これにより、Web サイト内のページが任意のデバイスからリクエストされたときに、そのデバイスがページを適切に表示できるようになります。 HTTP 以外にも、DNS、FTP など、アプリケーション層のプロトコルは数多くありますが、今回の主役である MQTT プロトコルもその 1 つです。
IoT が MQTT を好む理由
既存のアプリケーションで利用できる優れたアプリケーション層プロトコルがすべて揃っているにもかかわらず、なぜ MQTT が IoT 分野で輝くのでしょうか。 MQTT プロトコルの選択には根拠がないわけではありません。 MQTT は、IoT 開発者にとって適切なバランスを取るよう努める軽量で柔軟なネットワーキング プロトコルです。
この軽量プロトコルは、厳しく制約されたデバイス ハードウェアや、待ち時間が長く帯域幅が制限されたネットワークでも実装できます。
その柔軟性により、IoT デバイスとサービスのさまざまなアプリケーション シナリオをサポートできます。
ほとんどの開発者は、HTTP Web サービスにすでに精通しています。では、IoT デバイスを Web サービスに接続できるようにしてはどうでしょうか?デバイスは、HTTP リクエストの形式でデータを送信し、HTTP 応答の形式でシステムから更新を受信できます。このリクエストとレスポンスのモデルには、いくつかの重大な制限があります。
HTTP は同期プロトコルです。クライアントはサーバーが応答するまで待つ必要があります。 Web ブラウザにはこの要件がありますが、スケーラビリティが犠牲になります。 IoT 空間では、多数のデバイスとネットワークが信頼性が低いか遅延が大きいため、同期通信が問題になります。非同期メッセージング プロトコルは、IoT アプリケーションに適しています。センサーは測定値を送信し、ネットワークが測定値をターゲットのデバイスやサービスに配信するための最適なルートと時間を決定します。
HTTP は一方向です。クライアントは接続を開始する必要があります。 IoT アプリケーションでは、通常、デバイスまたはセンサーがクライアントになります。つまり、ネットワークからコマンドを受動的に受信することはできません。
HTTP は 1 対 1 のプロトコルです。{0}{1}クライアントがリクエストを行い、サーバーが応答します。ネットワーク上のすべてのデバイスにメッセージを配信することは難しいだけでなく、コストもかかります。これは、IoT アプリケーションでは一般的な使用例です。
HTTP は、多くのヘッダーとルールを備えた重量級のプロトコルです。制約のあるネットワークには適していません。
こうした理由により、ほとんどの高性能でスケーラブルなシステムは、内部データ交換にウェブ サービスではなく非同期メッセージ バスを使用します。{0}
サブスクライブ/パブリッシュ モデル
興味深いことに、この MQTT プロトコル サーバーは、効率的なサービスを目指しているため、実際には Web サーバーよりもはるかに単純な設計になっています。 MQTT が主にメッセージを送受信するメカニズムは、公開 Web サイトと読者の関係に似ています。
現実の世界では、私とあなたは、統合サーバーに接続された MQTT デバイスを持っていることに似ています。あなたは、私たちの公開番号に対する興味や愛情から私たちを購読しており、私が毎日テキスト プッシュを送信すると、私がメッセージをプッシュした携帯電話にあなたが表示されます。このプロセスで、あなたは私の情報を「サブスクリプション」と呼ばれる方法で取得します。このプロセスでは、私の情報を取得する方法は「サブスクリプション」と呼ばれ、この公開番号への私の投稿の動作は「公開」です。そして、誰もが私の記事にアクセスでき、お気軽に私にメッセージを残すことができます。この動作はみんなの「公開」動作であり、私は常にみんなのメッセージを見るためにプッシュを前にしています。これは一種の「購読」動作です。このプロセスでは、すべての外部情報は私たちとは何の関係もありません。単に双方向の情報フローと通信します。MQTT のメッセージング メカニズムも、パブリッシュ - サブスクライブ モデルに基づいています。 MQTT メッセージ配信メカニズムも、「パブリッシュ」-「サブスクライブ」モデルに基づいています。
MQTT 固有の手順は次のとおりです。
ステップ 1:最初の方法を使用して MQTT サーバーを取得し、新しい MQTT 通信製品を作成します。
ステップ 2:次に、このサーバーに接続します。サーバーに接続するための 2 つの重要なパラメータは、ホスト番号 (ドメイン名または IP アドレス) とポート番号です。
ステップ 3:サードパーティのクラウド サーバー プラットフォームを使用している場合は、プロダクト ID と認証情報を使用してこのデバイスにログインする必要がある場合があります。これらの情報は両方とも Device Cloud のバックエンドにあります。{0}
これら 3 つの手順が完了すると、対応するトピックに登録またはメッセージを投稿できます。
China Mobile デバイスのクラウド オープン アクセス プラットフォームを「売り出す」方法を示すドキュメントをまとめます。
これら 3 つの手順は、アプリケーション ソフトウェア開発とマイクロコントローラー開発の両方に適用されます。マイクロコントローラー開発では、AT コマンドと外部 WIFI モジュール通信を使用する場合、一般的なモジュールに AT + MQTT コマンドを含めることができます。これは、マイクロコントローラーへの負担を大幅に軽減する最良の方法です。または、TCP/IP トランスポート層データに直接アクセスして、MQTT を解析することもできます。これには、ユーザーが独自の Json データも解析するために MQTT プロトコルを深く理解している必要があります。そのため、一般に組み込みデバイスを使用する場合は、MQTT プロトコルで既製のモジュールを直接使用することをお勧めします。AT コマンドを直接解析する方が便利です。-
ケーススタディ:
照明の遠隔制御と現在の室温の取得。
このケースに関しては、実際には MQTT の最も単純なアプリケーションの 1 つです。まず、部屋に組み込まれた制御ボードは主に WIFI 経由でサーバーに接続されており、照明のスイッチを制御したり、温度を収集したりすることができます。遠くにあるエンドデバイスは携帯電話です。
通信を継続するには、まず同じ MQTT サーバーに接続する必要があります。
デバイス側の温度情報はデバイスが収集するため、収集したデータを「温度」トピックに公開する必要があり、携帯電話は温度情報を取得するため、「温度」トピックにサブスクライブする必要があります。デバイスが温度情報を「温度トピック」に送信すると、そのトピックは携帯電話で受信されます。
デバイス側の照明制御はデバイスによって実行されるため、「照明スイッチ」トピックにサブスクライブする必要がありますが、携帯電話は照明スイッチを制御するため、この「照明スイッチ」トピックに制御情報を公開する必要があります。携帯電話が「ライトオン」トピックにライトオンメッセージを送信すると、そのトピックが端末で受信され、ライトオンコマンドが実行されます。