First, the three-way handshake
1, the first handshake
The client sends a synchronization message (SYN = 1, ACK = 0, seq = x) to the server (TCP SYN = not carrying a predetermined data 1, x is a value randomly generated), and enters SYN_SEND state, waiting for the server to confirm.
Note:
- SYN (Synchronize): synchronous serial number to establish a connection. 1 when the ACK = 0 when SYN =, indicates that this is a connection request packet segments. If the other party agrees to establish a connection, it should be in response segment manipulation SYN = 1 and ACK = 1. Therefore SYN set to 1, it indicates that this is a connection request packet and the receiving connector;
- ACK (acknowledgment): ACK = 1, it is confirmed when the field is valid. When ACK = 0, the acknowledgment number is invalid. TCP provides that all the segments transmitted the ACK must be set after the connection;
- seq (Sequence Number): 4 bytes. Reference using mod
operations. TCP is a byte-oriented stream, byte stream transmitted in a TCP connection in each byte sequentially numbered. So the field is also called "segment sequence number."
2, second handshake
Server receives a SYN segment to confirm the identity SYN position 1, ACK is set to 1, seq set to y, ack set to x + 1, and then enters SYN_RECV state, this state is called a semi-connected state.
Note:
- ack (Acknowledgment Number): is the desired interface receives the first data byte sequence number of the next segment. If the acknowledgment number = N, indicates that: all of the data until the sequence number N-1 are received correctly.
3, third handshake
The client once again confirmed the ACK is set to 1, seq set to x + 1, ack is set to y + 1 sent to the server, the client and server are finally enters the ESTABLISHED state, complete the three-way handshake to establish a connection.
4 Why do we need the client to confirm once again in the third handshake?
If the TCP handshake with only two mechanisms, namely the client makes a connection request, the server confirmation request connection is established.
Assume that a client makes a request to establish a connection, because of network congestion server has not received the request, the client considers the request to send the second time lost again to establish a connection request, the server receives the request and confirm, successfully established link.
The first connection request segment is not lost, but in some network nodes stranded for a long time, so the delay to a point in time after connection release service before reaching the end. Actually, this connection request has failed, but the failure of the server after receiving this connection request segment, mistakenly think that this is the client has issued a new connection request. So Xiang server client makes a request segment, agreed to establish a connection.
Now that the client did not request connection is established, it will not bother to confirm the server, it will not send data to the server, but the server thought that the new transport connection has been established, and has been waiting for the client to send data many resources such service side so wasted.
Three-way handshake of ways to prevent the occurrence of these phenomena. For example, in the above scenario, the client does not send a confirmation request to the server, the server can not receive due acknowledgment, we do not really know the client requests to establish a connection.