Embed Size (px)
Citation preview
第三回IoT関連技術勉強会データ通信編
田実 誠
• データ通信に関する基礎知識• データ通信の規約（プロトコル）
• HTTPの構造• TCP vs UDP
• IoTにおけるデータ通信の課題• MQTT（詳細は別途）
• Pub/Sub• SORACOM• まとめ
アジェンダ
データ通信の規約（プロトコル）• データ通信の規約をプロトコルと呼ぶ
• ブラウザでURLを叩くとHTTP(S)のプロトコルでサーバと通信を行う• メーラでメールを送信するとメーラがSMTP(S)のプロトコルでサーバと通信を行う• メーラでメールを受信するとメーラがPOP3(S)/IMAP(S)のプロトコルでサーバと通信を行う
• プロトコルとは言語のようなもの。日本人と話すときは日本語で、アメリカ人と話すときは英語でコミュニケーションをとるように、コンピュータもデータ通信を行う場合は、その領域に特化した規約（プロトコル）に則って通信を行う。• 例えばブラウザでWebサイトにアクセスするときはメールアドレスの情報は不要だが、メールを送受
信する場合はメールアドレスの情報は必要。つまり、実現したいことに応じてプロトコルは大幅に変わる
• 種類は色々あるが、結局のところデータ（バイナリ）を送っているだけ。効率良く送りたいから規約（プロトコル）がある。
ちなみに…プロトコルとかデータ通信とか難しいこと言っているように聞こえますが、要は”入出力”です。
ファイルにデータを書き出したり、ファイルからデータを読み込むことはサーバにデータを送信したり、サーバからデータが読みだすことは本質的には同じです。
バスを通じてローカルのディスクに格納されているデータにアクセスするのか、ネットワークケーブルを通じてサーバのディスクに格納されているデータにアクセスするのかの違いでしか無いです。
実際、Linuxではファイル、デバイス、ネットワークからの読み書きに関してはほぼ同じインターフェースで行えます。
最近、プログラミングはフィルタリング、というような話を聞いたことがあるのですが、プログラムは入力に対して何かを出力するモノで、結局のところ”入出力”に帰結します。
ブラウザを立ち上げて、Webサーバにアクセスするのは、サーバに対してデータを入力して、サーバが適切なデータをクライアント（ブラウザ）に対して出力しているだけです。
GET https://www.google.co.jp/ HTTP/1.1Host: www.google.co.jpConnection: keep-aliveUpgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36X-Client-Data: CJa2yQEIprbJAQi/tskBCIqSygEItZTKAQj9lcoBCO6cygE=Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Encoding: gzip, deflate, sdch, brAccept-Language: ja,en;q=0.8,en-US;q=0.6Cookie: GoogleAccountsLocale_session=ja;…
HTTPやPOP3の例USER [email protected]¥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: <[email protected]>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 <[email protected]>; Sat, 11 Jun 2016 23:24:05 +0900 (JST)
(envelope-from [email protected])Received: by mail-oi0-x235.google.com with SMTP id u201so24545619oie.0
for <[email protected]>; Sat, 11 Jun 2016 07:24:05 -0700 (PDT)…
HTTPの構造を少し掘り下げる
HTTPヘッダ TCPヘッダ IPヘッダ Etherヘッダ
HTTPパケット
HTTPボディ
送信元MACアドレス宛先MACアドレス
送信元IPアドレス宛先IPアドレス
ポート番号シーケンス番号
HTTPメソッドヘッダ
データ
誰が送る？誰に送る？
何のソフトウェアに対して送る？データの番号札は？※
Webサーバへの指示（メソッド）データの付加情報
Webサーバに何のデータを送る？
※分割送信時の番号札
HTTPパケット＝TCPパケット
TCPヘッダ IPヘッダ EtherヘッダTCPデータ
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…
IoTにおけるデータ通信の課題• ネットワーク帯域が狭い
• デバイス側（IoT G/W）で利用できるマシンスペックが低い
• セキュリティの為にデータを暗号化して通信をしたいが、暗号化のコストが高い（マシンスペック）
• デバイス側のソースコードは書き換えづらいため、接続先を容易に変更できない
• デバイスが乗っ取られた時の対処方法
• セキュリティ要件として閉域ネットワークにデータを送りたいが、そのためには専用回線を引く必要がある
• 場所の都合上、有線LANを設置しづらい環境である
• 無線LANは事前設定が難しい（セキュリティにも懸念）
HTTP(S)をデバイス側で採用する際の問題点• 汎用的に利用できるが故に、パケットサイズのオーバーヘッドが大きい
• 1文字だけ送信するようなケースでもヘッダの文字列が必ず入る
• HTTP(S)自体は基本的にTCP接続を維持するようなプロトコルではないため、送受信においてTCPの3way handshakeによるオーバーヘッドが生じる※WebSocketやSSE（Server Sent Events）の話は別途
HTTPリクエスト（HTMLくださーい）
HTTPレスポンス（HTML渡しまーす）
SYN（これから通信するよー）
SYN/ACK（OKよろしくー）
ACK（じゃあ次のリクエストで送るよー）
TCPを利用している以上、このオーバーヘッドが必ず存在する（オーバーヘッドを減らすような仕組みは色々あるが、今回は割愛）
MQTT• M2M/IoT用の軽量＝省電力でPub/Subなプロトコル。TCP。固定ヘッダは2Byte。
※ただし軽量なのはMQTTヘッダだけ
• ハブとなるサーバをブローカと呼ぶ
• Publishするサーバ→Publisher、Subscribeするサーバ→Subscriber
• QoS（到達可能性）の制御
• Will（遺言）→任意のPublisher/Subscriberの接続が切れた時にトピックに対して指定のメッセージを送る
• Retain→最後に送ったメッセージを保存（Subscribeする直前のメッセージがわかる）
• 階層構造のTopic
• Username/Passwordの認証機構もあり。MQTTSであればTLSのクライアント証明書による認証も利用可能。
Pub/Sub？データを• 受け渡す方式の一つメルマガで• 例えると、メルマガを発行する人がPublisher、メルマガを受信する人がSubscriber、メールを配信したり、メルマガ登録者を管理するメールサーバをBroker
情報発信者• はPublishして情報が欲しい人だけSubscribeするメルマガ• 登録者はメールを発行する人に関しては知らなくて良いし、メルマガを発行する人もメルマガ登録者を知る必要が無い（メールサーバのみが知っていれば良い）
スケールし• 易い（＝Publisher/Subscriberを増やしやすい）柔軟• なシステム構成（＝送受信側の接続先を柔軟に変更可能）
メルマガの登録をする人→Subscriberメルマガの登録をする→Subscribe
メルマガを発行する人→Publisherメルマガを発行する→Publish
メールサーバ→Message Brokerメルマガ→Topic
HTTPヘッダ TCP IP Ether
各パケットのイメージ
MQTTヘッダ
TCP IP Ether
データ TCP IP Ether
HTTPパケット
MQTTパケット
TCPパケット(Raw)
データ
データ
暗号化されたHTTPパケット（ヘッダ＋データ） TCP IP Ether
HTTPSパケット
SSL/TLS
• プログラマブルなLTE/3Gデータ通信網→Air
• IoT用プロキシ（HTTP[S]/MQTT[S]）→Beam
• 閉域ネットワークとの通信（Amazon VPC）→Canal
• 閉域ネットワークとの通信（専用線）→Direct
• SIM認証を活かした他サービスへの認証の仕組み→Endorse
• 他サービスとの連携（AWS/Azure）→Funnel
SORACOM
IoTのデバイス側が抱える課題を解決するサービス
AirLTE/• 3Gのモバイルデータ通信を提供（スマホのSIMと同じ）
データ• 通信料に応じた従量課金
ユーザコンソール• 、APIを通じたSIMの一括操作SIM• の利用可否（＝通信可否）通信速度•
データ• 使用量の監視Air SIM• のID
カスタム• DNSの設定デバイスの• 活動検知、不正利用検出動的• に登録されるホストの名前解決
出典: https://soracom.jp/iot/
出典: https://soracom.jp/overview/
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/
Endorse
SIM• を通じたSSOTwitter• アカウントでログイン、facebookアカウントでログインと同じように「Air SIMでログイン」を実現したものそもそも• SIMは最初に基地局と認証を行うので、SORACOMにアクセスできる＝認証されている状態であるその• 「認証されている状態」を以って他のサービスにログインする仕組み
これにより• 、Webサービス用の認証情報をSIM以外に持つ必要がなくなるこれまではデバイス• 内に認証情報を別にデータとして持たせていたが、その必要が無くなる
• 高い耐タンパ性 (SIM の内部テータを不正に読み取ったり改さんしたりすることか困難な性質)を備えており、複製を作ることは非常に困難です。SIM • には、International Mobile Subscriber Identity (IMSI) と呼ばれる世界で固有の ID か書き込まれています。IMSI はモバイルネットワーク事業者ごとに発行され、モバイルネットワーク事業者側に登録されていなければ、データ通信は有効となりません。IMSI • を基に通信元を特定し、SIM 内にしかない秘密情報を使った鍵交換を行って認証や通信の暗号化を行います。
出典: https://soracom.jp/services/endorse/
出典: https://soracom.jp/services/endorse/
Endorseの利用フロー
Funnel
• Beamは接続先を変更するだけ（プロキシ）だったが、Funnelは外部サービスとの連携に特化したサービス
• IoT系外部サービス（Amazon Kinesis Stream、Amazon Kinesis Firehose、Microsoft Azure Event Hubs）に対してデータを送信できる• デバイス⇔基地局間のプロトコルはTCP/UDP/HTTP• 現在対応しているサービスは基本的にIoT向けメッセージキューサービス
出典: https://soracom.jp/services/funnel/
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
• 色々とプロトコルはあるけど基本データを送るだけ
• Pub/SubはTopicを介してデータを送受信するメッセージング方式
• MQTTは非力なデバイスが多いM2M/IoT向けのプロトコル
• SORACOMはIoTのデータ通信における様々な課題を解決するサービス• プログラマブルなデータ通信網（Air）• デバイス側の負荷を減らせる各種機能（Beam、Funnel）• デバイス管理側の負荷を減らせる各種機能（Air、Beam、Endorse）• セキュアな接続（Beam、Cannal、Direct）• 外部サービスとの連携（Beam、Endorse、Funnel）
まとめ
• SORACOMホームページhttps://soracom.jp/
• JWT試したい方はこちらでhttps://jwt.io/
• TCP/UDPhttp://www.infraexpert.com/study/tcpip12.html
• MQTThttp://mqtt.org/http://www.slideshare.net/naotomatsumoto/itrc36-20141126nmatsumotov1http://www.slideshare.net/r_rudi/mqtt-meetup-in-tokyo
参考URL
