MQTT 接続の確立は、MQTT プロトコルを使用した通信の最初のステップです。MQTT プロトコルは、開発者がさまざまな要件を満たす IoT アプリケーションを作成できるようにする多くの接続パラメーターを提供します。

この記事では、MQTT の各接続パラメーターの役割を紹介し、開発者が MQTT を使用する最初の一歩を踏み出すのに役立ちます。

MQTT 接続の概要

MQTT 接続はクライアントからブローカーへ開始されます。MQTT クライアントライブラリを実行しているアプリケーションまたはデバイスはすべてMQTT クライアントです。MQTT ブローカーは、クライアントの接続、切断、サブスクライブ (またはアンサブスクライブ) 要求を処理し、パブリッシュ要求の受信時にメッセージをルーティングします。

ブローカーとのネットワーク接続を確立した後、クライアントが送信する必要がある最初のメッセージはパケットですCONNECT。ブローカーはCONNACK応答としてをクライアントに返信する必要があり、クライアントがCONNACKパケットを受信すると、MQTT 接続が正常に確立されます。CONNACKクライアントがブローカーからパケットを時間内に受信しない場合(通常はクライアント側からの構成可能なタイムアウト)、クライアントはネットワーク接続をアクティブに閉じることがあります。

MQTT プロトコル仕様は、使用するトランスポートを制限しません。MQTT で最も一般的に採用されているトランスポートプロトコルは、TCP/TLS と Websocket です。EMQ は、MQTT over QUICも実装しています。

MQTT over TCP/TLS

TCP/TLS は広く使用されており、コネクション向けの信頼性の高いバイトストリームベースのトランスポート層通信プロトコルです。これにより、受信したバイトが確認応答および再送信メカニズムを通じて送信されたバイトと同じであることが保証されます。

通常、MQTT は TCP/TLS に基づいて、TCP/TLS の利点の多くを継承し、低帯域幅、高遅延、およびリソースに制約のある環境でも安定して実行できます。

MQTT over WebSocket

Web テクノロジーの急速な発展により、UI 用の強力なレンダリングエンジンを利用して、Web ブラウザーに実装できるアプリケーションがますます増えています。Web アプリケーションのネイティブ通信方式である WebSocket も広く使用されています。

デバイス監視システムなどの多くの IoT Web ベースアプリケーションは、デバイスデータをブラウザにリアルタイムで表示する必要があります。ただし、ブラウザは HTTP プロトコルに基づいてデータを送信するため、TCP 経由で MQTT を使用することはできません。

MQTT プロトコルの創設者は Web アプリケーションの重要性を予見していたので、MQTT プロトコルは創立以来、WebSocket 上の MQTT を介した通信をサポートしています。MQTT over WebSocket の使用方法の詳細については、ブログを参照してください。

MQTT over QUIC

QUIC (RFC 9000) は、次世代インターネットプロトコル HTTP/3 の基礎となるトランスポートプロトコルであり、TCP/TLS プロトコルと比較して接続オーバーヘッドとメッセージ遅延が少ない最新のモバイルインターネットへの接続を提供します。

IoT メッセージングシナリオに非常に適した QUIC の利点に基づいて、EMQX 5.0 では QUIC 上に MQTT が導入されています。詳細についてはブログをご覧ください。

MQTT 接続パラメータの使用

接続アドレス

通常、MQTT の接続アドレスには、ブローカー IP (またはドメイン名)、ブローカーポート、およびプロトコルが含まれます。クラスター化された MQTT ブローカーの場合、通常はロードバランサーが前に配置されるため、IP またはドメイン名が実際にはロードバランサーになる可能性があります。

MQTT over TCP の接続

たとえば、mqtt://broker.emqx.io:1883は TCP ベースの MQTT 接続アドレス、はmqtts://broker.emqx.io:1883TLS/SSL ベースの MQTT セキュア接続アドレスです。

一部のクライアントライブラリでは、TCP ベースの接続がtcp://ip:1883

MQTT over WebSocketの接続

WebSocket 接続を使用する場合は、接続アドレスにパスも含める必要があります。EMQXに構成されたデフォルトのパスはです/mqtt。

