LinuxサーバーのTCPネットワークのパフォーマンスを決定するカーネルパラメータ – 3編 | NHN Cloud Meetup
連載 LinuxサーバーのTCPネットワークのパフォーマンスを決定するカーネルパラメータ- 1編 LinuxサーバーのTCPネットワークのパフォーマンスを決定するカーネルパラメータ- 2編 5. TIME_WAIT socket TIME_WAIT状態のソケットは、利用可能なlocal port数を軽減させて同時に保有できるクライアントソケットの数を制限します。 5.1 TIME_WAIT socketとは? TIME_WAIT状態のソケットは、いつ発生するでしょうか? まず、TCPソケットの状態フローを見てみましょう。 上図から分かるように、active closingするソケットの最後の終着地がTIME_WAITの状態です。 言い換えれば、クライアントソケットであれ、サーバーソケットであれ、close()システムコールを先に呼び出した側(active closing)が最終的にそうなります。 TIME_WAIT状態では、RFC793の定義通りなら2MSL(Maximum Segment Lifetime)、すなわち2分間待機することになります。ところが、実際はほとんどのOSは、最適化のため1分程度をTIME_WAIT状態で待機するように実装されています。Linuxもこの時間を1分で規定しており、変更できません。(カーネルコードの定数として定められています。) Googleで検索できる一部の文書では、net.ipv4.fin_timeoutを変更すると、TIME_WAITで待機する時間を変更できると紹介しています。net.ipv4.fin_timeoutは、FIN_WAIT_2の状態に停留できる最大時間を設定します。(RFCは、TIME_WAIT状態以外では別途timeoutを定義していませんが、大半のシステムでは、最適化のため別途timeout時間を置いています。)現実世界では、FIN_WAIT_2に留まるソケットは非常に珍しく、自然とTIME_WAIT状態に遷移されるので、設定値はデフォルトのままでも大きな問題にはなりません。 ここで強調したいのは、TIME_WAIT状態は悪い状態ではないということです。 ソケットの、極めて正常なライフサイクル内の1つの状態であり、ソケットのgracefully shutdownを保証する不可欠な要素です。