UDP→HTTPS変換をお願いするまでのまとめ
自己紹介
WHILLという会社でパーソナルモビリティつくってます。Co-Founderの福岡です。
基本的には組み込み系のソフトウェアエンジニアですが、電気回路から部品調達、法規制、知財や細胞培養まで大抵のことは頑張ります。
ブログも書いたこと無いのですが、SORACOMさんからの期待に頑張って応えてみようという試みです。
SORACOMシステムを使う理由
そもそも何でSORACOMさんのシステムを使う必要が出たかと言いますと、主にセキュリティです。
これからの計画になりますが、今後WHILLは3Gなんかのセルラー通信で直接インターネットに繋がって、機体情報なんかをAWSなんかにあげていきます。
AWSに入ればセキュリティ確保する方法は色々ありますが、そこまでの経路上のセキュリティどうするの?ってことが懸念点です。
セルラー通信からAWSの経路で、どうしても一度はインターネットに出てしまうので、そこでのセキュリティ考える必要があります。
やり方は色々あるとは思います。
特殊な暗号化プロトコルつくるのもいいかもしれません。
でもそんなことすれば運用コスト上がるし、開発コストだってバカにならない。
普通に考えるならHTTPSでの通信にすればいいじゃない、と思うでしょう。
しかし、WHILLは安全と法規制を考慮してOS非搭載、HTTPS実装するとなれば結構泣けます。
そこでSORACOMさんのシステムです。
なんとインターネットに飛び出る前にHTTPからHTTPSに変換してくれるというではないですか。
しかも安い。
これこそ待ち望んでいたものだということでSORACOMシステムを使うことになった訳です。
とりあえず実験
まあとりあえず実験してみようとのことでu-bloxさんのキットにSORACOM SIM挿して動かしてみました。
https://www2.u-blox.com/ja/evaluation-tools-a-software/wireless-evaluation-kits/evk-u20-u23-lisa-3g-eval-kit.html
良い。
何が良いって、面倒なトラブルがほとんど無く、すぐに動いたこと。
しかも一回の通信にかかってる通信量がすぐに見れる。素晴らしい。
しかしここで気づいてしまったのです。
HTTPのGetでもPostでも1.6kB程度通信してる。。。
中身は10B程度なのに。。。
IP直打ちでも1kB超えちゃう。。。
普段数kBのメモリで生きている人間からするともったいなくて鼻血でそうな数字です。
これ全部に通信費かかるのよね?というか消費電力もこれだけ無駄遣いしてるってこと?
UDPならどうなの?
ということで下記のサイトを参考にしながら、UDPで3バイト送信、12バイト受信の接続実験。
http://nantekottai.com/2011/08/06/udp-server-with-node-js-2/
結果(ソラコムサイトから確認)
upload:81byte
download:54byte
そうそう、これくらいですよね。
HTTP→HTTPSだけでは厳しいですよ。
何とかならないですか、ということでSORACOMさんに相談しました。
TCPかUDPか
SORACOMさんからの返答は、
TCP→HTTPSの変換も今後対応しますよ
という神回答。
これで一安心、と思ったけど、ちょっと待てよ、と。
TCPって確かにシンプルなプロトコルだけど、定期的に小さいデータ送るだけで、しかも送れなかったデータを破棄していいなら、UDPの方が通信量少なくていいんじゃないの?
とりあえずSORACOMさんに相談だ。(ほんと感謝してます)
SORACOMさんからの返答は、
”TCPでもセッション張ったまま使えば通信量や消費電力はUDPと変わらないんじゃないですか?”
なるほど、一理ある。
これは実験で確かめるしかない、という謎の使命感に襲われ、実験することに。
そもそも消費電力って重要なの?
電動モビリティなんだから大きい電池積んでるでしょ?
なんでそんなに消費電力気にするの?
と思われる人は多いでしょう。
そんなことは無いのです。
重要なのは、保管されているときの消費電力なのです。
WHILLはいつでもどこでも走れるモビリティですが、寒い時期など長期間使用せずに保管されるお客様がいます。
そんなときにガンガン電力を消費していればどうなるでしょうか?
最悪バッテリーが死にます。
例えば24V10Ahのバッテリパックを使っていたとして、平均待機電流が24V系統で1mAだった場合、自己放電も考えると1年程度で空になってしまいます。バッテリは本当に空になると充電すらできなくなります(BMS次第ではありますが)。
最悪を想定すると、電池が残り20%程度で保管される使い方もありえます。その場合、春になっていざ使おうと思ったとき、充電しても動かない、という事態が発生します。
こういう事態を防ぐために消費電力を気にしている訳です。
再度実験、そして安川CTOの神対応
実際にTCPとUDPで消費電力がどれほど違うのか実験。
(この実験は別のエンジニアがやってくれました)
消費電力の測定って結構難しいのです。
特にこういう小さい電力で、かつ断続的に動くようなものは本当に難しい。
結構良い測定機材をレンタルして測定しました。
ローパワーモードの遷移条件などなど比較する条件多いし、算出の説明も複雑なんで結果だけ。
UDPの方がTCPよりも2割くらい消費電力削減できそう(WHILL限定)
さて、、、
2割、、、
思ったほど下がらなかったけど、無視できない数値、、、
と思いながら、実験結果をSORACOM安川さんに伝えました。
正直、2割くらいしか変わらないんだったらTCP使えばいいんじゃないの?と言われることも予想してたのですが、、、
安川CTO『分かりました。UDP→HTTPS実装します』
との神対応。しかも、先月11月には本当にリリースされてしまいました。
本当、SORACOM、凄いチームです。
以上、UDP→HTTPS変換をお願いするまでのまとめでした
分かりやすくするために若干事実と変えている点もありますが、ほとんど事実です。
無茶な要望に真摯に答えてくれたSORACOMさんには本当に脱帽です。
まだまだ準備中ではありますが、ありがたく使わせていただきます。
IoT雑感
良い機会なので、IoTについて思うことをつらつらと。
最近IoTが色んなところで注目されてますが、ほとんどの人がアプリケーションのことを言ってる気がします。
個人的には、もうちょっとハードだったり、プロトコルだったり、そういうことを議論してもいいんじゃないの、特に日本では、と思ったりします。
IoTでこれから盛り上がってくるのは、BluetoothやWiFi使わずに直接セルラーで繋がる用途です。
ハードという観点で話すにあたって、通信モジュールについて簡単に説明。
一般的に通信モジュールは3階層に分けて考えますが、ざっくりセルラーだけ。
- 第1階層 チップセット。いわゆるICチップです。実際に通信を制御するコア部品です。Qualcommがシェアトップですが、IoT向けはイスラエルのStartupが出てきたりで盛り上がっています。
- 第2階層 モジュール。チップセットに周辺部品付け足して基板実装部品にまとめる。外観はPCのCPUっぽい感じです。技適とかの認証はここがアンテナとセットで取得します。Sierraとかu-bloxとか色んな会社があって群雄割拠で面白いです。
- 第3階層 製品、キット、部品。モジュールを基板に実装して、アンテナとセットでキットとして販売したり、自社製品に組み込んだりします。WHILLはここになります。
第3階層の身としては基本的に第2階層の方たちと話をしていますが、個人的には第1階層に日本メーカーの話を聞かないことが大変残念です。イスラエルのStartupがのし上がってきてるくらいなんだから、日本でも出来るでしょ、IoTって皆言うくらいなんだからここを抑えにいけよ、という気持ちがたまに湧き上がってきます。
IoT向け通信規格という点では、3G or 2G, LTE Cat.1, LTE Cat.0, LTE Cat.M or NB-IoT, の順に主流通信規格が移り変わっていき(ただ日本においてはCat0は無かったことにされる気もしますが。。。)、ハードはこれに合わせて、コストダウン、消費電力削減が実現されていくことでしょう。
一方でプロトコルはと言うと、MQTTとかは気にしてます。
ただMQTTも色々な種類あるようで、現状TCPをベースにしたものが主流みたいです(間違ってたらすいません)。
ただ実際問題、プロトコルはハードの制約も受けます。
普通、通信モジュール(第2階層)はHTTPとかTCP、UDPみたいなメジャーなプロトコルを内部で持っていて、それを外部から動かす形になるので、いくらMQTTに特化したプロトコル組みたいと思っても、どれかをベースにするしかない場合がほとんどです。
そうなると純粋なTCPやUDPよりも通信量大きくなります。
つまり、しばらくはTCPやUDPのような原始的なプロトコルとSORACOMの組み合わせが、消費電力とセキュリティを気にする用途では最強、と私は思ったりしてます。
おしまい
追記:こういうの興味があるエンジニアでWHILLで働いてみよっかなという人がいれば[email protected]に連絡ください。
Author And Source
この問題について(UDP→HTTPS変換をお願いするまでのまとめ), 我々は、より多くの情報をここで見つけました https://qiita.com/fukuoka/items/08e5942f951748363a95著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .