社内勉強会の資料。 主にMQTTとSORACOMの話。

1. 第三回IoT関連技術勉強会
データ通信編
田実 誠

2. • データ通信に関する基礎知識
• データ通信の規約（プロトコル）
• HTTPの構造
• TCP vs UDP
• IoTにおけるデータ通信の課題
• MQTT（詳細は別途）
• Pub/Sub
• SORACOM
• まとめ
アジェンダ

3. データ通信の規約（プロトコル）
• データ通信の規約をプロトコルと呼ぶ
• ブラウザでURLを叩くとHTTP(S)のプロトコルでサーバと通信を行う
• メーラでメールを送信するとメーラがSMTP(S)のプロトコルでサーバと通信を行う
• メーラでメールを受信するとメーラがPOP3(S)/IMAP(S)のプロトコルでサーバと通信を行う
• プロトコルとは言語のようなもの。日本人と話すときは日本語で、アメリカ人と話すときは英語でコミュニ
ケーションをとるように、コンピュータもデータ通信を行う場合は、その領域に特化した規約（プロトコ
ル）に則って通信を行う。
• 例えばブラウザでWebサイトにアクセスするときはメールアドレスの情報は不要だが、メールを送受
信する場合はメールアドレスの情報は必要。
つまり、実現したいことに応じてプロトコルは大幅に変わる
• 種類は色々あるが、結局のところデータ（バイナリ）を送っているだけ。効率良く送りたいから規約
（プロトコル）がある。

4. ちなみに…
プロトコルとかデータ通信とか難しいこと言っているように聞こえますが、要は”入出力”です。
ファイルにデータを書き出したり、ファイルからデータを読み込むことは
サーバにデータを送信したり、サーバからデータが読みだすことは本質的には同じです。
バスを通じてローカルのディスクに格納されているデータにアクセスするのか、
ネットワークケーブルを通じてサーバのディスクに格納されているデータにアクセスするのかの違いでしか無いです。
実際、Linuxではファイル、デバイス、ネットワークからの読み書きに関してはほぼ同じインターフェースで行えます。
最近、プログラミングはフィルタリング、というような話を聞いたことがあるのですが、プログラムは入力に対して何かを出
力するモノで、結局のところ”入出力”に帰結します。
ブラウザを立ち上げて、Webサーバにアクセスするのは、サーバに対してデータを入力して、サーバが適切なデータをク
ライアント（ブラウザ）に対して出力しているだけです。

5. GET https://www.google.co.jp/ HTTP/1.1
Host: www.google.co.jp
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84
Safari/537.36
X-Client-Data:
CJa2yQEIprbJAQi/tskBCIqSygEItZTKAQj9lcoBCO6cygE=
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,
*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: ja,en;q=0.8,en-US;q=0.6
Cookie: GoogleAccountsLocale_session=ja;…
HTTPやPOP3の例
USER test@hoge.fuge.com¥r¥n
+OK Password required.¥r¥n
PASS fuga1234¥r¥n
+OK logged in.¥r¥n
STAT¥r¥n
+OK 1 2426¥r¥n
RETR 1¥r¥n
+OK 2426 octets follow.
Return-Path: <mtajitsu@uhuru.jp>
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com
[IPv6:2607:f8b0:4003:c06::235])
by xxxxx.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id
u5BEO40F007925
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
verify=FAIL)
for <test@hoge.fuga.com>; Sat, 11 Jun 2016 23:24:05 +0900
(JST)
(envelope-from mtajitsu@uhuru.jp)
Received: by mail-oi0-x235.google.com with SMTP id u201so24545619oie.0
for <test@hoge.fuga.com>; Sat, 11 Jun 2016 07:24:05 -0700 (PDT)
…

6. HTTPの構造を少し掘り下げる
HTTPヘッダ TCPヘッダ IPヘッダ Etherヘッダ
HTTPパケット
HTTPボディ
送信元MACアドレス
宛先MACアドレス
送信元IPアドレス
宛先IPアドレス
ポート番号
シーケンス番号
HTTPメソッド
ヘッダ
データ
誰が送る？
誰に送る？
何のソフトウェアに対して送る？
データの番号札は？※
Webサーバへの指示（メソッド）
データの付加情報
Webサーバに何のデータを送る？
※分割送信時の番号札
HTTPパケット＝TCPパケット
TCPヘッダ IPヘッダ EtherヘッダTCPデータ

