11 states of a TCP connection

Turn from: http://liujianguangaaa.iteye.com/blog/975445

11 Network connection status on Linux server

State Machine for TCP

Normally: a normal TCP connection, there will be three stages: 1, TCP three handshake; 2, data transmission; 3, TCP four times wave

Note: The following instructions are best combined with the "Diagram: TCP state Machine" to understand.

SYN: (Synchronization sequence number, Synchronize Sequence Numbers) This flag is valid only when a TCP connection is established with a three handshake. Represents a new TCP connection request.

ACK: (Acknowledgement number) is the confirmation flag for the TCP request and prompts the End-to-end system to receive all data successfully.

FIN: (End mark, finish) to end a TCP reply. However, the corresponding port is still open and ready to receive subsequent data.

1), LISTEN: First, the server needs to open a socket for listening, the status of LISTEN. /* The socket is listening for incoming connections. Listening for connection requests from a remote TCP port/*

2), Syn_sent: The client calls connect through the application for active open. The client TCP sends a SYN to request a connection. The state is then set to Syn_sent. /*the socket is actively attempting to establish a connection. Wait for a matching connection request after sending a connection request * *

3), SYN_RECV: The server should issue an ACK to confirm the client's SYN, at the same time send a SYN to the client. The status is then set to SYN_RECV/* A connection request has been received from the network. Wait for confirmation of connection request after receiving and sending a connection request * *

4, established: on behalf of an open connection, both sides can or have been in the data interaction. /* The socket has an established connection. Represents an open connection in which data can be transmitted to the user.

5), fin_wait1: active shutdown (active close) end application calls Close, so its TCP sends a FIN request to shut down the connection actively, then enter the FIN_WAIT1 state./* The socket is closed, And the connection is shutting down. Wait for a connection interrupt request from a remote TCP, or a confirmation of a previous connection interrupt request * *

6), close_wait: passive shutdown (passive close) End TCP receives the FIN, an ACK is issued to respond to the fin request (its reception is also passed as a file terminator to the upper application) and into close_wait. /* The remote end has shut down and waiting for the socket to close. Waiting for a connection interrupt request from a local user * *

7), Fin_wait2: active close to receive an ACK, it entered the fin-wait-2./* Connection is closed, and the socket is waiting for a shutdown from T He's remote end. Waiting for connection interrupt request from remote TCP */

, Last_ack: after a passive shutdown for a period of time, the application that receives the end of the file will call the close shutdown connection. This causes its TCP to also send a FIN, waiting for the other's ACK. It's in the Last-ack. /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. Wait for confirmation that the connection interrupt request originally sent to remote TCP.

