昨日に引き続いてソケット通信な話です。
conntrack-toolsを導入してパケットの流れを見たりしてる今日この頃ですが、流れを見たときに
conntrack v1.2.1 (conntrack-tools): 19 flow entries have been shown.
こんな感じで表示されるんですけど、flowってなんやと思たのでちょこっとググってみました。
正しいのかどうか分からないけど、おそらくnetwork flowのflowのことだと思う。
ネットワークの頂点をノード、枝をアークと呼ぶ。1つのノードに流入するフローとそのノードから流出するフローは常に等しい。なにかに例えるとすると、道路網の交通量、パイプを流れる液体、電気回路を流れる電流とかみたいです。なんとなくイメージはできたかもしれない。
んで、敵を知るにはまずは味方からという事でこのflowをおーばーどらいぶー！っという感じで大量に流してみたいと思った。のだが、これがなかなか手ごわい。結果を言うとこの戦いはまだ終わっていないのだ。
とりあえずPythonなら何とかなるので、PythonのDoSのプログラムを拾ってきてVM同士で流してみることにした。
というかCが多いんだな。ただソケットなら同じものが使えたりするのでそこそこ役にはたった。
学生時代に中途半端にやってたからおじさんになってから苦労するんだよ。
ちょっと話が逸れてしまったが、パケットをガンガン流してもどういう事か最大でも5万flowくらいにしかならず。オプションEで監視してみるとdestroyということで破棄か何かになっているみたいだ。新しい接続も追いついてないみたいでそれで最大でも5万flowとな。
これがうちのネットワークの限界かどうかも分からないので、ためしにVM4個にそれぞれプログラムの配置をしてホストに向かって一斉に流してみたが、これってDDoSにあたると思ったんだけど、これも何故か分からないけども、5万flowにしか届かず。
これはもうプログラムの書き方に問題あるのかもしれないなあと思ったので、UDPのブロードキャストを飛ばすPythonのプログラムを拾ってきて、ちょっと改変して１～65535ポートまでガンガン流すプログラムにいじって実行してみた。
やはり記述が問題だったようで、今度は20万flowまでいった。
でも、これも最大で20万。これが限界なのかー！
と思ったが、イメージ的にTCPよりUDPの方が確認をせずにドバドバ流すから大量にflowが流れると思ったんだけど、なんとなくTCPのプログラムに変えてみた結果なんと50万flowに達した。
しかしこれもflowの最大値は上がったのだけど、いくら流してもパケットドロップまでは起きなかった。
ちなみにだけど、ブロードキャストに流してみてサーバーの隣のWindowsにどれくらい影響があるか試してみたら、flowが5万くらいのプログラムですら20Mbpsくらいの帯域を使ってた。
こわいこわい。
CTUは超えないはずなので問題ないけど、一歩間違えたらえらいことになっちゃうから、気を付けるようにした方がいい。
論よりコードというけれど、今回の話は公開はしないです。あとちょっとだけ試してみようかなあと思ったけど、やっぱりやめたOpenflowというのがあって、これはflowtableでflowの制御ができるものみたい。
動的にネットワークを作れるのだそうだ。
ちまたで有名なSDNってやつみたい。SDN48ってあるの最近知ったけど、まったく関係ない（笑）
CDNとか3文字ばっかりでややこしいんだー。
