データを送信するときの実際の通信量は、データ本体だけでは決まりません。接続確立、Transport Layer Security (TLS) の鍵交換、プロトコルのヘッダー、接続先からの応答も通信量に含まれます。特にバッテリー駆動のデバイスや多数デバイスでは、この差が通信料金、電力消費、証明書運用、ファームウェア実装の負担に影響します。
このページは、データをクラウドや自社システムへ送るときに、通信量とデバイス負荷を抑えながら送信方式を選ぶための設計ガイドです。18 バイトのデータを送信した実測例は、プロトコルごとのオーバーヘッドを確認するための検証条件として扱います。実測例をもとに、Hypertext Transfer Protocol Secure (HTTPS)、HTTP、TCP、UDP の通信量の違いと、SORACOM Beam やバイナリパーサーを使うときの判断ポイントを整理します。
このページが役立つケース
データ送信の設計で次のような課題がある場合に役立ちます。
- データを送るたびに、データ本体以外の接続確立や暗号化の通信量が大きくなっている。
- バッテリー駆動のデバイスで、通信量、通信時間、電力消費を抑えたい。
- 多数デバイスから定期送信するときに、1 回あたりの通信量を小さくしたい。
- デバイス側に TLS や証明書管理の実装を増やすべきか判断したい。
- SORACOM Beam を使い、デバイス側は軽いプロトコルで送信し、SORACOM から先を HTTPS や Message Queuing Telemetry Transport over TLS (MQTTS) で保護したい。
- バイナリ形式で送信し、クラウド側では JavaScript Object Notation (JSON) 形式として扱いたい。
先に確認すること
通信量だけを見てプロトコルを選ぶと、セキュリティ要件や到達確認の設計を見落とします。最初に次の 3 点を確認します。
| 確認すること | 判断のしかた |
|---|---|
| デバイスから接続先まで End-to-End (E2E) で暗号化する必要があるか | 業務要件や規格要件で必要な場合は、デバイス側で TLS などの暗号化を実装します。SORACOM Beam でデバイス側の暗号化を省略する構成にはしません。 |
| デバイスから SORACOM までと、SORACOM から先を分けて保護できるか | SORACOM Air for セルラーでは、デバイスから SORACOM までの通信はセルラー通信の暗号化と閉域網で扱われます。SORACOM から先は、SORACOM Beam、SORACOM Canal、SORACOM Direct などで保護します。 |
| 送ったデータの到達確認や再送が必要か | 到達確認や再送が必要な場合は、HTTP / TCP / MQTT を含めて設計します。UDP を使う場合は、必要な確認や再送をアプリケーション側で設計します。 |
実測値は検証条件に依存します
このページの通信量は、特定の検証構成で 18 バイトのデータを送ったときの値です。TLS のバージョン、HTTP のバージョン、接続先の応答、SORACOM Beam の設定、プラットフォームバージョン、データ形式によって通信量は変わります。方式の優劣を固定値として扱わず、実際の構成では SORACOM Peek などで確認してください。
方式を選ぶときの考え方
まずは、何を優先するかで候補を絞ります。
| 方式 | 向いているケース | 主な注意点 |
|---|---|---|
| HTTPS 直接通信 | デバイスから接続先まで暗号化が必要な場合。既存の HTTPS API に直接送信したい場合。 | 接続ごとに TCP 接続確立と TLS 鍵交換が発生し、データ本体に対するオーバーヘッドが大きくなりやすい。 |
| HTTP + SORACOM Beam | デバイス側の実装を簡単にし、SORACOM から先を HTTPS で保護したい場合。 | HTTP ヘッダーと応答の通信量は残る。SORACOM から先の転送設定を正しく構成する必要がある。 |
| TCP + SORACOM Beam | HTTP より送受信の形式を小さくしたい場合。デバイス側で送信形式を制御できる場合。 | データの区切りや形式を設計する必要がある。SORACOM Binary Format v1 やバイナリパーサーを使う場合は対応条件を確認する。 |
| UDP + SORACOM Beam | 独立したデータを軽く送りたい場合。アプリケーション側で必要な到達確認を設計できる場合。 | UDP 自体には接続確立、再送、順序制御がない。Beam の UDP → HTTP/HTTPS では 1 つの UDP データグラムを 1 リクエストとして転送する。 |
| MQTT / MQTTS | 接続を維持し、双方向性や継続的な Publish / Subscribe が必要な場合。 | 初回接続では TLS 鍵交換が発生する。接続を維持できる構成か、切断時の再接続方針を確認する。 |
検証構成
検証では、{"test":"message"} という 18 バイトのデータを、SORACOM Air for セルラーの 4G (LTE) 通信で送信し、SORACOM Peek でパケットをキャプチャして通信量を確認しています。接続先は Amazon API Gateway と Amazon Web Services (AWS) Lambda です。
検証した経路は次の 4 つです。
- デバイスから Amazon API Gateway へ HTTPS で直接送信する。
- デバイスから SORACOM Beam へ HTTP で送信し、SORACOM Beam から Amazon API Gateway へ HTTPS で転送する。
- デバイスから SORACOM Beam へ TCP で送信し、SORACOM Beam から Amazon API Gateway へ HTTPS で転送する。
- デバイスから SORACOM Beam へ UDP で送信し、SORACOM Beam から Amazon API Gateway へ HTTPS で転送する。
この検証は、コマンドラインツールの curl と nc を使って同じデータを送信し、プロトコルごとの通信量の差を確認したものです。ここで重要なのはコマンドそのものではなく、同じデータでも接続方式と暗号化の位置によって通信量が変わることです。
SORACOM までの通信保護
SORACOM Air for セルラーを利用するデバイスから SORACOM までの通信は、セルラー通信の暗号化と、通信事業者の閉じたネットワークおよび SORACOM までの専用線接続で扱われます。この保護区間を利用すると、デバイスから SORACOM Beam までは HTTP、TCP、UDP、MQTT のような軽いプロトコルで送り、SORACOM Beam から転送先までを HTTPS や MQTTS で暗号化する構成を取れます。
SORACOM から先のインターネット区間は別に保護する
SORACOM Air for セルラーによる暗号化と閉域網は、デバイスから SORACOM までの区間です。SORACOM のアプリケーションサービスを使わずに、SORACOM から先のインターネット区間で非暗号化プロトコルのまま接続先へ通信すると、その区間は非暗号化になります。非暗号化プロトコルを選ぶ場合は、SORACOM Beam などのアプリケーションサービスと組み合わせて、SORACOM から先を暗号化してください。
Wi-Fi や有線ネットワークから SORACOM の仕組みに接続する場合は、SORACOM Arc による Virtual Private Network (VPN) 接続も選択肢になります。
実測結果
同じ 18 バイトのデータでも、接続確立、暗号化、応答の違いによって通信量は大きく変わります。
| 方式 | 実測通信量 | 読み取り方 |
|---|---|---|
| HTTPS 直接通信 | 10,664 バイト | TCP の 3 ウェイハンドシェイクに加えて、TLS 鍵交換が発生する。 |
| HTTP + SORACOM Beam | 1,513 バイト | デバイス側では TLS 鍵交換が発生しない。HTTP のリクエストとレスポンスのヘッダーは残る。 |
| TCP + SORACOM Beam | 1,153 バイト | HTTP より応答サイズを小さくできる。ただし、データ形式の設計が必要になる。 |
| UDP + SORACOM Beam | 560 バイト | TCP の 3 ウェイハンドシェイクがない。到達確認や再送は別途設計する。 |
この検証では、HTTPS 直接通信は HTTP、TCP、UDP と比べて約 7〜19 倍の通信量になっています。送信データ本体が 18 バイトでも、TLS 鍵交換や接続確立の通信が加わるためです。
HTTPS 直接通信
HTTPS 直接通信では、TCP の 3 ウェイハンドシェイクのあとに TLS 鍵交換が行われます。この検証では HTTP/2 と TLS 1.2 で通信しています。パケットキャプチャ上では、送信データ本体は暗号化されるため、内容ではなく Application Data として見えます。
TLS 鍵交換は 2,000〜3,000 バイト程度の通信量になります。データを送るたびに新しい接続を作ると、データ本体よりも接続と暗号化のための通信量が大きくなる場合があります。
Keep-Alive による接続再利用や TLS セッション再開を使うと、このオーバーヘッドを抑えられる場合があります。ただし、サーバー側だけでなくデバイス側の実装も必要です。Linux を搭載したデバイスでは扱いやすい場合がありますが、マイクロコントローラーを使うデバイスでは実装やライブラリの制約を確認してください。
HTTP と SORACOM Beam
HTTP と SORACOM Beam を組み合わせると、デバイスから SORACOM Beam までは HTTP で送信し、SORACOM Beam が転送先へ HTTPS で送信します。デバイス側では TLS 鍵交換が発生しないため、HTTPS 直接通信よりパケット数と通信量を減らせます。
HTTP は扱いやすい一方で、HTTP ヘッダーやサーバー応答の分だけ通信量が発生します。実装のしやすさと通信量のバランスを取りたい場合に向いています。
TCP と SORACOM Beam
TCP と SORACOM Beam を組み合わせると、デバイスから SORACOM Beam までは TCP で送信し、SORACOM Beam が転送先へ HTTP または HTTPS で転送します。HTTP と同じく TCP の 3 ウェイハンドシェイクは発生しますが、HTTP リクエストとして送るよりデバイス側の送受信を小さくできます。
TCP を選ぶ場合は、データの区切りや形式をアプリケーション側で設計します。SORACOM Binary Format v1 やバイナリパーサーを使う場合は、対応しているエントリポイント、データの扱い、データ形式を確認してください。
UDP と SORACOM Beam
UDP と SORACOM Beam を組み合わせると、TCP の 3 ウェイハンドシェイクがありません。この検証では、デバイスから送信した UDP パケットは 61 バイト、応答は 96 バイトで、4 方式の中で通信量が最小でした。
ただし、UDP は軽い代わりに、再送、順序制御、到達確認を持ちません。また、SORACOM Beam の UDP → HTTP/HTTPS エントリポイントでは、1 つの UDP データグラムを 1 つの HTTP / HTTPS リクエストとして転送します。現行仕様では、UDP の内容は Base64 にエンコードされ、JSON 形式のリクエストボディとして転送されます。
そのため、UDP は「独立したデータを軽く送る」用途では候補になりますが、到達、順序、欠損時の再送が要件になる用途では、アプリケーション側の設計が必要です。
データ形式を小さくする
プロトコルだけでなく、データ形式も通信量に影響します。JSON 形式は扱いやすい一方で、キー名や記号が通信量に含まれます。バッテリー駆動のデバイスや多数デバイスでは、デバイスからはバイナリ形式で送り、SORACOM 側で JSON 形式に変換する構成も有効です。
バイナリパーサー は、固定形式のバイナリデータを JSON 形式へ変換し、SORACOM Beam、SORACOM Funnel、SORACOM Funk、SORACOM Harvest Data へ渡す機能です。現行仕様では、SORACOM Beam と組み合わせる場合、TCP → HTTP/HTTPS と UDP → HTTP/HTTPS のプロトコル変換で利用できます。SORACOM Funnel や SORACOM Harvest Data と組み合わせる場合は、TCP または UDP の転送で利用します。
任意の変換処理が必要な場合や、バイナリパーサーの固定形式だけでは足りない場合は、SORACOM Orbit も検討します。
SORACOM Beam、SORACOM Funnel、SORACOM Funk の使い分け
SORACOM Beam は、任意の HTTP / HTTPS サーバー、TCP / TCPS サーバー、MQTT / MQTTS ブローカーなどへ転送する場合に使います。デバイス側の軽量な通信を SORACOM 側で暗号化し、必要に応じて認証情報やヘッダーを SORACOM 側で扱えます。
接続先が Function as a Service (FaaS) であれば SORACOM Funk を、対応する Platform as a Service (PaaS) や Software as a Service (SaaS) であれば SORACOM Funnel を検討します。デバイス側で接続先ごとの認証処理を増やさずに、SORACOM 側の設定でクラウド連携しやすくなります。
判断ポイント
- デバイス側で TLS が必須かどうかを最初に確認する。
- デバイス側の TLS が必須でなければ、SORACOM Beam で TLS とプロトコル変換を担う構成を検討する。
- 実装しやすさを優先するなら HTTP、通信量をさらに抑えたいなら TCP や UDP を候補にする。
- UDP を選ぶ場合は、到達確認、再送、順序制御をどこで扱うかを決める。
- TCP を選ぶ場合は、データの区切りと形式をどう扱うかを決める。
- 接続を維持できる用途では、MQTT / MQTTS のようなステートフルな方式も検討する。
- データ本体を小さくしたい場合は、バイナリパーサーや SORACOM Orbit を検討する。
- 方式を決めたら、SORACOM Peek などで実際の通信量を確認する。
関連する SORACOM ドキュメント
- データ転送と TLS オフロード: SORACOM Beam
- Beam のエントリポイント設定: Unified Endpoint のエントリポイント一覧
- データ形式の変換: バイナリパーサー
- 任意のデータ変換: SORACOM Orbit
- 対応クラウドサービスへの連携: SORACOM Funnel
- Function as a Service (FaaS) への連携: SORACOM Funk
- パケットキャプチャ: SORACOM Peek
- セルラー以外のネットワークから SORACOM へ接続する: SORACOM Arc
- 通信量、接続時間、プロトコルの設計: 接続と通信の設計
- データ送信の保護方式: データ送信を暗号化または閉域接続で保護する
元記事・元資料
このページは、以下の記事・資料をもとにしています。
正確な内容や最新の情報を確認するときは、元の記事・資料もあわせて参照してください。
- SORACOM 公式ブログ: 実測！IoT通信プロトコルのオーバーヘッドの実態と削減方法