MQTTとHTTPの違い。IoT開発に使用するプロトコルはどのように選ぶべきか?
MQTTとHTTPの特徴
MQTTプロトコル
非常に軽量で効率的なメッセージングプロトコルです。
配信するメッセージの重要性によってQoSレベルを変更することで、ネットワークが不安定な環境でも確実にメッセージを届けることが可能です。これらの特性から移動体端末やネットワーク帯域幅、リソースが限られたIoTの分野での利用が広がっています。
HTTPプロトコル
HTMLなどの文書を転送することを目的として設計されたプロトコルです。
MQTTと違いステートレスなプロトコルなので、セッションは保持されず各リクエストは独立して処理が行われます。
セッションを管理する必要がある場合は、Cookieなどを使用することでステートフルな振る舞いを実現することができます。WebブラウザやWebアプリケーションにおいて広く利用されていますが、IoTの分野でも普及率やアプリケーションとの互換性などから使用されることがあります。
MQTTとHTTPの比較
通信方式の比較
MQTTは、Pub/Subモデルが採用されており、次のような特徴があります。
・クライアントとブローカー間は常時接続でリアルタイムに相互通信を行うことができます。
・複数のクライアントが共通のトピックをサブスクライブすることで、多対多の通信を簡単に行うことができます。

HTTPは、クライアントサーバーモデルが採用されており、次のような特徴があります。
・クライアントからサーバーにリクエストを送信し、レスポンスを受け取る1対1の通信を行います。
・基本的には通信を行う度に接続処理が必要になりますが、キープアライブを指定することで持続的な接続を行うこともできます。

通信データの比較
ヘッダサイズMQTTは、ヘッダサイズの最小は2bytesになります。
HTTPは、ヘッダサイズは24bytes + リソースURIとホスト名のbytesが必要になります。(HTTP1.1かつGETを使用した最小サイズの場合)

MQTTはヘッダサイズが小さいため、各通信におけるオーバーヘッドを抑えることができます。全体の通信データ量が減少することでネットワーク帯域を効率的に利用できるようになり、送受信に必要なデバイスの電力消費も抑えることができます。
最大送信データサイズMQTTは、ヘッダサイズを含めて最大メッセージ長は256MBになり、最大メッセージ長を超える場合はメッセージを分割して送信する必要があります。(使用するMQTTブローカーによってはより最大メッセージ長の制限が厳しいことがあります)
HTTPは、使用するサーバーによって制限が異なりますが、1GBを超えるサイズのデータを送信することができます。
メッセージを分割して送信する場合、送信毎に追加のオーバーヘッドがかかります。そのためMQTTは大容量のデータを送信する用途としてはあまり向いていません。
ネットワーク切断時の比較
MQTTは、メッセージの再送機能やネットワーク切断通知機能があります。
QoS1,2を指定したメッセージの送信に失敗した場合、再接続にメッセージをプロトコルレベルで再送することができます。
Willメッセージを使うことで、ネットワーク切断が発生したことを他のクライアントに伝えることができます。

HTTPは、ネットワーク再接続時に送信に失敗したリクエストが自動的に再送信されることはありません。再送を行うにはユーザーが再度手動でリクエストを送信する必要があります。

IoT端末の中には、端末が移動することでネットワーク環境が安定しないケースがあります。
MQTTはネットワーク切断が発生する環境で利用されることを考慮して設計されているため、プロトコルレベルでネットワーク切断に対するサポートがあります。
プッシュ通知の比較
プッシュ通知とはサーバーがクライアントに対してメッセージを通知することです。
プッシュ通知を使用することでサーバーからクライアントに対して電源のON/OFFや操作切り替えなどの指示を行うことが可能になります。
MQTTは、双方向通信のため、サブスクライブを行うことでサーバーからのプッシュ通知を受け取ることができます。