7. TCP vs UDP
TCP
• データを送信したら、必ず相手がデータを受け取ったかどうかを確認する（確認応答）
• 順序制御、再送制御、ウィンドウ制御、フロー制御
• コネクション確立のためのオーバーヘッド(3way handshake)
• 確実にデータを送受信する必要がある信頼性が求められる用途
• HTTP(S)/SMTP(S)/POP3/IMAP/SMB/CIFS/MQTT(S)/(S)FTP(S)/SSH/Telnet
/RDBMSのプロトコル…
UDP
• データ投げっぱなし。送信先がデータを受け取ったかどうかは無視。
• ちょっとくらいデータ欠損が発生しても問題ない速度重視な用途（動画）あるいは少量の
データしか送らないもの（DNS、NTP等）
• VoIP/DNS/NTP/RTP/RTSP/RTMP…

8. IoTにおけるデータ通信の課題
• ネットワーク帯域が狭い
• デバイス側（IoT G/W）で利用できるマシンスペックが低い
• セキュリティの為にデータを暗号化して通信をしたいが、暗号化のコストが高い（マシンスペック）
• デバイス側のソースコードは書き換えづらいため、接続先を容易に変更できない
• デバイスが乗っ取られた時の対処方法
• セキュリティ要件として閉域ネットワークにデータを送りたいが、そのためには専用回線を引く必要がある
• 場所の都合上、有線LANを設置しづらい環境である
• 無線LANは事前設定が難しい（セキュリティにも懸念）

9. HTTP(S)をデバイス側で採用する際の問題点
• 汎用的に利用できるが故に、パケットサイズのオーバーヘッドが大きい
• 1文字だけ送信するようなケースでもヘッダの文字列が必ず入る
• HTTP(S)自体は基本的にTCP接続を維持するようなプロトコルではないため、送受信においてTCPの
3way handshakeによるオーバーヘッドが生じる
※WebSocketやSSE（Server Sent Events）の話は別途
HTTPリクエスト（HTMLくださーい）
HTTPレスポンス（HTML渡しまーす）
SYN（これから通信するよー）
SYN/ACK（OKよろしくー）
ACK（じゃあ次のリクエストで送るよー）
TCPを利用している以上、このオーバーヘッドが
必ず存在する
（オーバーヘッドを減らすような仕組みは色々
あるが、今回は割愛）

10. MQTT
• M2M/IoT用の軽量＝省電力でPub/Subなプロトコル。TCP。固定ヘッダは2Byte。
※ただし軽量なのはMQTTヘッダだけ
• ハブとなるサーバをブローカと呼ぶ
• Publishするサーバ→Publisher、Subscribeするサーバ→Subscriber
• QoS（到達可能性）の制御
• Will（遺言）
→任意のPublisher/Subscriberの接続が切れた時にトピックに対して指定のメッセージを送る
• Retain
→最後に送ったメッセージを保存（Subscribeする直前のメッセージがわかる）
• 階層構造のTopic
• Username/Passwordの認証機構もあり。MQTTSであればTLSのクライアント証明書による認証も利用可能。

11. Pub/Sub？
データを• 受け渡す方式の一つ
メルマガで• 例えると、メルマガを発行する人がPublisher、メルマガを受信する人がSubscriber、メールを配
信したり、メルマガ登録者を管理するメールサーバをBroker
情報発信者• はPublishして情報が欲しい人だけSubscribeする
メルマガ• 登録者はメールを発行する人に関しては知らなくて良いし、メルマガを発行する人もメルマガ登
録者を知る必要が無い（メールサーバのみが知っていれば良い）
スケールし• 易い（＝Publisher/Subscriberを増やしやすい）
柔軟• なシステム構成（＝送受信側の接続先を柔軟に変更可能）
メルマガの登録をする人→Subscriber
メルマガの登録をする→Subscribe
メルマガを発行する人→Publisher
メルマガを発行する→Publish
メールサーバ→Message Broker
メルマガ→Topic

12. HTTPヘッダ TCP IP Ether
各パケットのイメージ
MQTT
ヘッダ
TCP IP Ether
データ TCP IP Ether
HTTPパケット
MQTTパケット
TCPパケット(Raw)
データ
データ
暗号化されたHTTPパケット（ヘッダ＋データ） TCP IP Ether
HTTPSパケット
SSL/TLS

13. • プログラマブルなLTE/3Gデータ通信網→Air
• IoT用プロキシ（HTTP[S]/MQTT[S]）→Beam
• 閉域ネットワークとの通信（Amazon VPC）→Canal
• 閉域ネットワークとの通信（専用線）→Direct
• SIM認証を活かした他サービスへの認証の仕組み→Endorse
• 他サービスとの連携（AWS/Azure）→Funnel
SORACOM
IoTのデバイス側が抱える課題を解決するサービス

