TIME_WAITはファイル記述子を消費しますか？
多くのTCPIPおよびWebチューニングガイドで、「開いているファイルが多すぎます」というエラーが発生した場合は、ファイル記述子の最大数を増やすことをお勧めします。
しかし、「lsof-i」の出力にTIME_WAITが表示されません
TIME_WAITがファイル記述子を消費することを誰かが知っていますか？か否か
ファイル記述子は、アプリケーションがソケットからの読み取り/書き込みに使用します。したがって、アプリケーションがclose（）を呼び出すと、ファイル記述子はすぐに解放されます。
一方、アプリケーションがshutdown（）を呼び出す場合、ファイル記述子は引き続き有効であるため、アプリケーションはソケットとの間で読み取り/書き込みを行うことができます。
https://oroboro.com/file-handle-leaks-server/ からの引用：
神話：TCP TIME_WAITのソケットはファイルハンドルを保持しています人質
TCP/IPソケットを閉じると、オペレーティングシステムはソケットをすぐに解放しません。複雑な理由から、ソケット構造は、閉じられた後にIPパケットがそのソケットに到着する可能性がわずかにあるため、数分間循環しないようにする必要があります。オペレーティングシステムがソケットを再利用した場合、その接続の新しいユーザーは、他の誰かの失われたパケットの影響を受けてセッションに影響を与えることになります。
ただし、これはファイルハンドルを開いたままにしません。ソケットのファイル記述子を閉じると、ファイル記述子自体が閉じられます。 「開いているファイルが多すぎます」というエラーは表示されません。開いているソケットが多すぎると、サーバーが新しい接続の受け入れを停止する場合があります。これに対処する方法はいくつかあります（ソケットの再利用を許可するか、TCP TIME_WAIT）を下げる）-ただし、ファイルハンドルの制限を上げることはその1つではありません。
神話：ファイルハンドルが解放されるまでに時間がかかる
これは、TCP TIME_WAITの神話に関連しています。ファイルハンドルを閉じるとき、オペレーティングシステムがハンドルを解放するまでしばらく待たなければならないという誤った考えです。
ファイルハンドルを閉じると、osメソッドがリソースを解放するものが呼び出され、OSはそのリソースをすぐに解放するか、ソケットの場合のように後で解放しますが、close（）はファイルハンドルテーブルのファイルハンドルをすぐに解放します。プロセスはファイルハンドルテーブルを完全に制御しており、独自のファイル記述子テーブルのスロットを解放するために何かを待つ必要はありません。
TIME_WAITはTCP状態であり、ファイル記述子を消費しません。ただし、TIME_WAITのソケットはファイル記述子を消費します。ソケットは、UNIXの他のほとんどすべてと同様のファイルです。これがLinuxの場合ソケットの有効期限（待機時間）を調整したり、/proc/sys/net/ipv4/でソケットのリサイクルを有効にしたりできます。
特に興味深い2つの項目はおそらく次のとおりです。
sysctl -w net.ipv4.tcp_tw_recycle=1
sysctl -w net.ipv4.tcp_tw_reuse=1
いつものように、可能であれば事前にこれらをテストしてください。