Differences between current version and predecessor to the previous major change of TcpStates.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 7 | Last edited on Thursday, May 26, 2005 9:23:01 pm | by AristotlePagaltzis | |
| Older page: | version 5 | Last edited on Thursday, March 31, 2005 8:55:17 am | by JohnMcPherson | Revert |
@@ -1,33 +1,37 @@
-States of a [TCP] connection.
These can be seen with
-
netstat -at
+States of a [TCP] connection. These can be seen with <tt>
netstat -at</tt>
-;
CLOSED:A theoretical state where a [TCP] connection doesn'
t exist yet.
-;
LISTEN:A state where [TCP] connection is waiting for a connection to be made to it.
-;
SYN_RCVD: A [SYN] has been received, a SYN ACK has been sent, and we are waiting for an [ACK]
-;
SYN_SENT: A [SYN] has been sent to start a connection, the SYN ACK hasn'
t yet been received.
-;
ESTABLISHED: A connection has been established
-;
CLOSE_WAIT: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]
-;
LAST_ACK: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.
-;
FIN_WAIT_1:A FIN has been sent, waiting for a ACK or FIN
-;
FIN_WAIT_2:A FIN has been sent, and an ACK has been received.
More data can be received.
This connection is half open.
-;
CLOSING:A FIN has been sent, and one received, the FIN hasn'
t been ACK'd
yet.
+<tt>
CLOSED</tt>
:
+
A theoretical state where a [TCP] connection doesn’
t exist yet.
+<tt>
LISTEN</tt>
:
+
A state where [TCP] connection is waiting for a connection to be made to it.
+<tt>
SYN_RCVD</tt>
:
+
A [SYN] has been received, a [
SYN] [
ACK]
has been sent, and we are waiting for an [ACK].
+<tt>
SYN_SENT</tt>
:
+
A [SYN] has been sent to start a connection, the [
SYN] [
ACK]
hasn’
t yet been received.
+<tt>
ESTABLISHED</tt>
:
+
A connection has been established
+<tt>
CLOSE_WAIT</tt>
:
+
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]
+<tt>
LAST_ACK</tt>
:
+
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.
+<tt>
FIN_WAIT_1</tt>
:
+
A [
FIN]
has been sent, waiting for a [
ACK]
or [
FIN]
+<tt>
FIN_WAIT_2</tt>
:
+
A [
FIN]
has been sent, and an [
ACK]
has been received. More data can be received. This connection is half open.
+<tt>
CLOSING</tt>
:
+
A [
FIN]
has been sent, and one received, the [
FIN]
hasn’
t been [
ACK]ed
yet.
+<tt>TIME_WAIT</tt>:
+ The connection has closed, and is waiting for 2MSL
-----
-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 OSes, look in /proc/sys/net/ipv4.
+!! Tuning your system’s
settings
-From
/usr/src/linux/Documentation/filesystems/proc.txt:
+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>
:
-tcp_syn_retries:
- Number of
times
initial SYNs
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 tcp_retries1.
-
-
- 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.
-
-
- Defines how
often
an
answer
to
a
TCP connection request is retransmitted
-
before giving up.
-
-
- Defines how often a TCP packet is retransmitted before giving up.
+<tt>
tcp_syn_retries</tt>
:
+ 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>
.
+<tt>
tcp_fin_timeout</tt>
:
+ 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.
+<tt>
tcp_retries1</tt>
:
+ Defines how often an answer to a [
TCP]
connection request is retransmitted before giving up.
+<tt>
tcp_retries2</tt>
:
+ Defines how often a [
TCP]
packet is retransmitted before giving up.
