version 7, including all changes.
.
| Rev |
Author |
# |
Line |
| 7 |
AristotlePagaltzis |
1 |
States of a [TCP] connection. These can be seen with <tt>netstat -at</tt> |
| 1 |
PerryLorier |
2 |
|
| 7 |
AristotlePagaltzis |
3 |
<tt>CLOSED</tt>: |
| |
|
4 |
A theoretical state where a [TCP] connection doesn’t exist yet. |
| |
|
5 |
<tt>LISTEN</tt>: |
| |
|
6 |
A state where [TCP] connection is waiting for a connection to be made to it. |
| |
|
7 |
<tt>SYN_RCVD</tt>: |
| |
|
8 |
A [SYN] has been received, a [SYN] [ACK] has been sent, and we are waiting for an [ACK]. |
| |
|
9 |
<tt>SYN_SENT</tt>: |
| |
|
10 |
A [SYN] has been sent to start a connection, the [SYN] [ACK] hasn’t yet been received. |
| |
|
11 |
<tt>ESTABLISHED</tt>: |
| |
|
12 |
A connection has been established |
| |
|
13 |
<tt>CLOSE_WAIT</tt>: |
| |
|
14 |
After a [TCP] connection has been closed, the spec says you should make sure that the connection is not reopened for a few minutes to prevent packets that were delayed in the Internet causing the connection to be reopened. These will disappear by themselves after a while. This can cause problems on servers that have lots of very short connections (such as a web server) by filling up the OS’s connection table. See also [EADDRINUSE] |
| |
|
15 |
<tt>LAST_ACK</tt>: |
| |
|
16 |
A [FIN] has been received, we’ve sent our own FIN, but we are waiting on the [ACK] before we can move to the closed state. |
| |
|
17 |
<tt>FIN_WAIT_1</tt>: |
| |
|
18 |
A [FIN] has been sent, waiting for a [ACK] or [FIN] |
| |
|
19 |
<tt>FIN_WAIT_2</tt>: |
| |
|
20 |
A [FIN] has been sent, and an [ACK] has been received. More data can be received. This connection is half open. |
| |
|
21 |
<tt>CLOSING</tt>: |
| |
|
22 |
A [FIN] has been sent, and one received, the [FIN] hasn’t been [ACK]ed yet. |
| |
|
23 |
<tt>TIME_WAIT</tt>: |
| |
|
24 |
The connection has closed, and is waiting for 2MSL |
| 4 |
JohnMcPherson |
25 |
|
| 7 |
AristotlePagaltzis |
26 |
!! Tuning your system’s settings |
| 4 |
JohnMcPherson |
27 |
|
| 7 |
AristotlePagaltzis |
28 |
The amount of time that a connection waits in various stages is controlled by the OperatingSystem. Some [OS]es let you tune these settings. For example, for [Linux]-based [OS]es, look at the control files in <tt>/proc/sys/net/ipv4</tt>. According to <tt>/usr/src/linux/Documentation/filesystems/proc.txt</tt>: |
| 4 |
JohnMcPherson |
29 |
|
| 7 |
AristotlePagaltzis |
30 |
<tt>tcp_syn_retries</tt>: |
| |
|
31 |
Number of times initial [SYN]s for a [TCP] connection attempt will be retransmitted. Should not be higher than 255. This is only the timeout for outgoing connections, for incoming connections the number of retransmits is defined by <tt>tcp_retries1</tt>. |
| |
|
32 |
<tt>tcp_fin_timeout</tt>: |
| |
|
33 |
The length of time in seconds it takes to receive a final [FIN] before the socket is always closed. This is strictly a violation of the [TCP] specification, but required to prevent denial-of-service attacks. |
| |
|
34 |
<tt>tcp_retries1</tt>: |
| |
|
35 |
Defines how often an answer to a [TCP] connection request is retransmitted before giving up. |
| |
|
36 |
<tt>tcp_retries2</tt>: |
| |
|
37 |
Defines how often a [TCP] packet is retransmitted before giving up. |
