Analysis of TCP three-time handshake and four wave state transition

TCP is a TCP/IP Transport Layer Control protocol that provides a reliable connection service with three handshake confirmations to establish a connection:

There are several nouns to understand first: The TCP flag bit, with 6 types: SYN (synchronous online), ACK (acknowledgement acknowledgement), PSH (push transfer), FIN (finish end), RST (reset reset), URG (urgent emergency);
The URG emergency pointer tells the receiving TCP module that the critical pointer field refers to critical data.
When the ACK is set to 1, the confirmation number (valid, 0 indicates that the data segment does not contain confirmation information and the confirmation number is ignored).
PSH 1 O'Clock the requested data segment can be sent directly to the application after it has been received by the receiving party, without having to wait until the buffer is full.
RST 1 O'Clock rebuilds the connection. Some errors usually occur when the RST bit is received.
SYN 1 o'clock is used to initiate a connection.
FIN 1 indicates that the originator completes the send task. Used to release the connection, indicating that no data has been sent by the sending party.
There are also Sequence number (sequential number), acknowledge number (confirmation numbers) that are sent during the handshake process.

Host a (client) and Host B (server) begin to establish a handshake process:

The first handshake: host a send bit code for syn=1, randomly generate SEQ number=10001 packet to the server, Host B by Syn=1 know, a requirements to establish online, at this time the status of Syn_sent;
Second handshake: Host B receives the request to confirm the online information, send an ACK to a number= (host a seq+1), syn=1,ack=1, randomly generate seq=20001 packets, the state from listen to SYN_RECV;
Third handshake: Host a after receiving check ACK number is correct, that is, the first sent Seq Number+1, and the bit code ACK is 1, if correct, host A will send an ACK number= (Host B seq+1), ack= 1, Host B received after confirming the SEQ value with ack=1 then the connection established successfully, both sides State established.

To complete the three handshake, host A and Host B start transmitting data.

Explain the implications of each state:
CLOSED: This is nothing to say, it means the initial state.
LISTEN: This is also very easy to understand a state, that the server side of a socket is listening state, can accept the connection.
SYN_RECV: This status means that the SYN message is received, under normal circumstances, this state is the server side of the socket in the establishment of a TCP connection during the three handshake session process of an intermediate state, very short, basically with netstat you are very difficult to see this state, Unless you specifically write a client-side test program, deliberately not send the last ACK message during the three TCP handshake. Therefore, when the ACK message is received from the client, it goes into the established state.
Syn_sent: This state is echoed with the syn_recv thinking back, when the client socket performs a connect connection, it sends the SYN message first, so it then enters the syn_sent state and waits for the server to send the 2nd message in the three-time handshake. The Syn_sent status indicates that the client has sent a SYN message.
Established: This is easy to understand, indicating that the connection has been established.

：

SYN attack
During the three handshake, after the server sends Syn-ack, the TCP connection before receiving the ACK from the client is called a half-connection (Half-open Connect). The server is in the SYN_RECV state. When an ACK is received, the server goes into the established state.

SYN attack is to attack the client in a short period of time to forge a large number of non-existent IP addresses, to the server constantly send SYN packets, the server replies to confirm the packet, and wait for the customer's confirmation, because the source address is not present, the server needs to continue to resend until time-out, these forged SYN packets will occupy the disconnected queue Normal SYN requests are discarded, the target system is running slowly, and serious people cause network congestion and even system paralysis.

A SYN attack is a typical DDoS attack. The detection of SYN attacks is very convenient, when you see a large number of semi-connected state on the server, especially the source IP address is random, basically can be concluded that this is a SYN attack. Under Linux, you can check for SYN attacks as follows:
#netstat-N-P TCP | grep syn_recv
In general, the newer TCP/IP protocol stack modifies this process to prevent SYN attacks and modify TCP protocol implementations. The main methods are SynAttackProtect protection mechanism, SYN-cookie technology, increasing the maximum half-connection and shortening the time-out period, etc., but cannot prevent SYN attack completely.


