ダウンタイムを安全に減らすことができますが、パケット損失またはジッターがあるネットワークで接続が適切に閉じられないという問題が発生する可能性があります。私は1秒からチューニングを開始せず、15から30で開始して、下に向かって作業します。
TCP接続が閉じられると、TIME-WAIT状態の2 * MSLの遅延により、ソケットペアが4分間拘束されます（[Postel81]のセクション3.5を参照）。1つの接続を閉じて新しい接続を開くアプリケーション（TCPなど） 、ストリームモードを使用したFTPデータ転送接続）は、毎回新しいソケットペアを選択する必要があります。この遅延は、2つの異なる目的に役立ちます。
(a) Implement the full-duplex reliable close handshake of TCP.
The proper time to delay the final close step is not really
related to the MSL; it depends instead upon the RTO for the
FIN segments and therefore upon the RTT of the path.*
Although there is no formal upper-bound on RTT, common
network engineering practice makes an RTT greater than 1
minute very unlikely. Thus, the 4 minute delay in TIME-WAIT
state works satisfactorily to provide a reliable full-duplex
TCP close. Note again that this is independent of MSL
enforcement and network speed.
The TIME-WAIT state could cause an indirect performance
problem if an application needed to repeatedly close one
connection and open another at a very high frequency, since
the number of available TCP ports on a host is less than
2**16. However, high network speeds are not the major
contributor to this problem; the RTT is the limiting factor
in how quickly connections can be opened and closed.
Therefore, this problem will no worse at high transfer
speeds.
(b) Allow old duplicate segements to expire.
Suppose that a host keeps a cache of the last timestamp
received from each remote host. This can be used to reject
old duplicate segments from earlier incarnations of the
*注意：FINを送信する側は必要な信頼性の程度を知っているため、FINの受信者のTIME-WAIT遅延の長さを判別できるはずです。これは、FINセグメントの適切なTCPオプションで実現できます。
connection, if the timestamp clock can be guaranteed to have
ticked at least once since the old conennection was open.
This requires that the TIME-WAIT delay plus the RTT together
must be at least one tick of the sender's timestamp clock.
Note that this is a variant on the mechanism proposed by
Garlick, Rom, and Postel (see the appendix), which required
each host to maintain connection records containing the
highest sequence numbers on every connection. Using
timestamps instead, it is only necessary to keep one quantity
per remote host, regardless of the number of simultaneous
connections to that host.