Summary of TCP connection process in Linux

I,11 network connection statuses on Linux servers:

Figure: TCP State Machine

Generally, a normal TCP connection has three phases: 1. TCP three-way handshake; 2. Data Transmission; 3. TCP four-way handshake

Note: It is best to combine the following description with the "figure: TCP state machine.

SYN: (Synchronous sequence number, synchronize sequence numbers) this flag is valid only when three handshakes are used to establish a TCP connection. Indicates a New TCP connection request.

ACK: (Confirmation number, acknowledgement number) indicates the confirmation of TCP requests, and prompts that the peer system has successfully received all data.

Fin: (End sign, finish) is used to end a TCP session. However, the corresponding port is still open and is ready to receive subsequent data.

1) Listen: first, the server needs to open a socket for listening. The status is listen./* the socket is listening for incoming connections. Listen for connection requests from the remote TCP port */
2) syn_sent: the client uses the applicationProgramCall connect for active open. Therefore, the client TCP sends a SYN request to establish a connection. Then the status is set to syn_sent./* The socket is actively attempting to establish a connection. Wait for the matching connection request after sending the Connection Request */

3) syn_recv: the server should issue an ACK to confirm the SYN of the client, and send a SYN to the client. Then, the status is set to syn_recv./* A connection request has been received ed from the network. wait for confirmation of the connection request after receiving and sending a connection request */

4) Established: indicates an open connection. Both parties can interact with each other or already interact with each other./* The socket has an established connection. indicates an opened connection. data can be transmitted to the user */

5) fin_wait1: the application of the active close end calls close, so TCP sends a fin request to actively close the connection, and then enters the fin_wait1 status./* The socket is closed, and the connection is shutting down. Wait for the remote TCP connection interruption request or the confirmation of the previous connection interruption request */

6) close_wait: After the passive close end TCP receives the fin, it sends an ACK to respond to the fin request (its receipt is also passed to the upper-layer application as the file Terminator ), and enter close_wait./* The remote end has shut down, waiting for the socket to close. Wait for the connection interruption request from the local user */

7) fin_wait2: After the active shutdown end receives ACK, it enters fin-wait-2./* Connection is closed, and the socket is waiting for a shutdown from the remote end. Wait for the connection interruption request from remote tcp */

8) last_ack: After the end is passively closed for a period of time, the application receiving the file Terminator will call close to close the connection. This causes its TCP to also send a fin, waiting for the other side's ack. It enters the LAST-ACK./* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. waiting for confirmation of the connection interruption request sent to remote tcp */

9) time_wait: After the active shutdown side receives the fin, TCP sends the ACK packet and enters the time-Wait Status./* The socket is waiting after close to handle packets still in the network. Wait for enough time to ensure that the remote TCP receives the confirmation of the connection interruption request */

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

11) closed: After the passively closed end receives the ACK packet, it enters the closed status. Connection ended./* The socket is not being used. No connection status */
The formation of time_wait status only occurs on the party that closes the connection.

After receiving the fin request from the passive closing party, the active closing party changes its status from fin_wait2 to time_wait after successfully sending an ACK to the other party, and has to wait 2
Multiple MSL (maximum segment
Lifetime, MSL is the time when a datagram can exist in the Internetwork.) both parties can put the status after the time.
To close the connection. Currently, the time required to maintain the time_wait status in RHEL is 60 seconds. Of course, many of the preceding TCP statuses are explained or set in the system.
Man TCP

2. About persistent connections and short connections:
In layman's terms, a short connection is a result of a TCP request, and the connection ends immediately. the persistent connection is not immediately disconnected, but maintained until the persistent connection timeout (the specific program has related parameter descriptions ). persistent connections can avoid TCP three-way handshakes and four waves.
Long
The connection (keepalive) is maintained by the two parties continuously sending test packets. During keepalive, the TCP connection status between the server and the client is established.
In the previous HTTP 1.1 versions, keepalive is used by default (keepalive is disabled by default in version 1.0). in IE6/7/8 and Firefox, HTTP is used by default.
Version 1.1 (how to check which version is used by the current browser is not described here ). Apache, Java

Whether a short connection or persistent connection should be used for an application depends on the actual situation. Generally, persistent connections are recommended for applications.

TCP Four Waves

the TCP protocol has an elegant close mechanism, to ensure that the application does not have to worry about the loss of data being transmitted when closing the connection. As shown in the compression sample program in section 4.5, this mechanism is also designed to allow data transmission in both directions
to terminate independently of each other. The workflow of the closing mechanism is: The application indicates that the data has been sent by calling the close () method of the connection socket or the shutdownoutput () method.
at this moment, the underlying TCP implementation first transfers data stored in the sendq Queue (it also depends on the remaining space of the recvq queue at the other end ), then, send a handshake message to the other end that closes the TCP connection
. The closed handshake message can be seen as a stream termination flag: it tells the receiving end that TCP will no longer transmit new data to the recvq queue. (Note that the handshake message is not passed to the receiving
application, but is returned to indicate its position in the byte stream through the read () method .) TCP that is being disabled will wait for the confirmation message of the handshake to be closed. The confirmation message indicates that all data lost during the connection upload
has been securely transmitted to recvq. After receiving the confirmation message, the connection is in the "Half
closed" status. The connection is completely closed until the symmetric handshake message is received in the other direction of the connection. That is to say, both ends of the connection indicate that there is no data to be sent.

