日報(2021-01-13)　30 - 300 - 3000 データ送信のオーバーヘッドの法則

結論

データを送信する際のヘッダなどのオーバーヘッドですが

• UDP: 30バイト程度
• http: 300バイト程度
• https: 3000バイト程度

こんなかんじで１０倍づつ増えていくのがキレイだなと思いました

はじめに

データをサーバに UDP で投げるような IoT なアプリケーションだと、たまにファイアーウォールを通れなことがあって、「通してください」と IT の人にお願いするのも現実的でないのでトランスポートを http に切り替えて投げているのですが、なんとなく「http header の分ぐらいトラフィックが無駄になってるんだろうな」ぐらいに思ってました

で、今どきなんだから http2 にしたらヘッダ圧縮とか効いて軽くなるのかな(無知ゆえの誤解です、文字列だけの知識は無益などころか有害でした)と気軽に考えて（正確にはなにも考えないで）http2 にしたら逆に重くなったのでした

UDP のオーバーヘッド

UDP の場合、IP ヘッダの 20 バイトと UDP ヘッダの 8 バイトで 28 バイトになります

下の一番下の２つ、192.168.11.5,58613 から 33 バイトを 153-228-47-212.inst,10004 に送っているのと 29 バイトを 受け取っているのが、5バイトのデータを送信して 1バイトのレスポンスを受け取っている UDP 通信の例です

http のオーバーヘッド

http ヘッダと response ヘッダがつくので、上と同じ 5バイト送信して 1バイト返信もらうだけでもそれぞれ 300 バイト弱になります

https のオーバーヘッド

セキュアな伝送路を作るためのネゴシエーションの分とかあって 3000バイトこえちゃいます、5バイト送るのに 3000 バイトのオーバーヘッドはもったいないのでこのアーキ採用するのにはそれなりの覚悟がいりますね

trafshow

上のトラフィックですが trafshow を使って

sudo trafshow -i wlan0 tcp

とか

sudo trafshow -i wlan0 udp

して取りました。trafshow は iftop とか bmon とかみたいに「今、どれぐらいのスループットでデータが流れている」を表示するのではなく、もっと直接的に今、どこにどれだけ流れた を表示してくれるので、こういう時に便利なツールです

---