TCP three-way handshake (establish connection)/four-way handshake (close connection)

Compared with socket developers, the TCP creation and link Division processes are automatically created by the TCP/IP protocol stack. therefore, developers do not need to control this process. however, it is helpful to understand the underlying TCP operation mechanism.

In addition, a written examination such as a network protocol engineer is almost mandatory. the enthusiasm of the company for this issue is beyond my expectation :-). This problem is sometimes emphasized before the interview in the morning and repeated once. In the afternoon, almost everyone is asked this question. So here we will explain these two processes in detail. TCP three-way handshake refers to the three packets sent by the client and server when a TCP connection is established. The purpose of the three-way handshake is to connect to the specified port of the server, establish a TCP connection, synchronize the serial numbers and validation numbers of both parties, and exchange the TCP window size information. in socket programming, when the client executes connect. Three handshakes are triggered.

• First handshake:
  
  The client sends a packet with tcp syn flag position 1, indicating the port of the server to which the customer intends to connect, and the initial serial number X, which is saved in the sequence number field of the packet header.

• The second handshake:
  
  The server sends back the ACK response. That is, the SYN flag and ACK flag are both 1, and the acknowledgement number is set to the customer's I S N plus 1 to. x + 1.

• The third handshake.
  
  The client resends the ack syn flag to 0 and the ACK flag to 1. in addition, the serial number field + 1 sent from the server is placed in the confirmation field and sent to the other party. and write the ISN's + 1 in the data segment.

Syn Attack

During the three-way handshake, after the server sends the SYN-ACK, the TCP connection before receiving the ACK from the client is called a semi-connection (half-open Connect ). the server is in the syn_recv status. when Ack is received, the server is transferred to the established status.

SYN attacks are attacks on clients that forge a large number of nonexistent IP addresses in a short period of time. They constantly send Syn packets to the server. The server replies to the confirmation packet and waits for the customer to confirm that the source address does not exist, the server needs to continuously resend to timeout. These forged Syn packets will occupy the unconnected queue for a long time, normal SYN requests will be discarded, and the target system will run slowly, serious cases may cause network congestion or even system paralysis.

SYN attack is a typical DDOS attack. It is very convenient to detect SYN attacks. When you see a large number of semi-connection statuses on the server, especially when the source IP address is random, it can basically be determined that this is a SYN attack. in Linux, you can run the following command to detect SYN Attacks:

Netstat-n-p tcp | grep syn_recv

Generally, the new TCP/IP protocol stack fixes the process to prevent SYN attacks and modifies the TCP protocol implementation. The main methods include SynAttackProtect protection mechanism, syn cookies technology, maximum semi-connection addition, and timeout reduction.

However, SYN attacks cannot be completely prevented.

TCP Four Waves

The removal of the TCP connection requires four packets, so it is called four-way handshake ). The client or server can actively initiate a wave action. In socket programming, either party can execute the close () operation to generate a wave operation.

 

 

For more information, see Wireshark packet capture. The measured packet capture results are not strictly in the wave sequence. I guess it is caused by a short interval.

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. 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 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 very short, basically, you can hardly see this status with netstat unless you write a client test program and deliberately disable the last ACK packet from the three TCP handshakes. Therefore, when an ACK packet is received 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 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 fin_wait_1 and fin_wait_2 statuses both indicate waiting for the FIN packets of the other party. 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 packet, it enters the fin_wait_2 status. Of course, under normal circumstances, the other party should immediately respond to the ACK packet, regardless of the situation, therefore, 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: indicates that the FIN packet of the other party is received, and the ACK packet is sent concurrently, so that 2msl can return to the closed available status. If fin_wait_1 receives a message with both the fin mark and ACK mark, 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. Normally, when you send a FIN packet, you should first (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 a socket at the same time, both parties may send FIN packets at the same time, that is, the closing status may occur, 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 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. I have analyzed the results (not necessarily 100% correct)
1. Why is the three-way handshake while the four-way handshake when the connection is closed?
This is because the socket in the listen status of the server can respond to ack and SYN after receiving the SYN Packet connection request) it is sent in a message. 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, therefore, you may not close the socket immediately, that is, you may need to send some data to the other party, and then send the fin message to the other party to indicate that you agree to close the connection now, therefore, the ACK messages and fin messages 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 close the connection, and the four packets of the handshake 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 message you sent will be received by the other party. Therefore, the socket in the last_ack status of the other party may fail to receive the ACK message due to timeout, but resend the fin message, therefore, the time_wait status is used to resend potentially lost ACK packets.