Detailed TCP / IP three-way handshake and four waving
flowchart pure hand to play, vomiting masterpiece.
Related issues by: HTTPS: //blog.csdn.net/hyg0811/article/details/102366854
A. flowchart three-way handshake:
(a circular frame shows a state, the black arrows indicate the switching state, the white arrows indicate outgoing packet)
the SYN packets: request ligation
ACK packets: response effect
ack acknowledgment number: is the corresponding value in the request. 1 + SEQ
SEQ ID initial: marking the packet sequence number after each transmission packet + 1'd
B. handshake questions:
1.1 Why It requires three-way handshake, the two can not I?
Clarify this issue, we need to figure out what the purpose is three-way handshake, can not only to achieve the same purpose with two-way handshake.
The first handshake: the client sends a packet network, the server received.
So the server can be concluded: the ability to send, receive capability of the client service side is normal.
The second handshake: server contract, the client received.
So that the client can conclude that: receive, transmit capability, the client receives, the ability to send the server is normal. But this time the server and the client can not confirm reception is normal.
Third handshake: the client contract, the server received.
So the server can be concluded: the client receives, the ability to send, the server's own sending, receiving ability is also normal.
Therefore, three-way handshake to confirm both the reception and transmission capacity is normal.
Imagine if to shake hands with the two, the following scenario occurs:
The client makes a connection request, the connection request but does not receive acknowledgment packets are lost, then the client once again retransmit the connection request. Later received a confirmation, a connection is established. After the data transmission is completed, the connection is released, client connection requests were issued two segments, wherein a first lost, the second server arrived, but the first lost segment and only certain network node long stay, and delayed until some time after connection release service before reaching the end, when the server mistaken client has issued a new connection request, so they send a confirmation message to the client segment, agreed establish a connection, do not use three-way handshake, as long as the server issue, confirm that, to establish a new connection, and this time the client ignores the server sent a confirmation nor sending data, the server waits for a client to send the same data, a waste of resources .
1.2 What is the half-connection queue?
After the server first received the client's SYN, will be in SYN_RCVD state, this time the two sides have not yet fully established its connection, the connection request in a queue at the server will this state, we call this queue semi connection queue. Of course there is a connection queue is full, is already completed three-way handshake to establish a connection will be placed in full connection queue. If the queue is full there is packet loss may occur.
Here add that the issue of SYN-ACK retransmission times: the
server after sending SYN-ACK packet, if the client has not received confirmation packet, the server first retransmission, wait some time yet to receive customer confirmation pack, a second retransmissions. If the maximum number of retransmissions of retransmissions exceeds a predetermined system, the connection information deleted from the system half-connection queue.
Note that each retransmission waiting time is not necessarily the same, the general will be exponential growth, for example, the interval time is 1S, 2S, 4S, 8S ...
1.3 ISN (Initial Sequence Number The) is fixed it?
When one end to establish the connection sends its SYN, which is connected to select one of the initial number. ISN change over time, so that each will have a different connection ISN. ISN can be seen as a 32-bit counter, plus 1 every 4ms. Such selection number from the network aims to prevent delayed after the packet has been transmitted, but it leads to a one do the wrong interpretation of the connector.
Three-way handshake is one of the important functions of client and server exchange ISN (Initial Sequence Number), in order to let each other know when the next receive data on how the data assembled by serial number. If the ISN is fixed, it is easy for an attacker to guess the subsequent acknowledgment number, so ISN is dynamically generated.
1.4 three-way handshake may carry data?
In fact, the third time to shake hands, it can carry data. But, first, second handshake can not carry data
Why did this happen? We can think of a problem, if the first handshake can carry data, and if someone wants to malicious server, that every time he at first handshake SYN packets into large amounts of data. Because the attacker simply ignore the receiving server, the ability to send is normal, then frantically focus on relapse SYN packet, then it makes the server takes a lot of time and memory space to receive these messages.
In other words, the first handshake can not put data in which a simple reason for this is to make the server more vulnerable to attack. For the third time, then, when the client is already in the ESTABLISHED state. For the client, he has established a connection, and also have been known to receive, transmit power of the server is normal, so can carry data also nothing wrong.
1.5 SYN attack what?
Server resource allocation is assigned when the second handshake, and client resources are allocated upon completion of the three-way handshake, the server vulnerable to SYN flooding attack. Client SYN attack is a large number of forged IP address does not exist in a short time, and continue to send SYN packets Server, Server back to confirm the package and wait for Client confirmation, since the source address does not exist, therefore the need to constantly re-issued until the Server Timeout SYN, SYN packet to the forged connection queue is not occupied for a long time, leading to the normal request queue is full are discarded due to network congestion or even cause system failure. SYN attack is a typical DoS / DDoS attacks.
C. Four waving a flow chart:
MSL is the Maximum Segment Lifetime abbreviation, it can be translated as "the longest segment life", which is the most of any time, over this time the message packets on the network will be present throw away.
D. waved related issues:
2.1 waving Why do we need four?
Because when the server receives the client's connection request SYN packet, it can be sent directly SYN + ACK packet. Wherein the ACK message is used for response, SYN etc is used to synchronize the packet. But the connection is closed, when the server receives FIN packet, it might not turn off immediately SOCKET, it can only respond to a first ACK packet, telling the client, "you send FIN messages I have received." Only until the end of all my service messages are sent over, I can send FIN packets, and therefore can not be sent together. It requires four wave.
2.2 2MSL wait state
TIME_WAIT state has become 2MSL wait state. Each specific TCP implementation must select a maximum segment lifetime MSL (Maximum Segment Lifetime), which is before any segment is discarded longest time within the network. The time is limited, because the TCP segment to IP datagrams in the transmission network, and the IP datagram has the TTL field limit their survival time.
For a particular implementation of MSL values given, the processing principle is: when performing a TCP active close, and sends back the ACK last, the connection must stay in the TIME_WAIT state time is twice MSL. This allows TCP to send the final ACK ACK prevent this loss (the other end of the timeout and retransmit the final FIN) again.
Another result of this is that this wait 2MSL TCP connection during 2MSL waiting define the connection socket (client's IP address and port number, the server's IP address and port number) can not be reused. This connection can only be used again after the end of 2MSL.
Four waved 2.3 release, wait 2MSL meaning of?
MSL is the Maximum Segment Lifetime abbreviation, can be translated as "the longest segment life", it is the longest of any messages present on the network, and more than this time of packets will be dropped.
In order to ensure the last ACK segment sent by the client to reach the server. Because this ACK may be lost, resulting in the LAST-ACK state of the server can not receive an acknowledgment packet for FIN-ACK's. Server timeout retransmit the FIN-ACK, then the client retransmit once confirmed, restart waiting time timer. Finally, the client and the server can be normal shutdown. Assume that the client does not wait 2MSL, but released directly closed after sending ACK, but the ACK a loss, the server can not be properly connected into the closed state.
For two reasons:
to ensure that the last ACK segment sent by the client to reach the server.
The ACK segment may be lost, so that the B state in the LAST-ACK to receive acknowledgment FIN + sent, the server ACK segment retransmission timeout FIN + ACK segment, and the client can be in receiving this retransmission within 2MSL time FIN + ACK segment, then the client retransmit once confirmed, restart 2MSL timer, and finally the client and server are entered into the CLOSED state, if the client tIME-WAIT state do not wait for some time, but immediately release the connection after sending the ACK segment, you can not receive the service side retransmitted FIN + ACK segment, it will not send a confirmation message segment, the server can not be normal enter the CLOSED state.
Prevent the "expired connection request segment" appear in this connection.
The client after sending the last ACK segment, then after 2MSL, you can make all the segments in this connection duration generated disappeared from the network, the next new connection does not appear in this the old kind of connection request segment.