The closing event sequence of a TCP connection may occur in two ways: one is to call the close () method (or the shutdownoutput () method by one application first, and
One end closes the handshake message before calling the close () method. The other method is that both ends call the close () method at the same time, and their close handshake messages are transmitted across the network. Figure 6.10
The event sequence in the underlying implementation when the connection is closed in the first way. The closed handshake message has been sent, and the status of the socket data structure has been set to "Closing ".
Is "fin_wait_1"), and then close () is called to return. After these operations are completed, any read/write operations on the socket will be prohibited (an exception will be thrown ). When the handshake is closed
After the message is recognized, the status of the socket Data Structure Changes to "semi-closed" (technically called "fin_wait_2"). This status will continue until you receive the close handshake message from the other end.

The last subtle thing about closing a TCP connection is the need for the time-Wait Status. The TCP specification requires that at least one socket must be
Time-Wait status remains for a period of time. This requirement is raised because the message may be delayed during transmission in the network. If the handshake is closed at both ends of the connection, both of them remove the underlying data
In this case, a new connection is established between the same pair of socket addresses, so the delayed message of the previous connection during network upload and transmission may arrive after the new connection is established. Because it contains the same source address
And the target address, the old message will be mistakenly considered to be a new connection, and the data contained in it may be mistakenly allocated to the application.

Although this situation may rarely happen, TCP uses a variety of mechanisms, including the time-Wait Status, to prevent it. Time-Wait Status is used to ensure that every TCP connection has
End in a period of calm, during which no data is sent. The length of the calm time should be twice the maximum retention time of the packet on the network. Therefore, when a connection ends completely (that is, the socket data is closed
After the time-Wait Status is created and deleted, and a new connection on the same address is cleared, no messages sent from the old instance remain in the network. In fact, the length of Calm time is
Depending on the specific implementation, because there is no mechanism to really limit the delay time of grouped packets on the network. Generally, the time range is 4 minutes to 30 seconds, or shorter.

The most important role of the Time-Wait Status is that as long as the underlying socket data structure still exists, it is not allowed to associate other sockets on the same local port. In particular, an ioexception is thrown when you try to use this port to create a new socket instance.

 

TCP three-way handshake/four-way handshake

1. Establish a connection protocol (three-way handshake)
(1) the client sends a TCP packet with SYN flag 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 sign. 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 agreement (four waves)

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 terminate the connection in this direction. Receive
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 client 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 state, indicating that a socket on the server is in the listening state and can accept connections.

Syn_rcvd:

This status indicates that the SYN packet 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 short and basic.
It is difficult for you to see this status with netstat unless you write a client test program and deliberately disable the last ACK packet from the three TCP handshakes. So this status
When receiving the ACK packet from the client, it enters 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 enters the syn_sent state.
And wait for the server to send the 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:

In fact, the true meanings of fin_wait_1 and fin_wait_2 indicate waiting for the fin message of the other party. The difference between the two states
Yes: The fin_wait_1 status is actually when the socket is in the established status, it wants to take the initiative to close the connection and send the FIN packet to the other party. At this time, the socket is
Enter the fin_wait_1 status. When the other Party responds to the ACK packet, it enters the fin_wait_2 state. Of course, under normal circumstances, regardless of the other party's circumstances
So the fin_wait_1 status is generally difficult to see, while the fin_wait_2 status is often 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:

It indicates that the other party's FIN packet is received, and the ACK packet is sent concurrently. After 2msl is sent, it can return to the available state of closed. If fin_wait_1 is in the fin_wait_1 status
The fin and ACK packets can directly enter the time_wait status without passing through the fin_wait_2 status.

Closing:

This status is special and should be rare in actual situations. It is a rare exception status. Normally, when you send a fin message, you should first (or simultaneously) receive the other party's
ACK packets, and then receive the FIN packets 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. What
In this case? In fact, it is not difficult to come to the conclusion that if both parties close a socket almost simultaneously, then both parties send a fin message at the same time.
The closing status indicates that both parties are closing the socket connection.

Close_wait:

The meaning of this state is actually that it is 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
And then enters the close_wait status. Next, you actually need to check whether you have any data to send to the other party. If not, you can
Close this socket, 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 a side and waits for the other side's ACK packet after sending the fin message. After receiving the ACK message, you can enter the closed available status.

Finally, I have two answers, and I have analyzed the results (not necessarily 100% correct ):

1. Why is the connection established protocol three-way handshake, while closing the connection is four-way handshake?
This is because the socket in the listen state of the server can respond to ack and Syn (ACK) After receiving the SYN Packet connection request, SYN acts as a synchronization function) is sent in a
packet. However, when the connection is closed, when the other party receives the fin Message notification, it only indicates that the other party has no data to send to you; but not all your data may have been sent to the other party, so you can close the socket immediately without
, that is, you may need to send some data to the other party, if you send another FIN packet to the other party, you agree that the connection can be closed now. Therefore, the ACK packets
and FIN packets are sent separately in most cases.

2. Why does the time_wait status still need to be 2 MSL before it can be returned to the closed status?
This is because, although both parties agree to disable the connection, the four handshake packets are also coordinated and sent, it can be directly returned to the closed state (just like from syn_send to
establish State), but because we must assume that the network is unreliable, you cannot guarantee that the last ACK packet will be received by the other party. Therefore, the socket in the
last_ack status of the other party may resend the FIN packet because it does not receive the ACK packet due to timeout, therefore, the time_wait status is used to resend potentially lost
ACK packets.