MQTT を学ぶための最も包括的なリソース。基礎概念から高度なパターンまで、初回接続から本番デプロイメントまで。
ここから MQTT の旅を始めましょう。コアコンセプト、プロトコルメカニズム、基本パターンを理解します。
基礎を超えて。QoS、セキュリティ、クラスタリング、パフォーマンスチューニングなどの高度なトピックを探求します。
すべての主要プラットフォームとプログラミング言語向けのチュートリアル。
MQTT 用語とコンセプトの包括的なリファレンス。
時にはサーバーを直接ブローカーと呼ぶこともあります。これら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でのみ適用されます。
クライアントがブローカーから予期せず切断された場合、サーバーは接続時にクライアントが設定した遺言メッセージを他のクライアントに転送します。
「$」で始まるトピックは、その使用方法とシナリオがサーバーによって決定され、クライアントはそれらのトピックを自己の目的で任意に使用することはできません。
MQTT プロトコルと EMQX に関する一般的な質問にエキスパートがお答えします。
MQTT は IoT 接続のための OASIS 標準です。パブリッシュ・サブスクライブパターンに基づく軽量メッセージ転送プロトコルで、リソースが制約されたデバイスや低帯域幅、高レイテンシ、不安定なネットワーク向けに設計されており、一定レベルのメッセージ信頼性を提供します。これらの特徴により、MQTT はコネクテッドカー、産業製造、モバイル通信などのシナリオで広く使用されています。
現在、MQTT の主要バージョンは v3.1.1 と v5.0 です。MQTT v5.0 は 2019 年 3 月にリリースされ、v3.1.1 と比較して多くの改善と拡張が導入されました。現在、市場のほとんどのクライアントとブローカーは MQTT v5.0 をサポートしています。
MQTT はパブリッシュ・サブスクライブパターンで動作し、メッセージの送信者と受信者を効果的に分離し、ブローカーという重要な中間者の役割を必要とします。ブローカーは MQTT クライアント間のメッセージ転送の橋渡し役であり、クライアントからメッセージを受信し、メッセージのトピックに基づいて適切なサブスクライバーにルーティングする責任があります。
EMQX は、フィジカル AI と現代の IoT 向けに設計された、世界で最もスケーラブルなオープンソース MQTT ブローカーです。クラウドネイティブな分散メッセージングサーバーとして、EMQX はミッションクリティカルなアプリケーションの基盤を提供し、1 億を超える同時接続をサポートし、超低レイテンシで毎秒数百万のメッセージを処理します。
はい。EMQX は包括的な SSL/TLS 機能をサポートしており、シングル/デュアル認証、X.509 証明書認証、SNI などをサポートしています。
EMQX は、MQTT を含むすべてのクライアント接続に対して TLS を有効にしてアクセスとメッセージ転送のセキュリティを確保するだけでなく、すべての外部リソース接続に対しても TLS を有効にして、外部リソースへのアクセス時のデータセキュリティを確保しています。
トピックは異なるメッセージを識別し区別するために使用され、MQTT メッセージルーティングの基盤を形成します。パブリッシャーはメッセージ公開時にトピックを指定でき、サブスクライバーは関心のあるトピックを選択して関連メッセージを受信できます。
MQTT は IoT などの分野で広く使用されているメッセージングプロトコルです。MQTT はすべてのメッセージをクライアントにルーティング・配信するためのサーバーを必要とし、EMQX はそのサーバーの具体的な実装です。EMQX は世界で最も人気のあるオープンソース MQTT メッセージサーバーの一つでもあり、MQTT v3.1、v3.1.1、v5.0 プロトコル標準を完全にサポートしています。
MQTT と AMQP はどちらも TCP/IP 上で動作するバイナリメッセージ転送プロトコルであり、オープン標準プロトコルです。
ただし、MQTT は主に高レイテンシ、低帯域幅、不安定なネットワーク向けに設計されており、パブリッシュ・サブスクライブパターンを使用し、トピックベースのサブスクリプションによるメッセージルーティングをサポートしています。MQTT は軽量なメッセージ構造を持ち、リソースが制約されたデバイスに適しています。また、不安定なネットワークで動作するデバイス向けに特別に設計された、遺言メッセージ、保持メッセージ、セッションなどの機能も提供します。
一方、AMQP は汎用メッセージキュープロトコルを提供することを目的としており、アプリケーションまたはサーバー間でビジネスメッセージを安全かつ効率的に転送します。より複雑なアプリケーションシナリオに対応するさまざまなルーティングルールを提供し、ビジネスシナリオで広く使用されています。
MQTT と Kafka は完全に異なるテクノロジーですが、パブリッシュ・サブスクライブパターンに基づいていることやトピックによるメッセージルーティングなど、いくつかの類似した概念を共有しています。
実際には、Kafka はデータの保存と読み取りに重点を置いており、高スループットのリアルタイムストリーミングデータ処理シナリオ向けに設計されています。一方、MQTT は大量のデバイス接続とトピックによるメッセージルーティングに重点を置き、不安定なネットワーク環境でリアルタイムで信頼性の高いメッセージ交換を行います。したがって、MQTT と Kafka の最大の違いは、それぞれ異なるユースケースと解決する問題にあります。
実際の本番アプリケーションでは、MQTT と Kafka はしばしば一緒に使用されます。MQTT ブローカーは大量の端末デバイスの接続という課題を解決し、受信データを Kafka に転送します。Kafka はそれを異なるビジネスアプリケーションに配信し、さらなるメッセージ分析と処理を行います。
はい、EMQX は Apache 2.0 ライセンスに基づく完全オープンソースの MQTT メッセージサーバーです。2013 年に Github でリリースされて以来、EMQX は 11K 以上のスターを獲得しています。EMQX 公式ウェブサイトまたは Github から EMQX を無料でダウンロードして使用できます。
MQTT プロトコルに加えて、EMQX は MQTT-SN、CoAP、STOMP、LwM2M などの他の IoT プロトコルもサポートしています。異なるプロトコルを使用するクライアント同士が相互に通信できます。
EMQX は MQTT v3.1、v3.1.1、v5.0 を含むすべてのプロトコルバージョンの MQTT を完全にサポートしています。異なるプロトコルバージョンを使用するクライアントの同時接続も可能です。
MQTT は複数のセキュリティメカニズムを提供します。パスワード認証、トークン認証、または複数の認証アルゴリズムをサポートする拡張認証メカニズムにより、クライアントとサーバーの ID 認証を実現できます。サーバー側のアクセス権限チェックと組み合わせることで、認証されたクライアントのみが承認されたデータにアクセスできます。
MQTT は SSL/TLS を使用した暗号化通信もサポートしており、データのプライバシーと整合性を保護します。
ただし、システムの最終的なセキュリティは具体的な実装に依存することに注意してください。たとえば、パスワードを安全に保存しているか、TLS で十分に安全な暗号スイートを使用しているかなどが重要です。
MQTT プロトコルは、基盤となるトランスポート層が順序付けられた信頼性の高い双方向バイトストリーム転送を提供することを要求するため、TCP プロトコルが通常 MQTT の第一選択です。
ただし、MQTT は特定のトランスポートプロトコルの使用を義務付けていません。メッセージの順序到着を保証できない UDP は MQTT の基盤トランスポートプロトコルとして直接使用するには適していませんが、UDP に基づいて実装された QUIC は TCP と TLS のすべての利点を統合し、接続オーバーヘッドや接続の非マイグレーション性などの欠点を解決しているため、MQTT のトランスポートプロトコルとして非常に適しています。
EMQX の核心は MQTT であり、RabbitMQ の核心は AMQP です。それらは異なる設計目標とユースケースを持っています。EMQX は高性能でスケーラブル、機能豊富な MQTT メッセージサーバーであり、IoT および M2M 通信向けに最適化されています。EMQX は大量の同時接続とメッセージスループットを処理するように設計されており、低レイテンシとリアルタイム通信を必要とするアプリケーションに適しています。
RabbitMQ は異なるシステム間のデータ交換と転送により多く使用されます。Kafka と同様に、多くの場合、RabbitMQ と EMQX を組み合わせて使用するとより良い結果が得られます。
プロトコル間のパフォーマンスの違いだけを比較しても意味がありません。これは具体的なユースケースの実装により依存します。同じプロトコルの異なる実装でも大きなパフォーマンスの違いがある可能性があります。アプリケーションシナリオに基づいてプロトコルを選択し、期待するパフォーマンスに基づいてプロトコルの具体的な実装を選択することがより合理的なソリューションです。
学習から本番環境まで、必要なすべてを提供します。
プロトタイプから数百万デバイスへスケール。
数秒で本番環境対応の MQTT ブローカーをデプロイ。無料で始めて、無限にスケール。
クレジットカード不要
MQTT インフラストラクチャを完全にコントロール。どこにでもデプロイし、1,000 万接続までスケール。