foreword
TCP is used for communication between applications. When an application wants to communicate with another application over TCP, it sends a communication request. This request must be sent to an exact address. After the two sides "handshake", TCP will establish a full-duplex communication between the two applications. This full-duplex communication will occupy the communication line between the two computers until it is closed by one or both parties.
Because TCP provides a connection-oriented, reliable byte stream service.
Therefore, this article explains the "three-way handshake" when the connection is established and the "four-way handshake" when the connection is released.
1. TCP transport connection management
1. TCP connection establishment (three-way handshake)
The above picture shows the TCP connection establishment process. Assume that host A is running a TCP client program and B is running a TCP server program. Initially, the TCP processes on both ends are in the CLOSED state. The boxes below the host in the figure are the states of the TCP process. Note that A actively opens the connection, while B passively opens the connection.
B's TCP server process first creates a transmission control block TCB (which stores some important information in each connection, such as: TCP connection table, pointers to sending and receiving buffers, pointers to retransmission queues, current sending and receiving sequence numbers , etc.), ready to accept connection requests from client processes. Then the server process is in the LISTEN (listen) state, waiting for the client's connection request. If so, respond.
A's TCP client process also first creates a transmission control module TCB, and then sends a connection request segment to B. At this time, the synchronization bit in the header is SYN=1, and an initial sequence number seq=x is selected at the same time. TCP stipulates that the SYN segment (that is, the segment with SYN=1) cannot carry data, but a sequence number is consumed. At this point, the TCP client process enters the SYN-SENT state.
After receiving the connection request segment, B sends an acknowledgement to A if it agrees to establish the connection. In the confirmation segment, both the SYN bit and the ACK bit should be set to 1, the confirmation number is ack=x+1, and an initial sequence number seq=y should also be selected for itself. Note that this segment also cannot write data, but also consumes a sequence number. At this time, the TCP server process enters the SYN-RCVD (synchronized received) state.
After the TCP client process receives the confirmation from B, it also needs to give confirmation to B. The ACK of the confirmation segment is set to 1, the confirmation number ack=y+1, and its own sequence number seq=x+1, the standard of TCP stipulates that the ACK segment can carry data. However, if no data is carried, the sequence number is not consumed. In this case, the sequence number of the next data segment is still seq=x+1. At this time, the TCP connection has been established, and A enters the ESTABLISHED state.
When B receives the confirmation from A, it also enters the ESTABLISHED state.
The connection establishment process given above is called a three-way handshake.
Why does A need to send an acknowledgment? This is mainly to prevent the failed connection request segment from being suddenly transmitted to B, resulting in an error.
The so-called "defunct connection request segment" is generated in this way. Consider a normal situation. A sends a connection request, but does not receive an acknowledgment because the connection request message is lost. So A retransmits the connection request again. A confirmation was later received and the connection was established. After the data transfer is complete, the connection is released. A sends a total of two connection request segments, the first of which is lost and the second reaches B. There is no "stale connection request segment".
Now suppose that there is an abnormal situation, that is, the first connection request segment sent by A is not lost, but stays at some network nodes for a long time, so that it is delayed until a certain time after the connection is released before reaching B . Originally this was a long-defunct segment. However, after receiving the invalid connection request segment, B mistakenly believes that A has sent a new connection request. So it sends a confirmation segment to A and agrees to establish a connection. Assuming that the three-way handshake is not used, a new connection is established as long as B sends an acknowledgment.
Since A has not sent a request to establish a connection now, you will not pay attention to B's confirmation, and will not send a confirmation to B's confirmation. Since B does not receive the confirmation, it knows that A has not asked to establish a connection.
2. TCP connection release (four-way handshake)
After the data transmission is over, both parties in the communication can release the connection. Now both A and B are in ESTABLISHED state. The application process of A first sends a connection release segment to its TCP, stops sending data again, and actively closes the TCP connection. A sets the termination control bit FIN in the header of the connection release segment to 1, and its sequence number seq=u, which is equal to the sequence number of the last byte of the previously transmitted data plus 1. At this time, A enters the FIN-WAIT-1 (termination wait 1) state and waits for B's confirmation. caution. TCP stipulates that even if the FIN segment does not carry data, it consumes a sequence number.
After B receives the connection release segment, it sends an acknowledgment. The acknowledgment number is ack=u+1, and the segment's own sequence number is v, which is equal to the sequence number of the last byte of the data previously transmitted by B plus 1. . Then B enters the CLOSE-WAIT (close wait) state. The TCP server process should notify the high-level application process at this time, so the connection from A to B is released. At this time, the TCP connection is in a half-closed state, that is, A has no data to send, but if B sends data, A still to receive. That is to say, the connection from B to A is not closed, and this state may last for some time.
After receiving the confirmation from B, A enters the GIN-WAIT-2 (termination waiting 2) state and waits for the connection release segment sent by B.
If B has no data to send to A, its application process informs TCP to release the connection. At this time, the connection release segment sent by B must make FIN=1. Now assume that the sequence number of B is w (B may have sent some data in the valve closed state). B must also repeat the confirmation number ack=u+1 that has been sent last time. At this time, B enters the LAST-ACK (last confirmation) state and waits for A's confirmation.
After A receives B's connection release segment, it must confirm it. Set the ACK to 1 in the confirmation segment, the confirmation number ack=w+1. And its own sequence number is seq=u+1. Then enter the TIME-WAIT (time waiting) state. Note that the TCP connection has not been released yet. A must enter the CLOSED state after the time 2MSL set by the TIME-WAIT timer (the reason is for B to enter CLOSED according to normal steps, and for the presence of an invalid connection request segment) before A enters the CLOSED state. The time MSL is called the longest segment lifetime, and RFC793 recommends setting it to 2 minutes. once. After entering the TIME-WAIT state from A, it takes 4 minutes to enter the CLOSED state before establishing the next new connection. When A withdraws the corresponding transmission control block TCB, this TCP connection is ended.
As long as B receives the confirmation sent by A, it enters the CLOSED state. Similarly, B ends the TCP connection this time after revoking the corresponding transmission control block TCB. We notice that B ends the TCP connection earlier than A.
This article refers to "Computer Network" edited by Xie Xiren