るきへなWeblog

TIME_WAIT タイムアウト

　某所で、「たまにネットに繋がらなくなる」という現象が起きていた。しかし、チョト経つと自然復旧する。

　結論としては、NAPTセッション数が足りなかった。

　ここでは マイクロ総研のNetGenesis SuperOPT90 を利用している。

　最初の調査では、OPT90のログを見ても何も異常はなかった。しかし、SYSLOGのオプションを全部ONにしたところ、"IP Masquerade session table full"が表示された。

　解決策としては、コチラをみて、セッション情報保持時間を減らしてみた。最初、2分30秒にしてみたら現象の発生頻度が下がった。思い切って1分にしてみたら現象が出なくなった。

　しかし、3分とか1分とかって短いよな。たとえばTELNETとかSSHとかしていて、1分で切られると面倒くさい。ログインしなおさなきゃならないは、サーバー側のプロセスが残っているはで面倒。

　自宅の Aterm WB7000H は「NAT タイマ（秒）」という項目があり、デフォルト値は3600秒だ。

　差がありすぎる。何故だ？

　TCPの切断処理は、切断したい側がFINを投げて、ACKを貰う。ACKを投げたほうもFINを投げて、ACKを貰う。このとき、最後のACKを投げた側（＝切断したい側）は、TIME_WAIT状態になる。

　コチラの状態遷移図を見ると分かりやすいかもしれない。

　TIME_WAIT状態は何を待っているのかというと、相手がACKを受け取れなくて、もう一度FINを投げてくることがあるからなんだそうな。

　NAPTルータの立場からすると、クライアントがTIME_WAIT状態の場合も、NAPTセッションテーブルは維持しなければならない。NAPTセッションテーブルを破棄するのはTIME_WAITと同じタイムアウト時間後だ。だがこれは明確な秒数が決まっておらず、実装依存である。一般的には30〜120秒らしい。

　このTCPの状態遷移を考えると、NAPTセッションテーブルのタイムアウト値は、2種類必要のような気がする。FIN後のTIME_WAIT状態のタイムアウトと、ESTABLISHED状態での無通信タイムアウトの2種類。

　OPT90で設定する値は、もしかしするとTIME_WAITのタイムアウト値なのだろうか。いや、両方とも同じ値で管理しているのかな？ ナゾだ。

　ところで、タイムアウト値のチューニングって面倒くさいから、テーブルから一番古いのを追い出して使えばいいんじゃねぇの？ とか思った。さらに、HTTPはキープアライブで無駄なセッション使ってそうだから積極的に切っちゃえとか、TELNET/SSHだけは切らずに温存とか、いろいろ妄想が広がっていく。

　最初に戻るが、問題が起こった某所は、人が10人も居ない程度の事務所である。そこで2048セッションを使い切ってしまうというのは中で何をやっているのだろうか？ 3分間に2048セッションということは1秒間に11セッションぐらい消費している計算になる。「人力でネットサーフィン」では到底無理なアクセス数だ。

　今度、パケットキャプチャしてみようかと思っている。