📱

MQTT通信について(座学)

2025/02/16に公開

はじめに

前回のBluttoothに続いて、少し気になったのでまとめます。MQTTクライアントを使ってAWSでやってみよう編は次回書いてみようかなと思っています。

MQTT通信は軽量で効率的なプロトコルのため、スマートホームや産業IoTなど幅広い分野で利用されています。

まずはイメージを掴むためにですが、温度センサーのIoTデバイスがあり、スマホの専用アプリで温度が確認できる、というのが想像しやすい気がします。

MQTT通信の特徴

MQTT(Message Queuing Telemetry Transport)は以下の特徴を持っています。

  • 軽量かつ低帯域
    • 通信データ量が少ない
    • ネットワーク負荷を抑えられる
  • 双方向通信
    • デバイス間でメッセージのやり取りが可能
  • 疎結合
    • 通信するデバイス同士が直接つながる必要がなく、柔軟なシステム構築が可能
  • QoS(Quality of Service)の選択が可能
    • メッセージの送信品質を用途に応じて調整できる
    • 詳細はこの後記載します

仕組み(Publisher/Subscriberモデル)

MQTTはPublisher/Subscriberモデルと呼ばれる仕組みを使います。

用語の確認

  • MQTTクライアント
    • MQTTを使用してメッセージを送受信するもの
    • 先のイメージでいうと、温度センサーもスマホもMQTTクライアントになる
  • Broker (ブローカー)
    • ブローカーは受け取った情報を適切なMQTTクライアントに送る役割
    • ブローカーを挟んで、送信側と受信側が疎結合な状態で通信を行う方式をパブリッシュ/サブスクライブ(Pub/Sub)という
    • ブローカーはソフトウェアで、受信したメッセージを適切な受信者にルーティングをする
  • パブリッシュ/サブスクライブ
    • MQTTクライアントがメッセージを送信することをパブリッシュという
    • 逆にMQTTクライアントがメッセージを受信することをサブスクライブという
  • トピック
    • メッセージを送る際、何に関するメッセージか記載された情報
    • 通常は/で区切られている

横文字多くて意味わかりません(と私は思いました)ので、以下がイメージ図です。先の温度センサーを例にしています。

QoSについて

MQTTでは、メッセージ配信の信頼性をさまざまなネットワーク環境下で保証するQoSが定められています。

QoS0: とりあえず送るけど届くかはわかんないぜ!

かっこよく言うと At most once
最大1回のメッセージが送信されますが、到達することは保証されていません。

先の温度センサーの例では、温度は最新値が重要ですし(用途による)、1回送れなくても大きな問題にはなりにくいケースが多いと思います。

QoS0は上記のようなデータが損失しても大きな問題が起きないような場合に利用されます。

QoS1: 必ず送ります、けどしかしたら何回も送っちゃうかも...

かっこよく言うと At least once
最低1回のメッセージが到達することが保証されます。受信者はメッセージが届いたことを送信者に通知するため、メッセージが到達することが保証されます。

先の温度センサーで考えると、家にペットがいて、室温が28°以上になったら危ないのでアラートを出すという設定をしてるケースを考えましょう。

この場合、アラート忘れちゃいました。だと困っちゃうわけで、重複してもいいから送ってくれよと思うはずです。まさにこの場合がQoS1ですね。

QoS2: 必ず1回だけ送ります!

かっこよく言うと Exactly once
文字通り重複なく1回だけ送るという完成系になります。

中身の仕組みがどうなっているかというと、

  • メッセージを送る
  • 受信者から返事(PUBREC)があるまで待機(QoS1だと一定時間経って返事がないと再送)
  • 受信者から返事がきたら、「では完了します」と送信する(PUBREL)
  • 受信者は送信者に「はい、OKです」と連絡(PUBCOMP)

このような多段チェックにより重複を防ぐようになっています。

おわりに

簡単でしたが以上です。。

reference

https://dev.classmethod.jp/articles/mqtt_illustrations/

https://qiita.com/emqx_japan/items/7f818cb2071183ef7253

Discussion