table of Contents
Overview
First, the client sends a connection request message, and the server responds with an ACK message after accepting the connection, and allocates resources for this connection. After the Client receives the ACK message, it also sends an ACK message to the Server side and allocates resources, so that the TCP connection is established.
Initially, the TCP processes at both ends are in the CLOSED state, A actively opens the connection, and B passively opens the connection. (A, B closed state CLOSED** —> **B listening state LISTEN —> A synchronized sent state SYN-SENT —> B synchronized received state SYN-RCVD —> A, B connection established state ESTABLISHED)
Assume Client The end initiates an interrupt connection request, that is, sends a FIN message. After the server receives the FIN message, it understands the meaning of the client to say: "Server, hello, I have no data to send to you, but if you still have data on the server that has not been sent, you do not need to rush to close the Socket , You can continue to send data.
So the server sends an ACK to tell the client: "Client, hello, I have received your request, but I am not ready yet, please continue to wait for my message." At this time, the client side enters the FIN_WAIT state, and continues to wait for the FIN message from the server side.
When the server side determines that the data has been sent, it sends a FIN message to the client side, telling the client side: "Server side, hello, I have finished sending the data here, and I am ready to close the connection".
After the client receives the FIN message, knowing that there is no more data to transmit, it can close the connection. But he still doesn't believe in the network, because the server doesn't know to close it, so he enters the TIME_WAIT state after sending the ACK. If the server does not receive the ACK, he can retransmit. After the server receives the ACK, it also knows that the client has confirmed that it has disconnected. The client side waited for 2MSL and still did not receive a reply from the server side, which proved that the server side has been closed normally. I thought, this time I can safely close the connection on the client side. Ok, so far the TCP connection is closed!
After the data transmission is over, both parties in the communication can release the connection, and both A and B are in the ESTABLISHED state. (A, B connection establishment state ESTABLISHED —> A termination waiting state FIN-WAIT-1 —> B closing waiting state CLOSE-WAIT —> A termination waiting state 2 FIN-WAIT-2 — B final confirmation state LAST-ACK —> A time waiting state TIME-WAIT —> B, A closed state CLOSED)
Three-way handshake process
The TCP server process of B first creates the transmission control block TCB, ready to accept the connection request of the client process. Then the server process is in the LISTEN (listening) state, waiting for the client's connection request. If so, respond.
First handshake
The TCP client process of A also first creates the transmission control block TCB. A sets the flag bit SYN to 1, randomly generates a value seq=x, and then sends a connection request segment to B. The segment （首部的同步位SYN=1，初始序号seq=x）with SYN=1 cannot be carried. Data, but a sequence number is consumed. At this time, the TCP client process enters the SYN-SENT (synchronized sent) state.
Second handshake
After server B receives the connection request segment, it knows from the flag bit SYN=1 that the client requests to establish a connection, the server sets both the flag bits SYN and ACK to 1, the confirmation number ack=x+1, and a random value is generated as The initial sequence number seq=y, if it is agreed to establish a connection, a confirmation segment will （SYN=1，ACK=1，ack=x+1，seq=y）be sent to A to confirm the connection, and the operating system will allocate TCP buffers and variables for the TCP connection. At this time, the TCP server process enters the SYN-RCVD (synchronously received) state.
Third handshake
After client A receives the confirmation from server B, it checks whether ack is x+1 and whether ACK is 1. If it is correct, set the flag ACK to 1, the confirmation number ack to y+1, and the sequence number seq to x +1, and at this time the operating system allocates TCP buffers and variables for the TCP connection, and must give B an acknowledgment segment （ACK=1，ack=y+1，seq=x+1）. The TCP connection has been established, and A enters ESTABLISHED (the connection has been established). When B receives A's confirmation, it also enters the ESTABLISHED state.
Process string
Both A and B are in the CLOSED state —> B creates a TCB, is in the LISTEN state, waiting for A request —> A creates a TCB, sends a connection request (SYN=1, seq=x), enters the SYN-SENT state —> B receives the connection Request, send an acknowledgement to A (SYN=ACK=1, acknowledgement number ack=x+1, initial sequence number seq=y), enter the SYN-RCVD state —> After A receives the confirmation from B, send an acknowledgement to B (ACK= 1, ack=y+1, seq=x+1), A enters the ESTABLISHED state —> After B receives A's confirmation, it enters the ESTABLISHED state.
TCB transmission control block
Transmission Control Block stores important information in each connection, such as the TCP connection table, pointers to sending and receiving buffers, pointers to retransmission queues, and current sending and receiving sequence numbers.
Four waved process
Wave for the first time
The application process of client A first sends a connection release segment to the server TCP （FIN=1，序号seq=u）, stops sending data again, actively closes the TCP connection, enters the FIN-WAIT-1 (termination waiting 1) state, and waits for the confirmation of server B.
Second wave
After server B receives the connection release message segment, it sends the confirmation message segment （ACK=1，确认号ack=u+1，序号seq=v）, and server B enters the CLOSE-WAIT (close waiting) state. At this time, the TCP is in a half-closed state. After receiving B's confirmation, A enters the FIN-WAIT-2 (termination waiting 2) state and waits for the connection release message segment sent by B.
Third wave
Server B has no data to send to client A, B sends a connection release segment （FIN=1，ACK=1，序号seq=w，确认号ack=u+1）, B enters the LAST-ACK (last confirmation) state, and waits for A's confirmation.
Fourth wave
After client A receives the connection release segment from server B, it sends an acknowledgement segment （ACK=1，seq=u+1，ack=w+1）, and A enters the TIME-WAIT state. At this time, TCP is not released, and A will enter the CLOSED state only after the time 2MSL set by the waiting timer has elapsed.
Process string
A and B are in the ESTABLISHED state —> A sends a connection release segment and is in the FIN-WAIT-1 state —> B sends an acknowledgement segment and enters the CLOSE-WAIT state —> After A receives the confirmation, enters FIN-WAIT- 2 state, waiting for B's connection release segment -> B has no data to send to A, B sends a connection release segment and enters the LAST-ACK state -> A sends an acknowledgment segment and enters the TIME-WAIT state- > B enters the CLOSED state after receiving the confirmation segment —> A enters the CLOSED state after the waiting timer time 2MSL.
other problems
Why is there three handshake when connecting, but four waves when closing?
Because when the Server side receives the SYN connection request message from the Client side, it can send a SYN+ACK message directly. The ACK message is used for reply, and the SYN message is used for synchronization. However, when the connection is closed, when the server receives a FIN message, it may not immediately close the SOCKET, so it can only reply with an ACK message and tell the client, "I received the FIN message you sent." Only after all the messages on my Server side have been sent, I can send FIN messages, so I cannot send them together. Therefore, a four-step handshake is required.
Why does A send a confirmation? Can I shake hands twice?
The main purpose is to prevent the failed connection request message segment from being suddenly transmitted to B, thus causing an error. If A sends a connection request, but has not received the confirmation due to the loss of the connection request message, then A retransmits the connection request again. A confirmation was received later and the connection was established. After the data transmission is completed, the connection is released. Worker A sends out two connection request segments. The first one is lost and the second reaches B. However, the first lost segment is only in some network connections. Point stays for a long time, and it will not reach B until a certain time after the connection is released. At this time, B mistakenly believes that A has sent a new connection request, so it sends a confirmation segment to A, agreeing to establish a connection.
It is not possible to establish a connection with the two-way handshake. If the three-way handshake is not used, as long as B sends a confirmation, a new connection is established. If A ignores B's confirmation and does not send data at this time, B will wait for A to send data. ,a waste of resource.
What to do if the client crashes
TCP also has a keep-alive timer. Obviously, if the client fails, the server cannot wait forever, and resources are wasted. The server resets this timer every time it receives a request from the client. The time is usually set to 2 hours. If it has not received any data from the client for two hours, the server will send a probe segment, and then every 75 Sent every second. If there is no response after sending 10 probe messages, the server considers the client to be faulty, and then closes the connection.