HTTPは、片方向通信のため、プッシュ通知を行いたい場合はポーリングを行うことで定期的にサーバーからのレスポンスを確認したり、サーバーがレスポンスを返さず待機してレスポンスを返す(CometやServer-Sent Events)を使用する必要があります。

Webブラウザとサーバー間で双方向通信ができるプロトコルとしてWebSocketもあります。
WebSocketはリアルタイム性が求められるビデオ通話やオンラインゲームといったアプリケーションで利用されています。MQTTと組み合わせて使うことも可能です。
セキュリティの比較
MQTTとHTTPはどちらも、SSL/TLSの利用やユーザー認証機能、リソースの認可機能を利用することができます。
MQTTで使用できる詳しいセキュリティについてのコラムは今後追加予定です。
まとめ
MQTT | HTTP | |
通信方式 | Pub/Subモデル(多対多通信) | クライアントサーバーモデル(1対1通信) |
通信時のオーバーヘッド | 小 | 大 |
送信可能な最大データサイズ | 制限あり(最大256MB) | 制限なし(実際は使用するサーバーやブラウザで制限がある) |
ネットワーク切断による再送信 | あり | なし |
プッシュ通知 | 〇 | △(ポーリング等の工夫が必要) |
セキュリティ | 〇 | 〇 |
<MQTTの利用が向いているケース>
・センサー値など比較的小さいデータの送信を頻繫に繰り返すようなケース
ヘッダサイズが小さいため通信毎のオーバーヘッドを抑えることができます。
・不安定なネットワーク環境で使用されるケース
ネットワーク切断時や再接続時のサポートがプロトコルレベルで対応しています。
・多数のクライアントにデータを通知するケース
多対多の通信が容易に行うことができ、効率的に複数のクライアント間でメッセージをやり取りすることができます。
・送信するデータの多くが256MBを超えるケース
データを分割することなく一度に大容量のデータを送信することができます。
・MQTTインフラを新しく用意することが難しいケース
既存のWebサーバーを活用することで新たなサーバーを追加する必要が無くなります。
MQTTはIoT向けに設計されており、端末が利用されるさまざまな環境や状況に役立つ機能を備えています。MQTTを利用する場合、使用するMQTTブローカーによって使える機能が異なるため適切なMQTTブローカーを選択することも重要になります。私たちが提供している「MessagePub+」は、高性能なMQTTブローカーであり、よりさまざまな環境に対応できるように独自機能も備えています。
「MessagePub+」のご紹介
MQTTはテキストデータだけでなく、バイナリデータもメッセージとして送信することができます。
実際にMQTTを活用したIoTのシステムでは、JSONのようなテキストデータや、MessagePackのようなバイナリデータも利用されています。
オージス総研が提供する「MessagePub+」は、MQTT v3.1.1と、最新のv5.0に対応した高性能なMQTTブローカーです。 高い安定性とセキュリティでIoTシステムをしっかり支えます。
「MessagePub+」の資料ダウンロード・お問い合わせ
2025年3月4日
※この記事に掲載されている内容、および製品仕様、所属情報(会社名・部署名)は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。関連サービス
-
IoTメッセージングプラットフォーム「MessagePub+」
MessagePub+ はオージス総研が開発したつなげることに特化した"IoTメッセージングプラットフォーム"です
関連記事一覧
MQTTがIoTに最適な理由とは?知っておくべきMQTTの基本と導入メリット
MQTTとMessagePub+ :ラベル(MessagePub+ )
MQTTとMessagePub+ :トピックの名前と階層化
MQTTとMessagePub+ :トピック分類のまとめ
MQTTとMessagePub+ :応答系トピック
MQTTとMessagePub+ :要求系トピック
MQTTとMessagePub+ :通知系トピック
MQTTとMessagePub+ :トピックの分類
MQTTとMessagePub+ :MQTTを用いたIoTサービスにおけるトピック設計
MQTTとMessagePub+ :MessagePub+ におけるセッション管理
MQTTとMessagePub+ :MQTT活用のコツ