たとえば、ws://broker.emqx.io:8083/mqttは WebSocket ベースの MQTT 接続アドレス、はwss://broker.emqx.io:8083/mqttWebSocket ベースの MQTT セキュア接続アドレスです。

ClientID

MQTT ブローカーはClientID を使用してクライアントを識別し、ブローカーに接続する各クライアントには一意のClientID が必要です。ClientID は UTF-8 でエンコードされた文字列です。クライアントが長さゼロの文字列で接続する場合、ブローカーはそれに一意の文字列を割り当てる必要があります。

MQTT プロトコルのバージョンとブローカーの実装の詳細に応じて、ブローカーが受け入れる有効な文字セットは異なります。最も保守的なスキームは、文字を使用し[0-9a-zA-Z]、長さを 23 バイトに制限することです。

ClientID の一意性により、2 つのクライアントが同じClientID で同じブローカーに接続すると、後で接続したクライアントが先に接続したクライアントを強制的にオフラインにします。

ユーザー名パスワード

MQTT プロトコルはユーザー名とパスワードの認証をサポートしていますが、基礎となるトランスポート層が暗号化されていない場合、ユーザー名とパスワードは平文で送信されるため、最高のセキュリティを確保するには、MQTT プロトコルを使用することをお勧めしmqttsますwss。

ほとんどの MQTT ブローカーはデフォルトで匿名ログインを許可します。つまり、ユーザー名やパスワードを指定する (または空の文字列を設定する) 必要はありません。

接続タイムアウト

ブローカーパケットを受信するまでの待ち時間CONNACK。この時間内に受信しない場合CONNACK、接続は閉じられます。

MQTT Keep Alive

Keep Alive は秒単位の間隔です。送信するメッセージがない場合、クライアントは Keep Alive の値に従って定期的にハートビートメッセージをブローカーに送信し、ブローカーが接続を切断しないようにします。

接続が正常に確立された後、ブローカーはキープアライブの 1.5 回以内にクライアントからパケットを受信しなかった場合、クライアントとの接続に問題があると判断し、ブローカーはクライアントから切断されます。

Keep Alive の詳細については、ブログをご覧ください。

Clean Session

Clean Sessionに設定すると、false永続的なセッションが作成されます。クライアントが切断すると、セッションは残り、セッションの有効期限が切れるまでオフラインメッセージが保存されます。に設定すると、trueクライアントが切断されると自動的に破棄される新しい一時セッションが作成されます。

永続的なセッションにより、サブスクライブクライアントはオフラインでもメッセージを受信できるようになります。この機能は、ネットワークが不安定な IoT シナリオで非常に役立ちます。

ブローカーが永続セッションのために保持するメッセージの数は、ブローカーの設定によって異なります。たとえば、EMQ が提供するパブリック MQTT ブローカーは、オフラインメッセージを 5 分間保持するように設定されており、メッセージの最大数は 1000 です (QoS 1 および QoS 2 メッセージの場合)。

※ 永続的なセッションの回復の前提は、クライアントが固定のClientID で再接続することです。ClientID が動的である場合、新しい永続セッションが作成されます。

Clean Session の詳細については、ブログをご覧ください。

Last Will

Will Message を設定した MQTT クライアントが異常オフラインになると、MQTT ブローカーはそのクライアントによって設定された Will Message を公開します。

***予期しないオフラインには、*ネットワーク障害により接続がサーバーによって閉じられた場合が含まれます。デバイスの電源が突然切れた。デバイスが許可されていない操作を実行しようとしたため、サーバーによって接続が切断された場合などです。

Will メッセージは、トピック、ペイロード、QoS、保持なども含まれる簡略化された MQTT メッセージとして見ることができます。

デバイスが予期せずオフラインになると、意志メッセージがに送信されますWill Topic。
Will Payload送信するメッセージの内容です。
これは、Will QoS標準の MQTT メッセージの QoS と同じです。MQTT QoS の詳細については、ブログをご覧ください。
に設定Will Retainすると、trueウィルメッセージが保持されるメッセージであることを意味します。フラグが設定されたメッセージを受信したretainMQTT ブローカーは、メッセージがパブリッシュされたトピックのメッセージを保存する必要があり、最新のメッセージのみを保存する必要があります。そのため、このトピックに興味のあるサブスクライバーは、サブスクリプション後にパブリッシャーからの次のメッセージを待つ必要がなく、オフラインでいつでも再接続して最新のメッセージを受信できます。