TCP four times Wave
The removal of TCP connections requires sending four packets, so called four waves (Four-way handshake). The client or server can initiate a wave gesture.
Parse various state meanings:
Fin_wait_1: This state should be well explained, in fact, the real meaning of fin_wait_1 and fin_wait_2 state is to wait for each other's fin message. The difference between the two states is: The fin_wait_1 state is actually when the socket in the established state, it would like to actively close the connection, send a FIN message to the other side, when the socket is entered into the fin_wait_1 state. And when the other party responds to the ACK message, then into the fin_wait_2 state, of course, under the actual normal circumstances, regardless of the circumstances of each other, should immediately respond to the ACK message, so fin_wait_1 state is generally more difficult to see, and Fin_wait_ 2 states can also sometimes be seen with netstat.
Fin_wait_2: Above has explained in detail this state, actually fin_wait_2 the socket in the state, indicates the half connection, also namely has the party request close connection, but also tells the other side, I temporarily also some data need to transmit to you, later closes the connection again.
Time_wait: Said to receive the other side of the fin message, and sent out an ACK message, just wait for 2MSL to return to the closed usable state. If the fin_wait_1 state, received the other side with the FIN flag and the ACK flag message, you can directly into the time_wait state, without having to go through the fin_wait_2 state.
CLOSING: This kind of state is special, the actual situation should be very rare, belong to a relatively rare exception state. Normally, when you send a fin message, it is supposed to receive (or receive) the other's ACK message before receiving the other's fin message. But closing status indicates that you send fin message, and did not receive the other's ACK message, but also received the other side of the fin message. Under what circumstances will this happen? In fact, it is not difficult to come to a conclusion: that is, if the two sides close a socket at the same time, then there is a situation where both sides send the fin message, there will be a closing state, indicating that both sides are shutting down the socket connection.
Close_wait: The meaning of this state is actually expressed in waiting to be closed. How do you understand it? When the other side close a socket to send fin message to yourself, you will undoubtedly respond to an ACK message to each other, then enter into the close_wait state. Next, the real thing you really need to consider is whether you still have the data sent to the other person, if not, then you can close the socket, send fin messages to each other, that is, close the connection. So what you need to accomplish in the close_wait state is waiting for you to close the connection.
Last_ack: This state is still relatively easy to understand, it is the passive close side after sending fin messages, and finally wait for each other's ACK message. When an ACK message is received, it is also possible to enter the closed available state.
Use the online easy to understand wave process:

Finishing the online knowledge point, there are 3 questions analyzed after the conclusion (not necessarily guaranteed 100% correct):
1, why to establish a connection agreement is three handshake, and close the connection is four handshake it?
This is because the socket in the listen state of the server is sent in a message after it receives a request for the connection of the SYN message, and it can put the ACK and SYN (ACK response, and SYN synchronous). However, when the connection is closed, when receiving the other's fin message notification, it simply means that no data is sent to you, but not all of your data are sent to the other side, so you may not immediately close the socket, that is, you may also need to send some data to the other side, Send the FIN message to the other side to show that you agree that you can now close the connection, so it is here that the ACK message and fin messages are sent separately in most cases.

2, why time_wait state also need to wait 2MSL to return to closed status?
Because although both sides agreed to close the connection, and the handshake of the 4 messages are sent, it can be directly back to the closed state (as from the Syn_sent state to the establish state), but we must assume that the network is unreliable, you can not guarantee that you (the client) The final ACK message must be received by the other side, that is, the other side in the Last_ack state of the socket may be due to the timeout did not receive an ACK message, and the re-send fin message, so this time_wait state function is used to resend the possible loss of the ACK message.

3. Do I need to wave 4 times to close the TCP connection?
Not necessarily, 4 times to wave off the TCP connection is the safest practice. But at some point, we don't like the time_wait state (such as when the MSL value is too large to cause a TCP connection with too many time_wait states on the server side, reducing the number of these entries can close the connection faster, freeing up more resources for new connections), At this point we can prevent the socket from entering the TIME_WAIT state after close () by setting the SO_LINGER flag of the socket variable, forcing the TCP connection to be terminated by sending the RST (instead of terminating the normal TCP four handshake). But this is not a very good idea, time_wait for us is often advantageous

Analysis of TCP three-time handshake and four wave state transition