9), time_wait: in the active closed-end received fin, TCP sent ACK packets, and into the time-wait state. /* The socket is waiting after closing to handle packets still the network. Wait enough time to ensure that remote TCP receives a confirmation of a connection interrupt request * *

10), CLOSING: relatively rare./* Both sockets are shut down but we still don ' t have all our data sent. Wait for a remote TCP to confirm the connection interruption

11), CLOSED: the passive closed end after receiving the ACK packet, entered the CLOSED state. The connection ends./* The socket is not being used. No Connection Status * *

The formation of the TIME_WAIT state occurs only on the active shutdown side of the connection.

The active close party receives the passive close side's fin request, sends succeeds to each other after sending a ACK, changes own state from Fin_wait2 to time_wait, but must wait twice times the MSL (Maximum Segment Lifetime, The MSL is the time that a datagram can exist in internetwork after which both sides can change the state to closed to close the connection. At present, the time to maintain time_wait state in Rhel is 60 seconds.

Of course, many of the above TCP states in the system have a corresponding interpretation or settings, visible man TCP

second, about long connection and short connection:

Popular point: A short connection is the result of a TCP request, the connection ends immediately. The long connection is not immediately disconnected, and has been maintained until the long connection timeout (the specific procedures are related to the parameters described). Long connections avoid the constant TCP three handshake and four wave waving.

Long connection (keepalive) is required by both sides of the continuous sending probe packets to maintain, keepalive during the server and client TCP connection status is established. Currently, the HTTP 1.1 version of the default is KeepAlive ( The 1.0 version is not keepalive by default, IE6/7/8 and Firefox are all by default HTTP 1.1 version (how to see which version of the current browser is used, here no longer repeat). Apache,java

An application as to whether the use of short or long connection, should depend on the specific circumstances. A general application should use long connections.

1, the related keepalive parameters of Linux

A, Tcp_keepalive_time–integer
How to often TCP sends out keepalive messages when KeepAlive is enabled.
Default:2hours.

B, Tcp_keepalive_probes–integer
How to many keepalive probes TCP sends out, until it decides
Connection is broken. Default Value:9.

C, Tcp_keepalive_intvl–integer
How to frequently the probes are send out. multiplied by
Tcp_keepalive_probes It is time to kill not responding connection,
After probes started. Default value:75sec i.e. connection
Would be aborted after ~11 minutes of retries.

2, F5 load balance on the relevant parameter description

A, Keep Alive Interval

Specifies, when enabled, how frequently the system sends data over a idle TCP connection, to determine whether the Connec tion is still valid.

Specify:specifies the interval at which's system sends data over a idle connection, to determine whether n is still valid. The default is 1800 milliseconds.

B, Time wait

Specifies the length of time this a TCP connection remains in the Time-wait state before the entering state.

Specify:specifies the number of milliseconds that a TCP connection can remain to the time-wait state. The default is 2000.

C, Idle Timeout

Specifies the length of time this a connection is idle (has no traffic) before the connection was eligible for deletion.

Specify:specifies a number of seconds that the TCP connection can remain idle before the system deletes it. The default is seconds.

3, the Apache related parameter explanation

The following are the default parameters and descriptions for the apache/2.0.61 version

A, KeepAlive:

Default On.whether or Allow persistent connections (more than

One request per connection). Set to ' off ' to deactivate.

B, Maxkeepaliverequests:

Default 100.The maximum number of requests to allow

During a persistent connection. Set to 0 to allow an unlimited amount.

We recommend you the leave this number is high and for maximum performance.

C, KeepAliveTimeout:

Default 15. Number of seconds to the next request from the

Same client on the same connection.

4, JAVA1.6 related parameter description:

A, http.keepalive=<boolean>
Default:true

Indicates if keep alive (persistent) connections should be supported.

B, http.maxconnections=<int>
Default:5

Indicates the maximum number of connections/destination to is kept alive at no given time

11 Network connection status on Linux server

State Machine for TCP

Normally: a normal TCP connection, there will be three stages: 1, TCP three handshake; 2, data transmission; 3, TCP four times wave

Note: The following instructions are best combined with the "Diagram: TCP state Machine" to understand.

SYN: (Synchronization sequence number, Synchronize Sequence Numbers) This flag is valid only when a TCP connection is established with a three handshake. Represents a new TCP connection request.

ACK: (Acknowledgement number) is the confirmation flag for the TCP request and prompts the End-to-end system to receive all data successfully.

FIN: (End mark, finish) to end a TCP reply. However, the corresponding port is still open and ready to receive subsequent data.

1), LISTEN: First, the server needs to open a socket for listening, the status of LISTEN. /* The socket is listening for incoming connections. Listening for connection requests from a remote TCP port/*

2), Syn_sent: The client calls connect through the application for active open. The client TCP sends a SYN to request a connection. The state is then set to Syn_sent. /*the socket is actively attempting to establish a connection. Wait for a matching connection request after sending a connection request * *

3), SYN_RECV: The server should issue an ACK to confirm the client's SYN, at the same time send a SYN to the client. The status is then set to SYN_RECV/* A connection request has been received from the network. Wait for confirmation of connection request after receiving and sending a connection request * *

4, established: on behalf of an open connection, both sides can or have been in the data interaction. /* The socket has an established connection. Represents an open connection in which data can be transmitted to the user.

5), fin_wait1: active shutdown (active close) end application calls Close, so its TCP sends a FIN request to shut down the connection actively, then enter the FIN_WAIT1 state./* The socket is closed, And the connection is shutting down. Wait for a connection interrupt request from a remote TCP, or a confirmation of a previous connection interrupt request * *

6) , close_wait: passive shutdown (passive close) End TCP receives the FIN, an ACK is issued to respond to the fin request (its reception is also passed as a file terminator to the upper application) and into close_wait. /* The remote end has shut down and waiting for the socket to close. Waiting for a connection interrupt request from a local user * *

7) , Fin_wait2: The active close end receives an ACK, enters the fin-wait-2./* Connection is closed, and the socket is waiting for a shutdown from the Remote end. Waiting for connection interrupt request from remote TCP */

, Last_ack: after a passive shutdown for a period of time, the application that receives the end of the file will call the close shutdown connection. This causes its TCP to also send a FIN, waiting for the other's ACK. It's in the Last-ack. /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. Wait for confirmation that the connection interrupt request originally sent to remote TCP.

9) , time_wait: after the active shutdown to receive fin, TCP sends ACK packets, and into the time-wait state. /* The socket is waiting after closing to handle packets still the network. Wait enough time to ensure that remote TCP receives a confirmation of a connection interrupt request * *

10),CLOSING: relatively rare./* Both sockets are shut down but we still don ' t have all our data sent. Wait for a remote TCP to confirm the connection interruption

One ) , CLOSED: The passive closed end receives the ACK package and enters the CLOSED state. The connection ends./* The socket is not being used. No Connection Status * *

The formation of the TIME_WAIT state occurs only on the active shutdown side of the connection.

The active close party receives the passive close side's fin request, sends succeeds to each other after sending a ACK, changes own state from Fin_wait2 to time_wait, but must wait twice times the MSL (Maximum Segment Lifetime, The MSL is the time that a datagram can exist in internetwork after which both sides can change the state to closed to close the connection. At present, the time to maintain time_wait state in Rhel is 60 seconds.

Of course, many of the above TCP states in the system have a corresponding interpretation or settings, visible man TCP

second, about long connection and short connection: