# マルチプロトコルゲートウェイ EMQX マルチプロトコルゲートウェイは、MQTT以外のすべてのプロトコル接続の処理、認証、メッセージの送受信を可能にします。さまざまなプロトコルに対して統一された概念モデルを提供します。 EMQX 5.0以前は、MQTT以外のプロトコルアクセスは個別のプロトコルプラグインで実装されていました。これらのプラグインは設計や実装が異なっており、利用が困難でした。 5.0以降、EMQXはマルチプロトコルゲートウェイを提供し、統一された概念および運用モデルを定義することで、より使いやすくなっています。 マルチプロトコルゲートウェイは、MQTT-SN、STOMP、CoAP、LwM2Mなどのプロトコルをサポートしています。Dashboardで直接有効化および設定できるほか、REST APIや`base.hocon`で管理可能です。これらのゲートウェイの有効化方法やビジネスニーズに合わせた設定カスタマイズについては、以下のリンクをご参照ください。 ::: warning 重要なお知らせ ExProtoゲートウェイはEMQX 6.2.0で非推奨となり、EMQX 6.3.0で削除されました。 ::: - [MQTT-SN](./mqttsn.md) - [STOMP](./stomp.md) - [CoAP](./coap.md) - [LwM2M](./lwm2m.md) - [OCPP](./ocpp.md) - [GB/T 32960](./gbt32960.md) - [JT/T 808](./jt808.md) - [NATS](./nats.md) ## マルチプロトコルゲートウェイの仕組み EMQX マルチプロトコルゲートウェイは、リスナー、接続／セッション、パブリッシュ／サブスクライブ、認証、認可などの主要コンポーネントに対して統一された概念および運用モデルを定義しています。 gateway_struct 各コンポーネントの概要は以下の通りです。 - **リスナー**：TCP、SSL、UDP、DTLSのリスナータイプをサポートします。各ゲートウェイは複数のリスナーを作成可能です。 - **接続／セッション**：ゲートウェイは受け入れたクライアント接続ごとにセッションを作成し、サブスクリプションリスト、送受信キュー、クライアントメッセージの再送制御を管理します。 - **パブリッシュ／サブスクライブ**：各ゲートウェイタイプは、MQTTプロトコルのPUB/SUBメッセージモデルへの適応方法を定義します。PUB/SUB概念を持たないプロトコルでは、メッセージのトピックやペイロードを設定する必要があり、ゲートウェイごとに異なるメッセージフォーマットを使用する場合があります。 - **認証**：各ゲートウェイは認証機能を設定可能で、クライアント情報を用いてログイン認可を行います。 ## 主な機能 ### リスナー 各ゲートウェイは複数のリスナーを有効化でき、プロトコルごとに以下のリスナータイプをサポートしています。 | | TCP | UDP | SSL | DTLS | Websocket | Websocket over TLS | | ---------- | ---- | ---- | ---- | ---- | --------- | ------------------ | | MQTT-SN | | ✔︎ | | ✔︎ | | | | STOMP | ✔︎ | | ✔︎ | | | | | CoAP | | ✔︎ | | ✔︎ | | | | LwM2M | | ✔︎ | | ✔︎ | | | | OCPP | | | | | ✔︎ | ✔︎ | | GB/T 32960 | ✔︎ | | ✔︎ | | | | | JT/T 808 | ✔︎ | | | ✔︎ | | | | NATS | ✔︎ | | ✔︎ | | ✔︎ | ✔︎ | #### バインドアドレス ゲートウェイリスナーの`bind`設定は、クライアントのトラフィックを受信するためのローカルアドレスとポートを指定します。明示的なIPアドレスとポート、またはポートのみを指定可能です。 EMQX 6.3.0以降、`bind`でポートのみを指定したゲートウェイリスナーは、ノードレベル設定の`node.default_listener_address`を使用してデフォルトのバインドアドレスを選択します。`bind`に明示的なIPアドレスとポートがある場合はそちらが優先されます。この設定がない場合、`legacy`および`hardened`セキュリティプロファイルの両方で、ポートのみ指定のゲートウェイリスナーはすべてのネットワークインターフェースでリッスンします。 ポートのみ指定のゲートウェイリスナーのアドレスを変更するには、各ノードの`emqx.conf`または`EMQX_NODE__DEFAULT_LISTENER_ADDRESS`で設定し、変更後にノードを再起動してください。これはMQTTリスナーのポートのみバインドやDashboardのHTTPリスナーにも影響します。[デフォルトリスナーアドレス](../../guides/access-control/security-profile.md#default-listener-address)でサポートされる値や公式Dockerイメージのデフォルトを確認できます。 #### リスナーアドレス情報の確認 ゲートウェイリスナーのアドレスを確認するには、`GET /api/v5/gateways/:name/listeners`を使用します。`:name`はゲートウェイ名（例：`stomp`）に置き換えてください。EMQX 6.3.0以降、各リスナーの`node_status[].status`には`resolved_address`および`resolved_address_from`が含まれます。各`node_status`エントリは対応するノードの値を報告し、クラスター全体の`status`にはこれらのノードローカルフィールドは含まれません。 各`node_status`エントリで`status.running`と`status.resolved_address`を確認し、そのノードでリスナーが稼働しているか判別してください。空の`resolved_address`値の解釈については[リスナーアドレス情報の確認](../../guides/configuration/listener.md#view-listener-address-information)を参照してください。MQTTの`emqx ctl listeners`コマンドやゲートウェイの単一リスナー設定エンドポイントではなく、このゲートウェイリストエンドポイントを使用してください。 ### メッセージフォーマット PUB/SUBメッセージモデルとの互換性を確保するため、各ゲートウェイタイプは基盤となるプロトコルにPUB/SUB概念があるか否かに応じて適応します。 [MQTT-SN](./mqttsn.md)や[STOMP](./stomp.md)のようにPUB/SUB概念を持つプロトコルでは、クライアント送信のトピックとペイロードをそのまま使用し、メッセージフォーマットの変換は不要です。 [CoAP](./coap.md)や[LwM2M](./lwm2m.md)のようにPUB/SUB概念を持たないプロトコルでは、トピックやパブリッシュ、サブスクライブの定義がありません。この場合、ゲートウェイ側でメッセージ内容のフォーマットを設計し、ゲートウェイタイプごとに異なるフォーマットを使用することがあります。 - **CoAP**：CoAPゲートウェイは[Publish-Subscribe Broker for the CoAP](https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-09)標準で定義されたURIパスとメソッドを使用します。詳細は[メッセージパブリッシュ](./coap.md#message-publish)、[トピックサブスクライブ](./coap.md#topic-subscribe)、[トピックサブスクライブ解除](./coap.md#topic-unsubscribe)を参照してください。 - **LwM2M**：LwM2Mプロトコルのメッセージモデルは[Resources Model and Operations](https://technical.openmobilealliance.org/OMNA/LwM2M/LwM2MRegistry.html)に基づいており、MQTTプロトコルのパブリッシュ／サブスクライブモデルとは全く異なります。詳細は[LwM2Mゲートウェイ - メッセージフォーマット](./lwm2m.md#message-format)を参照してください。 ### 認証 認証は、システムに接続を試みるクライアントの身元を検証するプロセスです。バージョン5.0以降、ゲートウェイはログイン認可のための認証機能をサポートしています。 ゲートウェイによってサポートする認証タイプは異なりますが、すべてのゲートウェイはHTTPベースの認証をサポートしています。[HTTPベース認証](../../guides/access-control/authn/http.md)。以下の表はサポートされる認証タイプを示しています。 | | HTTPサーバー | 組み込みデータベース | MySQL | MongoDB | PostgreSQL | Redis | JWT | LDAP | | ---------- | ----------- | ----------------- | ----- | ------- | ---------- | ----- | ---- | ---- | | MQTT-SN | ✔︎ | | | | | | | | | STOMP | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | | CoAP | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | | LwM2M | ✔︎ | | | | | | | | | OCPP | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | | GB/T 32960 | ✔︎ | | | | | | | | | JT/T 808 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | | | NATS | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | 注：認証機能が設定されていない場合、どのクライアントもログイン可能です。 #### ゲートウェイでの認証の仕組み EMQX マルチプロトコルゲートウェイは、接続してくるクライアントの認証を担当します。これは各接続に対して`ClientInfo`を作成することで実現されます。 `ClientInfo`には、認証に一般的に使われる`Username`や`Password`などの共通フィールドが含まれます。さらに、各ゲートウェイはLwM2Mの`Endpoint Name`のように独自のクライアント情報フィールドを持ち、これらも認証に利用される場合があります。 認証機能が設定されている場合、ゲートウェイはクライアントのUsernameとPasswordを自身のデータベースと照合し、一致すればクライアントを認証しゲートウェイへのアクセスを許可します。 ::: tip 異なるゲートウェイ間でクライアントIDは重複可能ですが、同一ゲートウェイに重複したクライアントIDでログインすると、既存のそのクライアントIDに紐づくセッションは切断されます。 ::: ## 外部システムとの連携 外部システムとの連携を強化するため、ゲートウェイはEMQXで定義されたフックをサポートしています。 ゲートウェイ間の意味論の違いにより、利用可能なコアフックは一部に限られます。 クライアント接続関連のフックのサポート状況は以下の通りです。 外部システムとの相互運用性向上のため、ゲートウェイはEMQXで定義されたフックをサポートする設計となっています。 しかし、各ゲートウェイ間の意味論の違いにより、利用可能なコアフックは一部に限られます。以下の表はクライアント接続関連のサポートされるフックを示しています。 | 名前 | 必須かどうか | 説明 | 対応プロトコル | | ---------------------- | ------------ | ------------------------------------------------------------ | -------------------- | | `client.connect` | 任意 | クライアント接続要求の数（成功・失敗を含む） | すべてのゲートウェイ | | `client.connack` | 任意 | クライアントが受信した`CONNACK`メッセージの数 | すべてのゲートウェイ | | `client.authenticate` | 必須 | 認証済みクライアントの数 | | | `client.connected` | 必須 | 正常に接続したクライアントの数 | すべてのゲートウェイ | | `client.disconnected` | 必須 | クライアントの切断数（正常切断・異常切断を含む） | すべてのゲートウェイ | | `client.authorize` | 必須 | 認可されたクライアントのパブリッシュ／サブスクライブ要求の数 | すべてのゲートウェイ | | `client.subscribe` | 任意 | クライアントのトピックサブスクライブ試行数 | MQTT-SN
STOMP | | `client.unsubscribe` | 任意 | クライアントのトピックサブスクライブ解除試行数 | MQTT-SN
STOMP | セッションおよびメッセージ関連のフックはプロトコル間の意味論の違いがないため、各ゲートウェイタイプで完全にサポートされています。 フックの詳細については[フック](../../guides/extensions/hooks.md)を参照してください。