デフォルトでは、との両方tcp_tw_reuseがtcp_tw_recycle無効になっている場合、カーネルは、状態のソケットがTIME_WAITその状態に十分長く留まるようにします。将来の接続に属するパケットが古い接続の遅延パケットと間違えられないようにするのに十分な長さです。
を有効tcp_tw_reuseにすると、有効期限が切れる前に状態のソケットをTIME_WAIT使用でき、カーネルはTCPシーケンス番号に関する衝突がないことを確認しようとします。有効にするとtcp_timestamps（別名PAWS、ラップされたシーケンス番号に対する保護）、これらの衝突が発生しないようにします。ただし、TCPタイムスタンプを両端で有効にする必要があります（少なくとも、それは私の理解です）。厄介な詳細については、tcp_twsk_uniqueの定義を参照してください。
を有効tcp_tw_recycleにすると、カーネルはより積極的になり、リモートホストによって使用されるタイムスタンプを想定します。状態で接続している各リモートホストによって使用された最後のタイムスタンプを追跡しTIME_WAIT、タイムスタンプが正しく増加した場合にソケットを再利用できるようにします。ただし、ホストが使用するタイムスタンプが変更された場合（つまり、時間にワープバックした場合）、SYNパケットはサイレントにドロップされ、接続は確立されません（「接続タイムアウト」のようなエラーが表示されます）。カーネルコードを詳しく調べたい場合は、tcp_timewait_state_processの定義が出発点として適している可能性があります。
現在、タイムスタンプは過去にさかのぼってはなりません。そうでもなければ：
- ホストが再起動されます（ただし、ホストが復旧するまでに、
TIME_WAITソケットの有効期限が切れている可能性があるため、問題は発生しません）。
- IPアドレスは他の何かによってすぐに再利用されます（
TIME_WAIT接続は少し残りますが、他の接続はおそらく攻撃されTCP RST、それによってスペースが解放されます）。
- ネットワークアドレス変換（またはsmarty-pantsファイアウォール）は、接続の途中で行われます。
後者の場合、同じIPアドレスの背後に複数のホストを配置できるため、タイムスタンプのシーケンスが異なります（または、タイムスタンプはファイアウォールによって接続ごとにランダム化されます）。TIME_WAITその場合、一部のホストは、サーバーのバケットのタイムスタンプが新しいポートにマップされているため、ランダムに接続できなくなります。そのため、ドキュメントには、「設定が原因で、NATデバイスまたはロードバランサーがドロップフレームを開始する可能性がある」と記載されています。
一部の人々は放っておくことをお勧めしますtcp_tw_recycleが、有効tcp_tw_reuseにして低くしtcp_fin_timeoutます。私は同意します ：-）