14. Air
LTE/• 3Gのモバイルデータ通信を提供（スマホのSIMと同じ）
データ• 通信料に応じた従量課金
ユーザコンソール• 、APIを通じたSIMの一括操作
SIM• の利用可否（＝通信可否）
通信速度•
データ• 使用量の監視
Air SIM• のID
カスタム• DNSの設定
デバイスの• 活動検知、不正利用検出
動的• に登録されるホストの名前解決
出典: https://soracom.jp/iot/
出典: https://soracom.jp/overview/

15. Beam
• 暗号化をSORACOM側でやってくれる仕組み
＝プロトコル変換
• HTTP→HTTPS
• MQTT→MQTTS
• TCP→HTTPS
• UDP→HTTPS
• 接続先もプロキシ側で変換することができる
例）beam.soracom.io→ap.salesforce.com
• グループ単位での設定（コンソール／API）
出典: https://soracom.jp/services/beam/
出典: https://soracom.jp/services/beam/

16. Endorse
SIM• を通じたSSO
Twitter• アカウントでログイン、facebookアカウントでログインと同じように「Air SIMでログイ
ン」を実現したもの
そもそも• SIMは最初に基地局と認証を行うので、SORACOMにアクセスできる＝認証されて
いる状態である
その• 「認証されている状態」を以って他のサービスにログインする仕組み
これにより• 、Webサービス用の認証情報をSIM以外に持つ必要がなくなる
これまではデバイス• 内に認証情報を別にデータとして持たせていたが、その必要が無くなる
• 高い耐タンパ性 (SIM の内部データを不正に読み取ったり改ざんしたりすることが困難な性質)を備えて
おり、複製を作ることは非常に困難です。
SIM• には、International Mobile Subscriber Identity (IMSI) と呼ばれる世界で固有の ID が書き込まれ
ています。IMSI はモバイルネットワーク事業者ごとに発行され、モバイルネットワーク事業者側に登録
されていなければ、データ通信は有効となりません。
IMSI• を基に通信元を特定し、SIM 内にしかない秘密情報を使った鍵交換を行って認証や通信の暗号化を
行います。
出典: https://soracom.jp/services/endorse/

17. 出典: https://soracom.jp/services/endorse/
Endorseの利用フロー

18. Funnel
• Beamは接続先を変更するだけ（プロキシ）だったが、Funnelは外部サービスとの連携に特化したサービス
• IoT系外部サービス（Amazon Kinesis Stream、Amazon Kinesis Firehose、Microsoft Azure
Event Hubs）に対してデータを送信できる
• デバイス⇔基地局間のプロトコルはTCP/UDP/HTTP
• 現在対応しているサービスは基本的にIoT向けメッセージキューサービス
出典: https://soracom.jp/services/funnel/

19. IoTにおけるデータ通信の課題の解決
ネットワーク• 帯域が狭い
→MQTT/SORACOM Air(LTE/3G)
デバイス• 側（IoT G/W）で利用できるマシンスペックが低い
→MQTT/SORACOM Air
セキュリティの• 為にデータを暗号化して通信をしたいが、暗号化のコストが高い（マシンスペック）
→SORACOM Beam/Canal/Direct
デバイス• 側のソースコードは書き換えづらいため、接続先を容易に変更できない
→SORACOM Beam/Funnel
デバイスが• 乗っ取られた時の対処方法
→SORACOM Air
セキュリティ• 要件として閉域ネットワークにデータを送りたいが、そのためには専用回線を引く必要がある
→SORACOM Canal/Direct
場所• の都合上、有線LANを設置しづらい環境である
→SORACOM Air
無線• LANは事前設定が難しい（セキュリティにも懸念）
→SORACOM Air

20. • 色々とプロトコルはあるけど基本データを送るだけ
• Pub/SubはTopicを介してデータを送受信するメッセージング方式
• MQTTは非力なデバイスが多いM2M/IoT向けのプロトコル
• SORACOMはIoTのデータ通信における様々な課題を解決するサービス
• プログラマブルなデータ通信網（Air）
• デバイス側の負荷を減らせる各種機能（Beam、Funnel）
• デバイス管理側の負荷を減らせる各種機能（Air、Beam、Endorse）
• セキュアな接続（Beam、Cannal、Direct）
• 外部サービスとの連携（Beam、Endorse、Funnel）
まとめ

21. • SORACOMホームページ
https://soracom.jp/
• JWT試したい方はこちらで
https://jwt.io/
• TCP/UDP
http://www.infraexpert.com/study/tcpip12.html
• MQTT
http://mqtt.org/
http://www.slideshare.net/naotomatsumoto/itrc36-20141126nmatsumotov1
http://www.slideshare.net/r_rudi/mqtt-meetup-in-tokyo
参考URL