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

In normal operation and maintenance of the server, you need to view various connection states, so you must be very familiar with TCP connection states to know the meaning of each state; only by knowing the meaning of these parameters can you optimize accordingly.

View Status Command:

[root@tomcat10 logs]# netstat -na | awk '/^tcp/{s[$6]++}END{for(key in s) print key,s[key]}'TIME_WAIT 1443CLOSE_WAIT 1122SYN_SENT 3FIN_WAIT1 2074FIN_WAIT2 195ESTABLISHED 89782SYN_RECV 7314LISTEN 9CLOSING 9LAST_ACK 2372

The meaning of each state is as follows:

LISTEN: indicates that the TCP port for listening has been opened;

SYN_SENT: The state of the client after sending the connection establishment (SYN) request;

SYN_RECV: The state after the server sends SYN+ACK after receiving SYN request to establish connection;

ESTABLISHED: the state of the client after sending ACK, the state of the server after receiving ACK, and the connection is formally established at this time;

FIN_WAIT1: status of client after sending FIN;

CLOSE_WAIT: status after the server receives a FIN request from the client and sends an ACK to FIN;

FIN_WAIT2: status after receiving ACK to previous FIN sent by server;

LAST_ACK: status after the server processes the last data and sends FIN;

TIME_WAIT: status after receiving FIN sent by the server, indicating that it is in idle waiting stage;

CLOSED: status after sending ACK to FIN after TIME_WAIT time arrives, after sending ACK indicates that the connection has been closed;

CLOSING: The state of the connection when both parties send a close request and an acknowledgement simultaneously;

The three-way handshake and the four-way disconnection flow diagram:

More intuitive flow diagram:

About four disconnections:

a. First, the client sends a FIN to the server requesting to turn off data transmission.

b. When the server receives FIN from the client, it sends an ACK to the client, where the value of ack is equal to FIN+SEQ

The server then sends a FIN to the client telling the client to close the application.

d. When the client receives a FIN yes from the server, it replies with an ACK to the server. where ack equals FIN+SEQ

Why does it take four times to disconnect?

a. Ensure that data can be transmitted.

b. When the connection is closed, when receiving the FIN message notification from the other party, it only indicates that the other party has no data to send to you;

c. But not all of your data is sent to the other party, so you may not close SOCKET immediately, that is, you may need to send some data to the other party later.

d. Send FIN message to the other party to indicate that you agree to close the connection now, so ACK message and FIN message here are sent separately in most cases.

Let's take a look at the three TCP states that everyone is generally concerned about:

SYN_RECV:

The server is in SYN_RECV state when it receives SYN packet for establishing connection but does not receive ACK packet. There are two related system configurations:

1. net.ipv4.tcp_synack_retries --> Default is 5

For far end SYN connection requests, the kernel sends a SYN + ACK datagram acknowledging receipt of the previous SYN connection request packet. This is the second step of the so-called three-way handshake mechanism. This determines the number of SYN+ ACKs the kernel sends before dropping the connection. It should not be greater than 255, the default value is 5, corresponding to about 180 seconds. Usually we don't change this value because we want TCP connections not to fail because of occasional packet loss.

2. net.ipv4.tcp_syncookies --> Default is 1

Most servers set net.ipv4.tcp_syncookies=1 to prevent SYN Flood***. Suppose a user suddenly crashes or drops the line after sending a SYN message to the server, then the server cannot receive the ACK message from the client after sending a SYN+ACK response message.(The third handshake cannot be completed), in which case the server will retry (send SYN+ACK to the client again) and wait for a period of time before dropping the incomplete connection. This period of time is called SYN Timeout, which is usually on the order of minutes (about 30 seconds-2 minutes).

These TCP connections at SYNC_RECV are called semi-connections and stored in the kernel's semi-connection queue. When the kernel receives an ack packet sent by the peer, it will look up the semi-connection queue and store the matching requst_sock information in the queue of the connection that completes the three-way handshake, and then delete this semi-connection. A large number of SYNC_RECV TCP connections will cause the semi-connection queue to overflow, so that subsequent connection establishment requests will be directly discarded by the kernel, which is SYN Flood***.

One of the ways to prevent SYN Flood*** is SYN Cookie. SYN Cookie principle is derived from D. J. Bernstain and Eric Schenk. SYN Cookie is a means of modifying the TCP server-side three-way handshake protocol to prevent SYN Flood***. The idea 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 validity of the TCP ACK packet based on that cookie value. If legal, allocate a dedicated data area to handle future TCP connections.

The number of SYN_RECV connections on the observation service is 7314, which is normal for a server with high concurrency.

CLOSE_WAIT

The party that initiates TCP connection closure is called client, and the party that passively closes is called server. The TCP state of a passively closed server that receives FIN but does not send ACK is CLOSE_WAIT. This is usually due to server-side code problems, and if you have a lot of CLOSE_WAIT on your server, you should consider checking the code.

TIME_WAIT

According to the TCP protocol definition of 3-way handshake disconnection rule, the party initiating socket active closure socket will enter the TIME_WAIT state. The TIME_WAIT state lasts 2 MSL(Max Segment Lifetime), which defaults to 4 minutes on Windows, or 240 seconds. A socket in TIME_WAIT state cannot be recycled. The specific phenomenon is that for a server that handles a large number of short connections, if the server actively closes the client's connection, it will cause a large number of sockets in the TIME_WAIT state on the server side, even more than the sockets in the Established state, seriously affecting the processing capacity of the server, and even exhausting the available sockets and stopping the service.

Why Time_WAIT? TIME_WAIT is a necessary logical guarantee of TCP protocol to ensure that redistributed sockets will not be affected by the residual delayed retransmission messages.

The system parameters related to TIME_WAIT status are generally 3, and the 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, reduce this value to speed up system shutdown of TCP connections in FIN_WAIT2 state, recommended value is 30.

net.ipv4.tcp_tw_reuse = 1 means reuse is enabled. Allow TIME-WAIT sockets to be reused for new TCP connections. Default is 0, which means closed.

net.ipv4.tcp_tw_recycle = 1 indicates that TIME-WAIT sockets in TCP connections are quickly recycled, and the default is 0, indicating that they are disabled.

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.