- First handshake: When a connection is established, the client sends
syn
a packet and a random serial number seq=x
to the server, and enters the SYN_SEND
state, waiting for the server to confirm. ( syn
, synchronous sequence number).
- The second handshake, the server receives the
syn
package, must confirm the client's SYN
, and then the server sends a ACK=1, SYN=1, seq=y
random number and ack=x+1
confirms the number of packets sent back.
- The third handshake is that the client receives the server-side
SYN+ACK
package, and then sends a confirmation packet to the server side, the ack=y+1, seq=x+1, ACK=1
client and the server side into the ESTABLISHED
state, completing three handshakes. The following illustration ( ACK
indicates the position 1 in the header ACK
, indicating the value of the ack
ordinal field in the header):
Here to say a little more, since the mention of the connection when the three handshake, by the way to the disconnection when the four wave also review.
- First the client sends
Fin=1,seq=u
it aggressively, which equals the ordinal of the last byte that was previously transmitted, plus 1. Then A
enter the FIN-WAIT-1
state, waiting B
for confirmation.
B
Immediately after the connection is received, the confirmation number is ack=u+1
, and the message segment's own sequence number is v
equal to the B
last byte of the previous transmitted data sequence number plus 1. Then B
enter the CLOSE-WAIT
state. Thus A
the B
link has now been disconnected, when the TCP
connection is in a semi-closed state, that A
there is no data to send. But B
if you send the data, A
you still have to accept it. A
after receiving B
the acknowledgement from, it enters the FIN-WAIT-2
status waiting to B
emit the connection release message segment.
- If
B
there is no A
data to send, its application process notifies the TCP
release connection. B
The connection release message segment that is emitted must be used FIN=1
. Now the assumed B
sequence number is w
, and B
you must repeat the confirmation number that was last sent ack=u+1
. Then B
it enters the LAST-ACK
state and waits for A
confirmation.
A
B
This must be confirmed after the received connection has been released. In the confirmation number put ACK
1, the confirmation number ack=w+1
, and its own serial number is seq=u+1
. Then A
enter the TIME-WAIT
state. In order to ensure that the B
confirmation release message segment can be received. Such as:
Are all active shutdowns socket
going into the TIME_WAIT
state?
Is there any situation that makes the active shut down socket
directly into the CLOSED
state?
The actively closed party after sending the last ack
It will enter the TIME_WAIT
state of Stay 2MSL
( max segment lifetime
) time
This is TCP/IP
essential, that is, "solution" is not. That's TCP/IP
what the designers were designed to do.
There are two main reasons:
- Prevent packages in the last connection, re-emerge after getting lost, affect new connections
( 2MSL
all duplicate packets in the last connection will disappear)
- Reliable closing of
TCP
connections
The last one sent in the active shutdown ack(fin)
, it is possible to lose, then the passive side will be re-sent
fin
, and if the active side is in CLOSED
the state then it responds rst
instead ack
. So
The active side should be in TIME_WAIT
a state, not a CLOSED
.
TCP three-time handshake and time-wait status