Solve the problem of excessive TCP connections

1. Establish a connection protocol (three-way handshake)
(1) the client sends a TCP packet with a SYN sign to the server. This is packet 1 during the three-way handshake.

(2) The server responds to the client. This is the first packet in the three-way handshake. This packet carries both the ACK mark and SYN mark. Therefore, it indicates the response to the client SYN Packet. It also marks the SYN message to the client and asks whether the client is ready for data communication.

(3) The customer must re-respond to an ACK packet in the service segment, which is packet segment 3.

2. Connection termination protocol (four handshakes)
Because the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes its data sending task, it can send a fin to end the connection in this direction. Receiving a fin only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a fin. First, the party that closes the service will take the initiative to close the service, and the other party will passively close the service.

(1) The tcp client sends a fin to disable data transmission from the customer to the server (packet segment 4 ).
(2) When the server receives the fin, it sends back an ACK and confirms that the serial number is 1 (packet segment 5 ). Like SYN, a fin occupies a sequence number.
(3) The server closes the client connection and sends a fin to the client (packet segment 6 ).
(4) The customer segment sends back the ACK message for confirmation, and sets the confirmation sequence number to receive the serial number plus 1 (packet segment 7 ).

Closed: this is nothing to say, indicating the initial state.

Listen: this is also an easy-to-understand status, indicating that a socket on the server is in the listening status and can accept connections.

Syn_rcvd: this status indicates that the SYN message is received. Normally, this status is an intermediate status of the server socket during the three-way handshake session when a TCP connection is established. It is very short, basically, you can hardly see this state with netstat unless you write a client to testProgramThe last ACK packet in the three TCP handshakes will not be sent. Therefore, when an ACK packet from the client is received
It will enter the established status.

Syn_sent: this status echo syn_rcvd. When the client socket executes the connect connection, it first sends the SYN packet, and then it enters the syn_sent status, and wait for the server to send 2nd messages in the three-way handshake. Syn_sent status indicates that the client has sent Syn packets.

Established: This is easy to understand, indicating that the connection has been established.

Fin_wait_1: the real meaning of fin_wait_1 and fin_wait_2 indicate waiting for the other party's Fin message. The difference between the two States is that the fin_wait_1 state is actually when the socket is in the established State, it wants to actively close the connection and send a FIN packet to the other party, the socket enters the fin_wait_1 state. When the other Party responds to the ACK message, it enters the fin_wait_2 status. Of course, in the actual normal situation
Regardless of the situation, the other party should immediately respond to the ACK packet, so the fin_wait_1 status is generally difficult to see, while the fin_wait_2 status can often be seen using netstat.

Fin_wait_2: The above has explained in detail this status. In fact, the socket in the fin_wait_2 status indicates a semi-connection, that is, either party requires a close connection, but also tells the other party, I have some data to send to you, and close the connection later.

Time_wait: indicates that the other party's Fin message is received, and the ACK message is sent concurrently, so that 2msl can return to the closed available status. If fin_wait_1 receives a message with both the fin tag and ACK flag, it can directly enter the time_wait status without passing through the fin_wait_2 status.

Closing: this is a special exception that is rare in actual situations. Under normal circumstances, when you send a FIN packet, it is reasonable to first receive (or simultaneously receive) the ACK packet from the other party and then receive the FIN packet from the other party. However, the closing status indicates that after you send the FIN packet, you have not received the ACK packet from the other party, but have also received the FIN packet from the other party. Under what circumstances will this happen? In fact, it is not difficult to come to the conclusion that if both parties close
If both parties send FIN packets at the same time, the closing status will appear, indicating that both parties are closing the socket connection.

Close_wait: the meaning of this state is actually waiting to be closed. How can this problem be solved? When the other party closes a socket and sends a FIN packet to itself, your system will undoubtedly respond to an ACK packet to the other party, and then enters the close_wait status. Next, in fact, what you really need to consider is to check if you still have data to send to the other party. If not, you can close the socket and send the FIN packet to the other party, that is, close the connection. So what you need to do in close_wait is to wait for you to close the connection.

Last_ack: this status is easy to understand. It passively closes the ACK packet sent by one party and waits for the other party after sending the fin message. After receiving the ACK message, you can enter the closed available status.

There are a lot of close_wait examples and solutions on the server (the example is found on the internet, basically similar)

Oracle9i @ rhel3 Oracle9i] $/usr/sbin/lsof-I | grep 6800
Oracle 22725 Oracle9i 3u IPv4 18621468 TCP rhel3: 6800 (Listen)
Oracle 22725 Oracle9i 4u IPv4 18621469 TCP rhel3: 6800-> rhel3: 2174 (close_wait)
Oracle 22725 Oracle9i 8u IPv4 18621568 TCP rhel3: 6800-> rhel3: 2175 (close_wait)
Oracle 22725 Oracle9i 9u IPv4 18621578 TCP rhel3: 6800-> rhel3: 2176 (close_wait)
Oracle 22726 Oracle9i 3u IPv4 18621468 TCP rhel3: 6800 (Listen)
Oracle 22726 Oracle9i 4u IPv4 18621469 TCP rhel3: 6800-> rhel3: 2174 (close_wait)
Oracle 22726 Oracle9i 8u IPv4 18621568 TCP rhel3: 6800-> rhel3: 2175 (close_wait)
Oracle 22726 Oracle9i 9u IPv4 18621578 TCP rhel3: 6800-> rhel3: 2176 (close_wait)

[Oracle9i @ rhel3 Oracle9i] $ kill-9 22725

#22725,227 26 is the process number (PID) that uses port 6800 ).
[Oracle9i @ rhel3 Oracle9i] $/usr/sbin/lsof-I | grep 6800

When a process is killed, all the link handles occupied are released.

The cause of this problem is everywhere on the Internet, that is, the client of the socket exits if there is an exception and no close occurs.
// The above statement is not accurate. It should be that the connection end is closed passively without closesocket, and the end is in close_wait state when the connection end is closed passively.