こんにちは、ソリューションアーキテクトの松永(taketo)です。
IoTはデバイス・ネットワーク・クラウドといった3つの要素で構成されており、それぞれで技術選定をしていきます。
そして、これらを適切に選択し組み合わせることが求められますが、すべてをカバーするのは難しいということでソラコムにご相談いただくことがあります。ネットワークで特に多いのが「どの通信プロトコルを使えばよいの？」というものです。これはIoTデバイスとクラウド、もしくはオンプレミスのシステムとの通信に使用するプロトコルの事を指します。
そこで本ブログでは、検討に上がるプロトコルについて通信量を実測して特長を見つつ、SORACOMを活用することで実現できる通信量の削減方法をご紹介します。
IoTで使える通信プロトコルの種類と特長
IoTはその名の通りインターネット上で動く仕組みであるため、IPベースのプロトコルを扱うことができます。その中でもSORACOMのユースケースとしてよく利用されているプロトコルと、その特徴を整理したのが下の表です。
| 通信プトロコル | 主な特徴 |
|---|---|
| HTTP / HTTPS | TCP/IPモデルにおけるアプリケーション層のプロトコルで非常に一般的。 クライアント(IoTではデバイス)からのリクエストが起点となり、サーバーからの応答をやり取りするプロトコル。IoTにおいてはリクエストの中にセンサーデータを盛り込む設計となる。一問一答式の「ステートレス」であるため実装が容易だが、基本的には都度接続を確立するオーバーヘッドが発生する。KeepAlive等でオーバーヘッドを抑える方法もあるが、クライアント側も対応実装も必要。 TLS(SSL)による通信の暗号化がされている場合は特にHTTPSと称する。 |
| TCP / TCPS(TLS) | HTTPよりも低レイヤーであるトランスポート層のプロトコル。 3ウェイハンドシェイクによる通信確立や再送処理により信頼性の高い通信が可能。ただし、実際の送受信を行うためには上位のアプリケーション層における独自プロトコル設計が必要。 HTTPS同様、TLSによる暗号化がされている場合はTCPSと称する。 |
| UDP / DTLS | TCPと同じくトランスポート層のプロトコル。 TCPにはあった3wayハンドシェイクといった信頼性向上の仕組みは無いが、ストリーム音声といった多少の欠損があったとしても問題にならないデータを低遅延・高効率で送信することに特化。TCP同様にアプリケーション層でのプロトコル実装が必要。 TLSによる暗号化がされている場合はDTLSと称される。 |
| MQTT / MQTTS | アプリケーション層で動作するプロトコル。 HTTPが常にクライアント起点のステートレスであることに対し、MQTTはクライアントとサーバー間であらかじめ接続を確立しておく(ステートフル)。この接続を用いてクライアント起点だけでなくサーバー起点のデータ送信、いわゆる双方向通信が可能。データ送受信には確立済みの接続を再利用するため、通信量がHTTPよりも少量になりやすい。 TLSによる暗号化がされている場合はMQTTSと称する。 |
プロトコルの違いやTLSの有無による通信のオーバーヘッド
プロトコルが異なるということは、データ送受信の仕方が異なる事を意味します。例えば “25” という2桁(=2バイト)の数字を送る際にも、プロトコルによっては総データ量が違います。また、TLSは通信の暗号化によってデータの盗聴や改ざんから保護できますが、鍵情報の交換といったオーバーヘッドが追加で発生します。
特にデータ量を削減したい場合は、利用プロトコルやTLSの有無が大きな影響を与えるわけです。
それではベンチマーク結果を見ていきましょう。
検証環境の解説
検証環境は以下の通りです。
まずサーバー側は、クラウド上にHTTPSで待ち受けるサーバー(今回はAmazon API Gateway (以下API Gateway))を準備し、API GatewayからはAWS Lambdaを起動するように設定しました。
今回は4つの方法(＝プロトコル)で通信してみました。すべての共通点は、IoTデータ通信「SORACOM Air for セルラー」によるLTE通信を利用しています。
1つはデバイスから直接HTTPSで通信する経路です。そして残りの3つの共通点は、データ転送サービス「SORACOM Beam (以下、Beam)」を使い、TLS済プロトコルへの変換処理をさせています。そして、BeamへはHTTP / TCP / UDPそれぞれのプロトコルで入力しています。
計測にはオンデマンドパケットキャプチャ「SORACOM Peek」を利用しました。
「SORACOM Beam」や「SORACOM Peek」
SORACOM Beamはデータ転送サービスです。Beam上で非暗号化プロトコルを暗号化済みプロトコル変換したり、転送先することができます。デバイスの設定や開発・運用工数の削減が見込めるサービスです。
SORACOM Peekはパケットキャプチャサービスです。SORACOM Airを利用している通信に対して、パケットキャプチャを指定でき、Wireshark等のアプリケーションで読み取ることができるpcap形式で結果を取得できます。本件のような実測や、トラブルシューティングに使えるサービスです。
IoTデバイスからSORACOMプラットフォーム(Beam)までの通信について
SORACOM Beamを利用する2~4の3つのケースにおいて、「IoTデバイスからBeamまでの通信は非暗号化なのでは？」と気づかれた方もいらっしゃるのではないでしょうか。
結論から言いますと、特段秘匿性の低いものであればデバイスからSORACOMプラットフォーム(今回はBeam)までは、暗号化せずとも安心して通信いただけます。
これには2つの理由があります。1つ目は、SORACOM Air for セルラーの通信、すなわちLTE/5Gといったセルラー通信自体が暗号化されていることにあります。2つ目は、セルラー通信を取り扱っているMNO事業者の閉じたネットワークとSORACOMプラットフォームは、インターネットを使わずに専用線で接続しています。
「セルラーによる暗号化された通信を、閉じたネットワーク内で扱う。必要があればインターネットに出す仕組み。」それがSORACOMなのです。
ちなみに、SORACOMプラットフォームからクラウドやオンプレミス環境(図中の右側)との通信については、今回利用したBeamといった暗号化プロトコル変換を用いたり、また、SORACOM Canal(Amazon VPC ピアリングやTransit Gateway利用)や、SORACOM Direct(専用線利用)といったネットワークサービスを利用することで、デバイスからクラウドまでをトータルで暗号化もしくは閉域化できます。興味のある方は各サービスをご覧ください。
Wi-Fiも暗号化＋閉じたネットワークに、セキュアリンクサービス「SORACOM Arc」
図中ではWi-Fi通信も「暗号化」となっています。これは、2021年夏にリリースしたサービス「SORACOM Arc」によるものです。SORACOM ArcはWireguardというVPNを用いて、SORACOM Airと同等の仕組みを実現するものです。
データを実際に送ってみる
それぞれのプロトコルの通信を発生させるために curl と nc(netcat) を、以下のように使用しています。すべて {"test":"message"} という18文字(18バイト)を送信しています。
HTTPS (HTTP+TLS) で直接通信
curl -X POST https://***.execute-api.***.amazonaws.com/dev/benchmark -H 'Content-Type: application/json' -d '{"test":"message"}'HTTPと、SORACOM Beamの利用
curl -X POST http://beam.soracom.io:8888/dev/benchmark -H 'Content-Type: application/json' -d '{"test":"message"}'TCPと、SORACOM Beamの利用
nc beam.soracom.io 23080
{"test":"message"}UDPと、SORACOM Beamの利用
nc -u beam.soracom.io 23080
{"test":"message"}1. HTTPS (HTTP+TLS) で直接通信
暗号化を伴ったHTTPS通信のパケットキャプチャです。本検証では、HTTP 2.0/TLSv1.2で通信しています。
以下がコマンドです。
curl -X POST https://***.execute-api.***.amazonaws.com/dev/benchmark -H 'Content-Type: application/json' -d '{"test":"message"}'パケットキャプチャの結果は以下のようになります。
読み方としては、1行が1パケットで一番左がキャプチャ番号になります。そして上から時系列に並んでおり、一番下が最後です。
一部本件とは関係の無いパケットも記録されていますが、注目いただきたいのは灰色と薄紫色の行です。
まずは3ウェイハンドシェイク(キャプチャ番号#8, #9, #11)を行い通信の開始をしています。この動作は、後述するTCPやHTTPと同様です。加えて、TLS化するための鍵交換を行い(キャプチャ番号#20)暗号化が始まっています。そのため {"test":"message"} というデータが送られているのですが、暗号化されているため “何らかのデータ” という意味の Applicaton Data という表記になっています。
次回のデータ送信時には3ウェイハンドシェイク→TLS鍵交換という通信が発生します。特にデータサイズが大きいのが鍵交換で、この通信は2~3KBです。すなわち、 {"test":"message"} という18文字(18バイト)の送信毎に2~3KBが余計に必要なのです。これがオーバーヘッドの正体です。
では、この通信オーバーヘッドは常に発生するのかというと、回避方法もあります。KeepAliveによる接続の再利用やTLS Sessionの再開がそれです。ただし、サーバー側だけでなく、クライアント側の実装も必要です。Linux OS等であれば容易に利用可能ですが、Arduino等のマイコンでKeepAlive等を使う場合は実装が必要な場合もあり、いつもKeepAlive使えるわけではないことにご留意ください。
2. HTTPと、SORACOM Beamを組み合わせた場合
非暗号化のHTTP通信のパケットキャプチャです。本検証ではHTTP 1.1で通信しています。
以下がコマンドとなります。送信先がAPI Gatewayではなく、SORACOM Beamのアドレスになっていることに注目ください。
curl -X POST http://beam.soracom.io:8888/dev/benchmark -H 'Content-Type: application/json' -d '{"test":"message"}'パケットキャプチャの結果は以下のようになります。
HTTPSと同様に、3ウェイハンドシェイク(キャプチャ番号#5, #6, #7)にて通信を開始をしています。TLSの鍵交換が無いため、通信開始直後の #8 でデータ送信(POST という表示)を行い、サーバーからは #10 で402バイトの応答が返ってきています。HTTPSに比べてパケット数も少ないことがおわかりいただけるでしょうか。具体的な比較は後述いたします。
3. TCPと、SORACOM Beamを組み合わせた場合
TCP通信のパケットキャプチャです
以下がコマンドとなります。nc(netcat)というコマンドを利用しています。
nc beam.soracom.io 23080
{"test":"message"}パケットキャプチャの結果は以下のようになります。
一見するとHTTPと大差がありません。3ウェイハンドシェイク(キャプチャ番号#5, #6, #7)にて通信を開始、#8でデータ送信しています。特筆すべきはその後です。HTTPではサーバーから約400バイトの応答が返ってきていましたが、TCPでは合計でも約180バイトと半減しています。もちろん数バイトの違いではありますが、これが数万台・数百万台のIoT機器の通信と考え始めると、インパクトは小さくないと言えるのではないでしょうか。
4. UDPと、SORACOM Beamを組み合わせた場合
UDP通信のパケットキャプチャです
以下がコマンドとなります。nc(netcat)というコマンドを利用しています。
UDPは、これまでのTCPベース通信で発生していた3ウェイハンドシェイクがありません。いきなりデータ送信(キャプチャ番号 #5)を行っています。そのサイズは61バイトです。サーバーからの応答(#6)も96バイトと小さくなっています。非常に軽量なプロトコルであることがわかりますね。
通信量比較
パケットキャプチャした結果から実際の通信量を見てみましょう。
TLS通信をともなうHTTPS通信が他に比べ約7〜19倍の通信をしていることがわかります。これだけ暗号化の通信量は大きいということがわかりますね。HTTP/TCP/UDP通信では、よりシンプルなプロトコルで通信しているに連れて通信量が少なくなっているのがわかります。
まとめと、プロトコル選択によるデータサイズ削減
通信プロトコルについて、その通信量と一緒にご紹介致しました。
IoTはデバイスとクラウドが協調して成り立つ仕組みです。そのため、どうしてもインターネットを経由する通信が発生しうる可能性があるため、「IoTデバイスには暗号化実装が必須なのでは？」というのは、基本的な考え方として間違ってはいません。
また、業務の要件上必要となる場合、例えば、クレジットカード等の情報取り扱いと保護をする基準のPCIデータセキュリティ基準 (PCI DSS)に準拠する場合は、デバイスでの暗号化は不可欠です。
一方で、本ブログでも紹介した通りTLS暗号化は、大きなオーバーヘッドを生みます。これは、通信量と料金に影響するだけでなく、IoTデバイス上での実装工数や、証明書の入れ替えなどの運用負担の増加になります。また、データサイズは通信モジュール(モデム)の消費電力と比例します。すなわち、データサイズが大きければ、それだけ電力消費をするわけです。この点は、特にバッテリー駆動型デバイスで考慮すべき点です。
例えばニチガス様のガスメーター検針IoTデバイス「スペース蛍」は、10年間のバッテリー運用を目指しあらゆる省電力化をしており、データサイズ削減もその1つです。データフォーマットにバイナリ形式を採用して削減していますが、このままではクラウド上でのデータ処理が手間です。そこでバイナリパーサーによるバイナリ→JSON変換を行い、続いてクラウドアダプタサービス「SORACOM Funnel」で希望するクラウドへのデータ送信をしています。SORACOMプラットフォームの活用で、手間をかけずにデータサイズ削減とクラウド上でのデータ処理を両立しているわけです。
今回はMQTT(S)の検証は行いませんでしたが、MQTTS(MQTT+TLS)においては、HTTPSと同様に鍵交換のオーバーヘッドが発生することは確実です。一方でHTTPSとは異なりMQTTは一度確立した接続を使用し続けるため、以降の通信はほとんどオーバーヘッドが発生しないと考えられます。この辺りは、別の機会でご紹介できればと思います。
SORACOMプラットフォームが「デバイスとクラウドの仲立ちに」
SORACOMプラットフォームが提供する通信自体の暗号化と閉域網の仕組みのご理解と、皆様のIoTの業務要件を照らし合わせていただいたうえで、デバイスから暗号化が不要だと判断できた場合は、HTTP/TCP/UDPといった通信と、SORACOM Beamをはじめとした「SORACOMのアプリケーションサービス」との組み合わせをおススメいたします。
また、バイナリパーサーやインラインプロセッシング「SORACOM Orbit」の活用で、ニチガス様の例のようにデータフォーマットにまで踏み込んだ削減が可能です。
クラウド連携については、AWS LambdaやGoogle Cloud Functionなど関数サービス(FaaS)の場合はSORACOM Funkが、同じくAmazon Kinesis Data StreamsやAzure Event HubといったPaaS/SaaS連携にはSORACOM Funnelの利用で、SORACOM Beam以上に手軽にプロトコル変換ができます。ぜひご利用ください。
SORACOM Air for セルラーによる暗号化/閉域網はSORACOMプラットフォームまでです。
SORACOMのアプリケーションサービスを使わずに、SORACOMプラットフォームの先のインターネットと通信した場合は、インターネット上のデータは非暗号化です。よって、非暗号化プロトコルを選択する場合は、SORACOM Beam等のアプリケーションサービスと組み合わせて使うことを強く推奨します。
さいごに
最後まで読んでいただき、有難う御座いました！
HTTPプロトコルはアップデートされており、v3では `QUIC`というプロトコルが採用されUDP通信を元にした通信を行います。今後の進化に期待ですね。
今年もSORACOM Discoveryの開催がいよいよ近くなってきました。今年は、7/6 ~ 7/7でオンライン開催されます！皆さまのご参加お待ちしております！
― ソラコム松永(taketo)