MQTT接続を確立する時パラメータはどう設定すれば最適ですか?
EMQX Team
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 アプリケーションとサービスの開発を始めましょう。