Real benefits of tcp TIME-WAIT and implications in production environment
Posted
by
user64204
on Server Fault
See other posts from Server Fault
or by user64204
Published on 2011-11-24T09:46:53Z
Indexed on
2011/11/24
10:00 UTC
Read the original article
Hit count: 340
SOME THEORY
I've been doing some reading on tcp TIME-WAIT
(here and there) and what I read is that it's a value set to 2 x MSL
(maximum segment life) which keeps a connection in the "connection table" for a while to guarantee that, "before your allowed to create a connection with the same tuple, all the packets belonging to previous incarnations of that tuple will be dead".
Since segments received (apart from SYN under specific circumstances) while a connection is either in TIME-WAIT
or no longer existing would be discarded, why not close the connection right away?
Q1: Is it because there is less processing involved in dealing with segments from old connections and less processing to create a new connection on the same tuple when in TIME-WAIT
(i.e. are there performance benefits)?
If the above explanation doesn't stand, the only reason I see the TIME-WAIT
being useful would be if a client sends a SYN
for a connection before it sends remaining segments for an old connection on the same tuple in which case the receiver would re-open the connection but then get bad segments and and would have to terminate it.
Q2: Is this analysis correct?
Q3: Are there other benefits to using TIME-WAIT?
SOME PRACTICE
I've been looking at the munin graphs on a production server that I administrate. Here is one:
As you can see there are more connections in TIME-WAIT
than ESTABLISHED
, around twice as many most of the time, on some occasions four times as many.
Q4: Does this have an impact on performance?
Q5: If so, is it wise/recommended to reduce the TIME-WAIT
value (and what to)?
Q6: Is this ratio of TIME-WAIT
/ ESTABLISHED
connections normal? Could this be related to malicious connection attempts?
© Server Fault or respective owner