MQTT Retained について詳しくは、ブログをご覧ください。

MQTTバージョン

MQTT プロトコルの最もよく使用されるバージョンは、MQTT v3.1、MQTT v3.1.1、および MQTT v5.0 です。現在、MQTT 5.0 はほとんどの IoT 企業で選ばれるプロトコルとなっており、初めて MQTT 開発を行う場合はこのバージョンを直接使用することをお勧めします。

MQTT 5.0の新機能の使用方法については、EMQ が提供する MQTT 5.0 ブログシリーズを参照してください。

MQTT v5.0 の新しい接続パラメータ

クリーンスタートとセッションの有効期限の間隔

Clean Session は MQTT 5.0 で削除されましたが、Clean Start と Session Expiry Interval が追加されました。

Clean Start の場合、true既存のセッションはすべて破棄され、新しいセッションが作成されます。値falseは、サーバーがクライアントとの通信を再開するために、ClientID に関連付けられたセッションを使用する必要があることを意味します (セッションが存在しない場合を除く)。

「セッション有効期限間隔」が 0 に設定されているか、存在しない場合、ネットワーク接続が閉じられるとセッションは終了します。(UINT_MAX)の場合0xFFFFFFFF、セッションは期限切れになりません。0 より大きい場合、ネットワーク接続が閉じられた後にセッションが残る秒数。

クリーンスタートとセッションの有効期限間隔について詳しくは、ブログをご覧ください。

接続プロパティ(User Properties)

MQTT 5.0 では、プロトコルの拡張性を高めるための新しい接続プロパティも追加されています。Connect Properties の詳細については、ブログをご覧ください。

安全な MQTT 接続を確立にはどうすればよいですか?

MQTT プロトコルはユーザー名とパスワード、ClientID などの認証メカニズムを提供しますが、これは IoT セキュリティには十分ではありません。TCPによるPlaintext伝送通信では、データの安全性を保証することが困難です。

TLS (Transport Layer Security)、または一部の文脈では新しく非推奨になった名前 SSL は、主に、通信する 2 つ以上のコンピュータアプリケーション間でプライバシーとデータの整合性を提供することを目的としています。TLS 上で実行される MQTT は、そのセキュリティ機能を最大限に活用して、データの整合性とクライアントの信頼性を確保できます。

SSL/TLS を有効にする手順は、MQTT ブローカーによって異なります。EMQX には、一方向/双方向認証、X.509 証明書、負荷分散された SSL、およびその他の多くのセキュリティ証明書のサポートを含む、TLS/SSL のサポートが組み込まれています。

一方向認証は、サーバー証明書を検証するだけで安全な通信を確立する方法です。通信は確実に暗号化されますが、クライアントの信頼性は検証できません。通常、ユーザー名とパスワード、ClientID などの認証メカニズムと組み合わせる必要があります。安全な一方向認証された MQTT 接続を確立する方法については、ブログを参照してください。

双方向認証とは、通信を認証するときにサーバーとクライアントの両方が証明書を提供する必要があり、双方が認証を行って相手が信頼されていることを確認する必要があることを意味します。高度なセキュリティ要件を持つ一部のアプリケーションシナリオでは、双方向認証を有効にする必要があります。安全な双方向認証された MQTT 接続を確立する方法については、ブログを参照してください。

***注:*ブラウザで MQTT over WebSocket を使用する場合、双方向認証通信はまだサポートされていません。

How to use TLS/SSL two-way authentication connections in browser? · Issue #1515 · mqttjs/MQTT.js

まとめ

この時点で、MQTT 接続がどのように確立されるか、および各接続パラメータの役割を十分に理解しているはずです。

次に、 EMQ が提供する「MQTT プロトコルのわかりやすいガイド」シリーズの記事を参照して、MQTT トピック、ワイルドカード、保持メッセージ、Last-Will などの機能について学ぶことができます。MQTT のより高度なアプリケーションを探索し、MQTT アプリケーションとサービスの開発を始めましょう。