MQTTとHTTPの違い。IoT開発に使用するプロトコルはどのように選ぶべきか?

MQTTとHTTPの特徴

MQTTプロトコル

非常に軽量で効率的なメッセージングプロトコルです。
配信するメッセージの重要性によってQoSレベルを変更することで、ネットワークが不安定な環境でも確実にメッセージを届けることが可能です。これらの特性から移動体端末やネットワーク帯域幅、リソースが限られたIoTの分野での利用が広がっています。

HTTPプロトコル

HTMLなどの文書を転送することを目的として設計されたプロトコルです。
MQTTと違いステートレスなプロトコルなので、セッションは保持されず各リクエストは独立して処理が行われます。
セッションを管理する必要がある場合は、Cookieなどを使用することでステートフルな振る舞いを実現することができます。WebブラウザやWebアプリケーションにおいて広く利用されていますが、IoTの分野でも普及率やアプリケーションとの互換性などから使用されることがあります。

MQTTとHTTPの比較

通信方式の比較

MQTTは、Pub/Subモデルが採用されており、次のような特徴があります。
・クライアントとブローカー間は常時接続でリアルタイムに相互通信を行うことができます。
・複数のクライアントが共通のトピックをサブスクライブすることで、多対多の通信を簡単に行うことができます。

7894_mqtt.png

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

7894_http.png

通信データの比較

ヘッダサイズ

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

7894_header.png

MQTTはヘッダサイズが小さいため、各通信におけるオーバーヘッドを抑えることができます。全体の通信データ量が減少することでネットワーク帯域を効率的に利用できるようになり、送受信に必要なデバイスの電力消費も抑えることができます。

最大送信データサイズ

MQTTは、ヘッダサイズを含めて最大メッセージ長は256MBになり、最大メッセージ長を超える場合はメッセージを分割して送信する必要があります。(使用するMQTTブローカーによってはより最大メッセージ長の制限が厳しいことがあります)
HTTPは、使用するサーバーによって制限が異なりますが、1GBを超えるサイズのデータを送信することができます。
メッセージを分割して送信する場合、送信毎に追加のオーバーヘッドがかかります。そのためMQTTは大容量のデータを送信する用途としてはあまり向いていません。

ネットワーク切断時の比較

MQTTは、メッセージの再送機能やネットワーク切断通知機能があります。
QoS1,2を指定したメッセージの送信に失敗した場合、再接続にメッセージをプロトコルレベルで再送することができます。
Willメッセージを使うことで、ネットワーク切断が発生したことを他のクライアントに伝えることができます。

7894_mqtt_disconnect.png

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

7894_http_disconnect.png

IoT端末の中には、端末が移動することでネットワーク環境が安定しないケースがあります。
MQTTはネットワーク切断が発生する環境で利用されることを考慮して設計されているため、プロトコルレベルでネットワーク切断に対するサポートがあります。

プッシュ通知の比較

プッシュ通知とはサーバーがクライアントに対してメッセージを通知することです。
プッシュ通知を使用することでサーバーからクライアントに対して電源のON/OFFや操作切り替えなどの指示を行うことが可能になります。

MQTTは、双方向通信のため、サブスクライブを行うことでサーバーからのプッシュ通知を受け取ることができます。

7894_push1.png

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

7894_push2.png

Webブラウザとサーバー間で双方向通信ができるプロトコルとしてWebSocketもあります。
WebSocketはリアルタイム性が求められるビデオ通話やオンラインゲームといったアプリケーションで利用されています。MQTTと組み合わせて使うことも可能です。

セキュリティの比較

MQTTとHTTPはどちらも、SSL/TLSの利用やユーザー認証機能、リソースの認可機能を利用することができます。
MQTTで使用できる詳しいセキュリティについてのコラムは今後追加予定です。

まとめ

MQTT HTTP
通信方式 Pub/Subモデル(多対多通信) クライアントサーバーモデル(1対1通信)
通信時のオーバーヘッド
送信可能な最大データサイズ 制限あり(最大256MB) 制限なし(実際は使用するサーバーやブラウザで制限がある)
ネットワーク切断による再送信 あり なし
プッシュ通知 △(ポーリング等の工夫が必要)
セキュリティ

<MQTTの利用が向いているケース>

・センサー値など比較的小さいデータの送信を頻繫に繰り返すようなケース
 ヘッダサイズが小さいため通信毎のオーバーヘッドを抑えることができます。
・不安定なネットワーク環境で使用されるケース
 ネットワーク切断時や再接続時のサポートがプロトコルレベルで対応しています。
・多数のクライアントにデータを通知するケース
 多対多の通信が容易に行うことができ、効率的に複数のクライアント間でメッセージをやり取りすることができます。

<HTTPの利用が向いているケース>

・送信するデータの多くが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+」の資料ダウンロード・お問い合わせ

資料ダウンロード

「MessagePub+」の特徴のポイントや活用シーン例を簡単にご紹介しています。
無料トライアル

無料トライアルで「MessagePub+」の機能をぜひご確認ください。

2025年3月4日

※この記事に掲載されている内容、および製品仕様、所属情報(会社名・部署名)は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。

関連サービス