インターネット通信データ量をd3jsのツリーマップで可視化してみた

練習などを兼ねてちょいと書いてみました。

自分のMacBookProで作業をしていた時に取得した通信データから、通信相手をドメイン名で判定し、送受信量をもとにツリーマップにしてみました。通信からのデータ取得は自作ツールを使い、出力結果をPythonでごにょっといじった後にd3jsで描画しました。通信データは約5時間ほど。

HTML版はここに公開しています。細かい通信量とか見えます。

送信データ量のツリーマップ

送信データ量と受信データ量は一度に表現するのが難しいので、今回は分けてみました。まずは送信データ量から。

f:id:mztnex:20151114163953p:plain

解説を入れるとこんな感じです。

f:id:mztnex:20151114164009p:plain

送信データ量そのものは多くないのですが、作業していたソースコードがDropbox配下にあったので頻繁にDropboxにデータを送信していたため、Dropboxがとても大きく出ています。といっても、送信データ量はDropboxの島を全部あわせて70MB程度ですね。どうということはありません。さらに、作業時にずっとみていたニコ動の通信が目立って見えるのがわかります。これも送信データ量としては少なく、トータルで20MB強というところでしょうか。これはこちらから生中継をするようなデータを流していたわけではないため、ほぼTCPのack（受信確認）のパケットだけでこれぐらいの容量になっていることが伺えます。

受信データ量のツリーマップ

一方、受信側はこんな感じです。

f:id:mztnex:20151114165102p:plain

解説付きだとこんな感じになります。

f:id:mztnex:20151114165134p:plain

さっきより顕著にニコ動の通信がデータ量を占めているのがわかります。マイリスト登録していた動画をBGM代わりに受信しつづけていたので、その配信される動画のデータががつんと乗ってきている状態ですね。全体で約2.5GBほどあり、携帯キャリアの回線（テザリング）などを使っていたらあっというまに帯域制限にひっかかったでしょう。（この時はカフェに設置されてるWiFiを使っていました）

次に大きなポーションになっているのが左下のBlizzard社からの通信です。これはBlizzard社が制作、発売しているHeathstoneのパッチが落ちてきたためだと考えられます。Hearthstoneはゲームとしてとてもシンプルなのですが、演出などが豊富なためアプリ・パッチのサイズがとても大きいというのが若干ネックになっている気がします。でもゲーム内容はとても面白いのでおすすめですよ（脈絡のない宣伝）

他に注目すべき点としては右下にあるtwimgからのトラフィックでしょうか。そこまでtwitterの画像をずっと見続けた記憶はないので、Twitterクライアント（Tweetbot）がサムネイル（および画像本体？）を取得する通信だけで約100MBほどを受信しているのがわかります。ちなみにツイートの受信であるuserstream.twitter.comからの受信は右上にある青の細長い部分で、受信は20MB程度です。写真投稿などが多い昨今だと通信データ量だけでみればかなりtwimgに負荷がかかっているようです。

ということで、通信を無制限に使える環境であれば特に気にすることのないものですが、データ量制限のある環境ではどの通信がどれくらいの割合をしめているかということがわかると通信データ量の節約がはかどるのではと思います。（一部当然のことですが）今回の知見としては以下のとおりです。