第 3 章 レイヤ 7 NIDS/NIPS のための TCP ストリーム再構成機構 22
3.6 実験
3.6.5 Store-through と Stop-forward の比較
センサで重い処理を伴うようなッセージの検査のための余地を残している．Store-through方式によるメモリ使用量も，IP forwardより少し多い程度であり，大きな
オーバヘッドになるほどではなかった．Store-through方式では，IP forwardより最
大2.4%（同時接続数が80と90の時）メモリ消費量が多い程度であった．
フラグメンテーションがあるとき
図3.9にパケットの1%を，図3.10にパケットの10%を，IPフラグメントし順番 を入れ替えた場合のCPU使用率とメモリ使用量を示す．フラグメンテーションがな いときに比べて，IP forwardとstore-throughともにCPU使用率は増加しているが，
store-throughのIP forwardに対する割合は変化していない．すなわち，store-through によるCPU使用率は，IPフラグメントされたパケットの割合が1%，10%の時と もに，同時接続数にかかわらず，IP forwardの約2倍となっている．しかし，同時 接続数が100と最悪の場合でも，CPU使用率が70%程度であり，100%使用率まで には達していない．そのため，メッセージを検査するためにセンサが処理をする 余地は残っている．
メモリ使用量も，IPフラグメンテーションや順番の入れ替えによって大きく増 加する，ということはなかった．IP転送時のメモリ消費量と比較すると，IPフラ グメントされたパケットの割合が1%の時には最大3.3%増加（同時接続数が100の 時），IPフラグメントされたパケットの割合が10%の時には最大4.7%増加（同時 接続数が90の時）程度となっており，IPフラグメントがない場合の最大2.4%増加 に比べてもそれほど大きくなっているわけではない．Store-through方式では，順 番が入れ替わったりIPフラグメントされたパケットはコピーを取って保存するが，
順番通りのパケットが届いてメッセージの検査が終わった時点でメモリは解放さ れるため，メモリ使用量の増加はそれほど多くはならない．
20 40 60 80 100 0
20 40 60 80 100
10 8 6 4 2 1
CPU usage [%]
Number of clients IP Forward
Store-Through
(a) CPU使用率
20 40 60 80 100 30
32 34 36 38 40 42
10 8 6 4 2 1
Memory usage [MBytes]
Number of clients IP Forward
Store-Through
(b)メモリ使用量
図3.8: 実験結果：CPUとメモリの使用率（0%フラグメンテーション）
20 40 60 80 100 0
20 40 60 80 100
10 8 6 4 2 1
CPU usage [%]
Number of clients IP Forward
Store-Through
(a) CPU使用率
20 40 60 80 100 30
32 34 36 38 40 42
10 8 6 4 2 1
Memory usage [MBytes]
Number of clients IP Forward
Store-Through
(b)メモリ使用量
図3.9: 実験結果：CPUとメモリの使用率（1%フラグメンテーション）
20 40 60 80 100 0
20 40 60 80 100
10 8 6 4 2 1
CPU usage [%]
Number of clients IP Forward
Store-Through
(a) CPU使用率
20 40 60 80 100 30
32 34 36 38 40 42
10 8 6 4 2 1
Memory usage [MBytes]
Number of clients IP Forward
Store-Through
(b)メモリ使用量
図3.10: 実験結果：CPUとメモリの使用率（10%フラグメンテーション）
実験環境
この実験では，クライアントマシン，ルータ，NIDS，サーバマシンをそれぞれ 1台ずつ用い，この順番で1Gbpsのネットワークで接続した．全てのマシンは第 3.6.1節と同じ性能である．OSはLinux 2.6.16を用いた．
クライアントとサーバは，ルータとNIDSを介してDiscard通信 [83]を行う．
Discard通信とは，単にデータを送信するだけの通信であり，受信側では届いた
データに対して特別な処理はしない．また，ネットワークの輻輳とパケット損失を 再現するため，ルータではtoken bucket filter (tbf) [84]を用いて，帯域幅2MB/s，遅 延10ms，キューサイズ15,400bytesというボトルネックをエミュレートした． Store-through方式及びstop-forward方式はNIDS上で動作する．TCPストリーム再構成 機構の2方式の比較を行うため，センサは無効とした．クライアントは200MBの データをサーバに送信し，計測は5回行った．クライアントの輻輳制御アルゴリ ズムは，LinuxのデフォルトであるBinary Increase Congestion Control (bic)である．
また，トランスポート透過性の実ネットワーク上での影響を確認するため，同 様の実験をインターネット経由でも行った．クライアントマシンとサーバマシン を，それぞれ慶應義塾大学と電気通信大学の2つの大学に置いて実験を行った．こ れらのネットワーク距離は22ホップであった．この実験のクライアントマシンは，
Pentium 4 2.80 GHz CPU 2つ，512 MBメモリ，7,200 rpm HDDを持つ．この実験 では故意にIPフラグメントや順番の入れ替えはしていない．
実験結果
図 3.11にローカルネットワークでのクライアント側の輻輳ウィンドウサイズ，
図3.12にインターネット環境での輻輳ウィンドウサイズの変化を示す．見やすさを 考慮し，図3.11では5回計測したうちの1回分についてプロットしてある．図3.12 では5回全ての計測結果をプロットした．
ローカルネットワーク（図3.11）におけるstore-through方式では，パケット損
失が発生してウィンドウサイズが一度下がっても，すぐに大きくなる．一方，stop-forward方式では，一度ウィンドウサイズが下がると，しばらく下がった状態が続
いてから大きくなる．この傾向は実インターネット環境でも同様である（図3.12）．
Store-through方式でのウィンドウサイズは一度下がってもすぐに上昇するが，
stop-forward方式では一度下がると，上昇する前にしばらく下がったままの状態が続く
（例えば140秒付近）．
表3.3: 送信所要時間の比較(5回測定の平均)
Time [sec.] Store-through Stop-forward ratio Local
no packet drop (tbf off) 16.022 15.914 −0.7%
packet drop (tbf on) 119.326 1039.012 ×8 Internet
no packet drop 34.330 34.601 +0.7%
packet drop 92.840 188.828 ×2
この結果より，store-through
方式はトランスポート透過性を保持するが，stop-forward
方式はトランスポート透過性を保持しないことが分かる．これは，stop-forward方式ではパケットの転送を止めるからである．第2.1.1節で述べたように，
stop-forward方式では順番通りでないパケットを，その前のパケットが到着する
まで，転送せずに止める．そのため，輻輳が起きて1つのパケットが損失すると，
サーバにはパケットが1つも届かず，クライアントは損失したパケット以外にも 全てのパケットを再送しなければならなくなる．これを確認するため，ローカル ネットワークでの再送パケット数を計測した．5回測定した平均再送パケット数は，
store-throughは657個であるのに対し，stop-forwardは38倍の21,231個であった．
Stop-forward方式では，トランスポート透過性が保持されないことで，性能にも
影響を与えている．表3.3にデータ送信所要時間の平均値を示す．パケット損失が ないときの，store-through方式とstop-forward方式の送信所要時間は，差が1%以 下とほとんど変わらない．しかしながら，ネットワークの輻輳によりパケット損失 がおきたときのstop-forward方式の送信所要時間は，store-through方式に比べて，
ローカルネットワークで8倍，インターネット環境で2倍となる．送信所要時間が 増える理由としては2つ考えられる．まず1つ目は，再送パケットが増え，必要 のないパケットが送信されているためであると考えられる．クライアントは，損 失したパケットだけでなくNIDSで止められているパケットまで再送する．2つ目 は，ウィンドウサイズが小さいためであると考えられる．Stop-forward方式では，
一度ウィンドウサイズが小さくなると，しばらく小さいままとなりすぐに大きく ならない．ウィンドウサイズが小さいと，クライアントは一度に多くのパケット を送信することができず，ACKが返ってくるのを待たなければならなくなる．
0 5 10 15 20 25 30 35 40 45
0 20 40 60 80 100 120
Window size
Elapsed time [sec]
Transmission finished
120
(a) Store-through
0 5 10 15 20 25 30 35 40 45
0 20 40 60 80 100 900
Window size
Elapsed time [sec]
Transmission finished
900
(b) Stop-forward
図3.11: token bucket filterを用いたローカルネットワークでの輻輳ウィンドウサイ ズの変化
0 10 20 30 40 50 60 70
0 50 100 150 200 250 300 350 400 450
Window size
Elapsed time [sec]
go up immediately
(a) Store-through
0 10 20 30 40 50 60 70
0 50 100 150 200 250 300 350 400 450
Window size
Elapsed time [sec]
still low for a while
(b) Stop-forward
図3.12: インターネット経由での輻輳ウィンドウサイズの変化