Talk about the experience of communication system "one" TCP connection state analysis: sync_recv,close_wait,time_wait

Excerpt from: http://maoyidao.iteye.com/blog/1744277

During the interview, I was asked to ask a question, TCP has a few handshake to establish the connection. More than 95% of the candidates can get the correct answer 3 times. It takes a few handshakes to get a TCP disconnect, and 70% of the candidates are able to communicate 4 times correctly. Again ask Close_wait,time_wait is what state, how produces, to the service has what influence, how to eliminate. A part of the students can not answer. Not that I buckle the details, but on the communications-oriented front-end server, you must be able to handle a variety of TCP states. For example, statistics on a front-end machine in the factory peak time TCP connection, statistics command:

Linux Shell Code Netstat-n | awk '/^tcp/{++s[$NF]} end {for (a in S) print A, s[a]} '

Results:

In addition to established, you can see a number of connections in several states are: Fin_wait1, time_wait, close_wait, Syn_recv and Last_ack; The following article gives the conditions for these states, A brief description of the impact of the system and how it is handled.

TCP Status

The TCP status is shown in the following illustration:

Might be a little dazzled. And look at this timeline.

Below look at everybody general more concern three kinds of TCP state SYN_RECV

The service side received a SYN-connection that was in Syn_recv state when the ACK packet was not received. There are two related system configurations:

1,net.ipv4.tcp_synack_retries:integer

The default value is 5

For a remote connection request SYN, the kernel sends a SYN + ACK datagram to confirm receipt of the last SYN connection request package. This is the second step of the so-called three-time handshake (threeway handshake) mechanism. This determines the number of Syn+ack the kernel sends out before abandoning the connection. should not be greater than 255, the default value is 5, corresponding to 180 seconds or so. Usually we do not modify this value because we want the TCP connection not to be created because of occasional packet loss. 2,net.ipv4.tcp_syncookies

The general server will set up Net.ipv4.tcp_syncookies=1 to prevent SYN flood attacks. If a user sends a SYN message to the server and suddenly freezes or drops the line, then the server is unable to receive the client's ACK message after sending the Syn+ack answer message (the third handshake cannot be completed), in which case the server side will generally try again (send again syn+ ACK to the client) and wait for a while to discard this unfinished connection, the length of which we call the Syn Timeout, which is generally the order of magnitude of the minute (approximately 30 seconds-2 minutes).

These TCP connections in SYNC_RECV are called semi-connections and are stored in a semi-connected queue in the kernel, where the kernel receives an ACK packet that is sent to the end, finds the semi connected queue, stores the matched Requst_sock information in the queue of the connection that completes the three handshake, and then deletes the half connection. A large number of SYNC_RECV TCP connections can cause a half-open queue to overflow, so subsequent connection-creation requests are discarded by the kernel, which is the SYN flood attack.

One of the means to effectively prevent SYN flood attacks is the Syn Cookie. SYN Cookie Original Reason d. J. Bernstain and Eric Schenk invented it. The SYN cookie is a modification of the three handshake protocol on the TCP server side, which is specifically designed to prevent SYN flood attacks. The rationale is that when a TCP server receives a TCP SYN packet and returns a TCP Syn+ack packet, it does not allocate a dedicated data area, but calculates a cookie value based on the SYN packet. When a TCP ACK packet is received, the TCP server checks the legality of the TCP ACK packet against that cookie value. If it is legal, then assign a dedicated data area to handle future TCP connections.

Observation service on the number of SYN_RECV connections: 7314, for a high concurrent connection of the communication server, this number is relatively normal.
close_wait

A party that initiates a TCP connection shutdown is called a client, and the passive shutdown side is called the server. The passive shutdown server receives the FIN, but the TCP state that does not issue an ACK is close_wait. This situation is generally due to server-side code problems, if you have a large number of close_wait on the server, you should consider checking the code. time_wait

According to the TCP protocol defined by the 3 handshake disconnect rule, initiates the socket active shutdown side socket will enter the TIME_WAIT state. The TIME_WAIT state will last 2 MSL (Max Segment Lifetime), and the default is 4 minutes, or 240 seconds, under Windows. The socket in the TIME_WAIT state cannot be recycled. The specific phenomenon is for a large number of short connected servers, if the server is actively shut down the client connection, will lead to a large number of servers in the TIME_WAIT state of the socket, or even more than in the established state of the socket more, Seriously affect the processing power of the server, even exhausted the available sockets, stop the service.

Why need time_wait. Time_wait is a necessary logical guarantee that the TCP protocol is used to ensure that the reassigned socket will not be affected by the previously remaining delay redistribution.

and time_wait state-related system parameters are generally 3, factory settings are as follows:

Net.ipv4.tcp_tw_recycle = 1

Net.ipv4.tcp_tw_reuse = 1

Net.ipv4.tcp_fin_timeout = 30

Net.ipv4.tcp_fin_timeout, default 60s, reduces fin_timeout, reduces the number of time_wait connections.

Net.ipv4.tcp_tw_reuse = 1 means to turn on reuse. Allows time-wait sockets to be re used for a new TCP connection, which defaults to 0, indicating shutdown;

Net.ipv4.tcp_tw_recycle = 1 is a quick recycle of time-wait sockets on a TCP connection, and the default is 0, which means shutdown.

Next: http://maoyidao.iteye.com/blog/1744309 "communication system Experience" two "interpretation of kernel parameters-socket/file handle resource constraint parameters" will introduce the other options in our network-related settings, In particular, the kernel configuration associated with system resource constraints.

Size: 22.7 KB size: 108.9 KB size: 217 kb