I finally found written emergent described, the brother of the term a little more professional https://blog.csdn.net/qq_38950316/article/details/81087809 (brother of this slight typos
We can look at it. I see this may be better understood, after all, they are big vernacular
Three-way handshake!
Three-way handshake is not really accurate. For a TCP connection in the official document is to describe the whole process handshake handshake TCP connection establishment.
We can only hold one hand to establish a TCP connection . So why is it three-way handshake to establish a connection? In fact, it is three times to send three messages , we can say that a three-way handshake packets
① start the client and server are in a closed state , the client take the initiative to open, send a message to the server. The message carrying the SYN = (synchronous) and seq = x (a serial number, have their own serial number will continue to increase) 1
At this time, the client is: SYN-SENT state
PS: Probably look
Synchronization SYN: for synchronizing serial connection establishment. Means that when SYN = 1, ACK = 0: this is a connection request packet segments. If the agreed connection, in the response message segments that SYN = 1, ACK = 1. Accordingly, SYN = 1 indicates that this is a connection request, or the connection acceptance message. The SYN flag only if the TCP connection construction production will be set after the completion of the handshake SYN flag is set to 0.
SEQ ID NO seq: 4 bytes for the data segment order mark, the TCP connection all data bytes transmitted are compiled on a serial number, the first byte of the random number generated by the local; ed to bytes after the serial number, give each segment is assigned a serial number; seq is the sequence number of the first byte of the data segment number.
② Then our server passive open in listening , waiting for the client to send a message the first handshake.
After receiving the message sent by the client, the client will immediately send a confirmation message --------------- the ACK =. 1, the SYN =. 1, SEQ = Y, (lowercase ) ACK. 1 = X +
(Uppercase) ACK is the acknowledgment bit, if 1, the code confirmation packets. If 0, you can directly ignored, does not make sense
In this case the server is in the state of SYN-RECV
③ The packet has ACK = 1, acknowledge bit effective, ack = y + 1, is the acknowledgment message
That is, 'I acknowledge that I have received your confirmation message'
Is our client, confirm, confirm that the server sends the message that we have received client
Is the server-side to confirm the connection used to create the message sent by the client, I received a server, the server that I sent this message to confirm your client, your client receives not?
At this time, in the client server over ESTABLISHED (TCP connection success status)
Details: ①seq = x ③seq = x + 1 to be described ③ client before sending packets, there is no time to send another message
After the server then receive a confirmation message, the TCP connection is established
I have a question? Obviously, when the execution ①②, TCP connection can be established, then again why the client also sends a confirmation message in the past it?
① because such a request message may be sent on his way becomes ineffective. This failure is not that it is not a role.
But that due to the network for some reason, resulting in the request packet has occurred in the network blocking residence , but there is a TCP connection timeout retransmission mechanism
So ① request packet does not arrive, then the server will not receive. Not receive this one, the server will think just of ① request packet is sent to that client sends a request message again and again.
And just a piece request message to stay in the network. The client sends again a similar request to establish a TCP connection, the server they received, and then confirm ② ③ confirmation, thus establishing a TCP connection
As we flattered to establish a TCP connection is successful, run out after connection, it destroyed out
However, just stay in the network that link is, our network could suddenly open, and that that link is just another entry into force, but also to reach the server
Server receives, it will send a confirmation message to the client again. If this time is not ③ confirmation message, then the TCP connection is established.
But this we do not need the connection establishment. Because we have to re-pass before a request packet, the connection is established and released.
So there is no ③ will re-establish a connection, we do not need this connection.
Once you have ③, an acknowledgment packet sent from the server, the client side after I receive will say: I did not send you ah. Then it will not just deal with the piece 'connection'
Four waving
Are built before the state closed
① client sends a 'connection release message', carried in the header FIN = 1, seq = u u sequence is terminated FIN: for releasing a connection. FIN = 1 represents: a data sender of this segment has been transmitted, and for the release of the transport connection
② After receiving the message, the service, the client needs to know is disconnected. I send you a confirmation message, ACK = 1, on behalf of validated seq is v, ack = u +1
The client receives the packet, the client --- "TCP server connections in this direction has been disconnected, has expired
The Client "--- this direction or the server can be connected
③ But we may have data server does not pass in the past, you need to resend the packet, FIN = 1, ACK = 1, seq = w, ack = u + 1 Details: ① the seq = v ③ normal of seq = w is + 1, v w to illustrate discontinuous intermediate
This is the server to the client is disconnected
④ server may not hear from us ④ confirmation message, the server will know that we are sending ③ their own did not receive, then the server sends ③ again, I want to shut down. That's why you want to set the maximum packet generation period 2MSL
Otherwise, clients have closed, the server also send you a hammer?
The client receives a connection release message server must send acknowledgment, ACK = 1, ack = w + 1, and their serial number seq = u + 1, In this case, the client enters the TIME-WAIT ( time waiting) state. Note that the TCP connection has not been released at this time, must undergo 2MSL (maximum segment lifetime) time, when the client undo the TCB corresponding, before entering the CLOSED state.
[1] Why the problem is connected to three-way handshake when closing time is four-way handshake?
A: Because when the terminal receives SYN Server Client terminal connection request message may 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 side FIN packet is received, probably does not close immediately SOCKET, it can only respond to a first ACK packet, told Client-side, "you send FIN messages I have received." Only until the end of all my Server messages are sent over, I can send FIN packets, and therefore can not be sent together. It requires a four-step handshake.
[Question 2] Why TIME_WAIT state need to go through 2MSL (maximum segment lifetime) CLOSE to return to the state?
A: Although Logically, the four packets have been sent, we can go directly to the CLOSE state, but we have the illusion of a network is unreliable, there may be the last ACK is lost. So TIME_WAIT state is used to retransmit ACK packets may be lost. Send out the final ACK reply Client, but the ACK may be lost. Server If no ACK, FIN segment sent will repeat. Client can not close it immediately, it must be confirmed Server receives the ACK. Client enters the TIME_WAIT state after sending the ACK. Client will set a timer, waiting 2MSL time. If you receive FIN again within that time, then the Client will resend ACK 2MSL and wait again. The so-called 2MSL is twice the MSL (Maximum Segment Lifetime). MSL refers to a segment of the network the maximum survival time, 2MSL is transmitted and a maximum time required for a response. If until 2MSL, Client have not received FIN again, then the Client concluded that ACK has been successfully received, the TCP connection.
[Question 3] Why can not connect using two-way handshake?
A: 3-way handshake to complete two important functions, both sides should make preparations to send data (both sides know each other ready), but also to allow the parties to negotiate on the initial sequence number, serial number during the handshake It is sent and acknowledged.
Now put into a three-way handshake only requires two hands, a deadlock is likely to occur. As an example, consider the communication between the computer C and S, S is assumed to C transmits a connection request packet, the received packet is S, and send the acknowledgment packet. Under the agreement the two shook hands, S considers the connection has been successfully established, you can start sending data packets. However, C in the case of S reply packet is lost in transmission, and will not know if S is ready, I do not know what kind of establishment S serial number, C S even doubt whether it has received its own connection request packet. In this case, C considers the connection has not been established successfully, will ignore any data packet sent by S, just waiting for the connection confirmation response packet. After the S timeout packet sent repeatedly transmits the same packet. This creates a deadlock.
[4] how to do the problem if you have established a connection, but the client suddenly broke down?
TCP is also a keep-alive timer, apparently, a client if a failure occurs, the server can not keep on waiting, wasted resources. Each time the server receives the client's request will reset the timer set time is usually 2 hours, if two hours has not received any data from the client, the server sends a detection message segment, then every 75 seconds to send one. If sending 10 consecutive probe packets still did not respond, the server brought out customers considered a failure, and then they close the connection