시간을 안전하게 단축 할 수 있지만 패킷 손실 또는 지터가있는 네트워크에서 연결이 제대로 닫히지 않는 문제가 발생할 수 있습니다. 나는 1 초에 튜닝을 시작하지 않고 15-30에서 시작하여 아래로 내려갑니다.
또한 응용 프로그램을 수정해야합니다.
TCP 연결이 닫히면 TIME-WAIT 상태에서 2 * MSL의 지연 시간이 4 분 동안 소켓 쌍을 연결합니다 ([Postel81]의 섹션 3.5 참조) 하나의 연결을 닫고 새 연결을 여는 TCP 기반 응용 프로그램 스트림 모드를 사용하는 FTP 데이터 전송 연결은 매번 새 소켓 쌍을 선택해야합니다.이 지연은 두 가지 다른 용도로 사용됩니다.
(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.