Shulou(Shulou.com)06/01 Report--

How to analyze Linux TCP status TIME_WAIT too much to deal with, in view of this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

First of all, to deal with this problem, we need to know some network knowledge and tcp things, such as three handshakes and four waves. Many people will ask, why do you need 3 handshakes to build links and 4 waves to break links?

First, there is a three-way handshake:

First, the client sends a connection request message, and the Server segment replies to the ACK message after accepting the connection, and allocates resources for the connection. After receiving the ACK message, the Client terminal also sends the ACK message to the Server segment and allocates resources, so that the TCP connection is established.

Data can be transferred between the two.

Again, break the link below:

[note] the end of the disconnection can be Client or Server.

Suppose the client initiates a request to disconnect, that is, to send a FIN message. When Server receives the FIN message, it means "I have no data to send to you on Client", but if you still have data to send, you don't have to close Socket in a hurry, you can continue to send data. So you send ACK first, "tell the client that I have received your request, but I am not ready, please continue to wait for my message." At this time, the Client side enters the FIN_WAIT state and continues to wait for the FIN message on the server side. When the Server side determines that the data has been sent, it sends a FIN message to the client side, "tell the client side, all right, I have finished sending the data, and I am ready to close the connection." After receiving the FIN message, the Client side "knows that the connection can be closed, but he still does not trust the network, for fear that the Server side does not know to shut it down, so it enters the TIME_WAIT state after sending the ACK. If the Server side does not receive the ACK, it can retransmit it." When the server receives the ACK, it "knows it's ready to disconnect". After waiting for 2MSL, the Client still does not receive a reply, which proves that the Server has been shut down normally. Well, my Client can also close the connection. The Ok,TCP connection is closed!

So it can be understood that when client enters time_wait, the waiting time is 2 MSL.

Let's take a look at the network status of a linux server:

# netstat-an | awk'/ ^ tcp/ {+ + State [$NF]} END {for (key in State) print key "\ t" State [key]}'

LAST_ACK 7

LISTEN 9

SYN_RECV 2

CLOSE_WAIT 125

ESTABLISHED 1070

FIN_WAIT1 17

FIN_WAIT2 247

CLOSING 4

TIME_WAIT 25087

For websites, such time_wait is slightly too high, which means that a large number of shutdown operations end after waiting for 2 MSL. Normally, our tcp port is 65535. If the concurrency is higher, a large number of socket may not be released in time, resulting in performance degradation, so we can make some network adjustments through the linux kernel, such as enabling socket reuse and fast recycling:

Net.ipv4.tcp_syncookies = 1

Net.ipv4.tcp_tw_reuse = 1

Net.ipv4.tcp_tw_recycle = 1

Net.ipv4.tcp_max_tw_buckets = 5000

Net.ipv4.tcp_max_syn_backlog = 8192

Net.ipv4.tcp_keepalive_time = 1200

Net.ipv4.ip_local_port_range = 1024 65000

Net.ipv4.tcp_syncookies = 1

Indicates that SYN Cookies is enabled. When a SYN waiting queue overflow occurs, enable cookies to deal with it to prevent a small number of SYN attacks. The default is 0, which means it is turned off.

Net.ipv4.tcp_tw_reuse = 1

Indicates that reuse is enabled. Allow TIME-WAIT sockets to be reused for new TCP connections. Default is 0, which means off.

Net.ipv4.tcp_tw_recycle = 1

Means to enable fast recycling of TIME-WAIT sockets in TCP connections. Default is 0, which means disabled.

System tcp_timestamps is on by default, so when tcp_tw_recycle is turned on, this behavior is actually activated. If the server is in a NAT environment, tcp_tw_recycle is usually disabled for security reasons, and the problem of too many TIME_WAIT connections can be alleviated by activating tcp_tw_reuse.

Net.ipv4.tcp_max_tw_buckets = 5000

Indicates that the system maintains the maximum number of TIME_WAIT sockets at the same time, and if this number is exceeded, the TIME_WAIT socket will be cleared immediately and a warning message will be printed. The default is 180000, which changes to 5000. For servers such as Apache, Nginx, and so on, the parameters in the first few lines can well reduce the number of TIME_WAIT sockets, but it has little effect on Squid. This parameter controls the maximum number of TIME_WAIT sockets to prevent the Squid server from being dragged to death by a large number of TIME_WAIT sockets.

Net.ipv4.tcp_max_syn_backlog = 8192

Indicates the length of the SYN queue, which defaults to 1024, and increases the queue length to 8192, which can accommodate more network connections waiting for connections.

Net.ipv4.tcp_keepalive_time = 1200

Indicates the frequency at which keepalive sends keepalive messages when TCP is activated. The default is 2 hours, which changes to 20 minutes.

Net.ipv4.ip_local_port_range = 1024 65000

Represents the range of ports used for outbound connections. Small by default: 32768 to 61000, changed to 1024 to 65000.

# netstat-an | awk'/ ^ tcp/ {+ + State [$NF]} END {for (key in State) print key "\ t" State [key]}'

LAST_ACK 140

LISTEN 9

SYN_RECV 7

CLOSE_WAIT 2

ESTABLISHED 972

FIN_WAIT1 21

FIN_WAIT2 152

CLOSING 2

TIME_WAIT 682 on how to analyze the status of Linux TCP TIME_WAIT too many questions to share here, I hope the above content can be of some help to you, if you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.