メッセージ キューイング テレメトリ トランスポート (MQTT)は、インターネット経由でモノのインターネット (IoT) またはマシン間 (M2M) デバイスとアプリケーションを接続するのに最適な、人気の高い軽量のパブリッシュ/サブスクライブ メッセージング プロトコルです。 MQTT は、低帯域幅または低電力環境で効率的に動作するように設計されているため、多数のリモート クライアントを持つアプリケーションに最適です。 家電、自動車、輸送、製造、医療など、さまざまな業界で使用されています。
MQTT 経由で接続されたデバイスまたはアプリケーションは、クライアントと呼ばれます。 これらのクライアントは、特定のトピックまたは複数のトピックに関するメッセージを公開および/またはサブスクライブします。 サブスクライブしたクライアントは、そのトピックに公開されたすべてのメッセージを受信し、多くのデバイスとサービス間で効率的かつフォールト トレラントなデータ交換を可能にします。
MQTT アーキテクチャの中心となるのはブローカーです。 ブローカーは、クライアント (およびクライアントがサブスクライブしているトピック) を追跡し、メッセージを処理し、それらのメッセージを適切なシステムにルーティングする役割を担うサーバーです。
MQTT プロトコルのいくつかの主要なバージョンが標準として採用されています。 OASIS組織はプロトコルの改訂を管理し、各バージョンの完全な仕様を維持します。 MQTT の各リビジョンではプロトコルの機能セットが拡張されているため、デバイスとブローカーがどのバージョンの MQTT に準拠しているかを把握することが重要です。
MQTT メッセージにはいくつかの種類があり、各メッセージ タイプには、準拠するデバイスとアプリケーションが従う必要がある特定の形式が含まれています。 MQTT プロトコルの改訂は、形式とメッセージ タイプによって異なります。 メッセージ タイプの完全なリストは、 MQTT プロトコルの各仕様に記載されています。
最も一般的な 3 つのメッセージの種類は、CONNECT、PUBLISH、SUBSCRIBE です。 各 MQTT メッセージには、ヘッダー、ペイロード、およびオプションのフラグが含まれます。 メッセージの種類に応じて、ペイロードの長さは可変になります。 たとえば、PUBLISH メッセージでは、ペイロードにはすべてのサブスクライブデバイスに送信されるデータが含まれており、データ フィールドの長さはメッセージのサイズに直接影響します。 デフォルトでは、MQTT デバイスは、セキュリティ保護されていない方法でポート 1883 に接続し、SSL/TLS 暗号化が有効になっている場合はポート 8883 に接続します。
スマートカーは MQTT が実際に動作している素晴らしい例です。 自動車メーカーがリモート診断や車両管理から燃料支払いやエンターテイメントまであらゆるものをサポートする新機能を追加するにつれて、MQTT はコネクテッドカーの共通標準になりました。 ハイパーテキスト転送プロトコル (HTTP) プロトコルとは異なり、MQTT は、車がデッドゾーンに出入りしたり、接続が携帯電話基地局を変更したりした場合でも、永続的なセッションを維持できます。 MQTT は双方向通信もサポートしているため、車とクラウド アプリケーションは、相手からの応答を待たずにデータを送受信しやすくなります。
HTTP と MQTT はどちらも、インターネット経由でデータを送信するために使用されるネットワーク プロトコルです。 それらの違いを見てみましょう。
MQTT の多くの機能により、IoT デバイス (IoT の「モノ」) とバックエンド システム間のメッセージングに最適なプロトコルとなっています。 ここでは、次の 4 つの機能に焦点を当てます。
MQTT は、基盤となるトランスポート プロトコルとして、伝送制御プロトコル/インターネット プロトコル (TCP/IP) をサポートしています。 この広く使用されているネットワーク プロトコルにより、クライアントとブローカー間でメッセージが確実に送信されます。
TCP/IP が信頼性が高く効率的であると考えられる理由はいくつかあります。
TCP/IP は最も一般的ですが、MQTT メッセージの転送に唯一の選択肢というわけではありません。 MQTT プロトコルは、ユーザー データグラム プロトコル (UDP) および WebSocket でも動作します。
NGINX が MQTT ベースの IoT システムをどのように保護し、負荷分散し、高可用性を提供できるかを継続的に調査するために、以下の無料リソースを提供できることを誇りに思います。