When talking about the process of establishing and releasing connections in TCP, let's briefly understand several terms in the format of the header of the TCP segment (this is just a brief description, please refer to the relevant tutorials for details)
Sequence number seq: 4 bytes, used to mark the sequence of data segments, TCP codes all data bytes sent in the connection with a sequence number, and the number of the first byte is randomly generated locally; After the sequence number is added, a sequence number is assigned to each segment; the sequence number seq is the data number of the first byte in the segment. Acknowledgement number ack: occupies 4 bytes, expecting to receive the sequence number of the first data byte of the next segment of the other party; the sequence number indicates the number of the first byte of data carried in the segment; and the acknowledgement number refers to is the number of the next byte expected to be received; therefore, the number of the last byte of the current segment + 1 is the acknowledgment number. Confirm ACK: occupy 1 bit, the confirmation number field is valid only when ACK=1. When ACK=0, the acknowledgment number is invalid. Synchronization SYN: It is used to synchronize the sequence number when the connection is established. When SYN=1, ACK=0, it means: this is a connection request segment. If the connection is agreed, make SYN=1 and ACK=1 in the response segment. Therefore, SYN=1 indicates that this is a connection request, or a connection accept message. The SYN flag will only be set to 1 when the TCP connection is established, and the SYN flag will be set to 0 after the handshake is completed. Terminate FIN: used to release a connection. FIN=1 means: the data of the sender of this segment has been sent, and the transport connection is requested to be released
PS: The uppercase words of ACK, SYN and FIN represent flag bits, and their value is either 1 or 0; the lowercase words of ack and seq represent serial numbers.
1. TCP establishes a connection three-way handshake
(1) The process of three-way handshake
1) Host A sends a TCP connection request packet to host B, which contains the initial sequence number of host A seq(A)=x. (The synchronization flag bit SYN=1 and ACK=0 in the message indicate that this is a TCP connection request data message; the sequence number seq=x indicates that the sequence number of the first data byte when transmitting data is x) ;
2 ) After host B receives the request, it will send back a connection confirmation packet. (In the confirmation segment, the identification bit SYN=1, ACK=1, indicating that this is a TCP connection response data message, and contains the initial sequence number seq(B)=y of host B, and host B to host A The confirmation number of the initial serial number ack(B)=seq(A)+1=x+1)
3) For the third time, after host A receives the confirmation message from host B, it needs to confirm, that is, send a serial number seq(A)=x+1; the message whose confirmation number is ack(A)=y+1;
(2) Why is the third handshake needed?
It is necessary to send an acknowledgment again to prevent the failed connection request segment from being suddenly transmitted to B, resulting in an error.
Invalid segment: Under normal circumstances: A sends a connection request, but because it is lost, it cannot receive an acknowledgement from B. So A re-sends the request, then receives the confirmation, establishes the connection, and releases the connection after the data transmission is completed. A sends 2, one is lost, the other arrives, and there is no "invalid segment".
However, under certain circumstances, The first one of A is stranded at a certain node and arrives with a delay. Originally this is a segment that has already expired, but after A sends the second one and gets a response from B, after the connection is established, this segment is actually Arrived, so B thinks that A has sent a new request, so it sends a confirmation segment and agrees to establish a connection. If there is no three-way handshake, then the connection is established (there is a request and a response), At this time, A receives the confirmation from B, but A knows that it has not sent a request to establish a connection, because it will ignore this confirmation from B, so A will not send any data, but B thinks that a new connection It has been established and has been waiting for A to send data to itself. At this time, B's resources are wasted. However, if the three-way handshake is used, A does not send an acknowledgement, and since B cannot receive the acknowledgement, it also knows that the connection is not required to be established.
In short: In the third handshake, host A sends a confirmation to prevent: if the client does not receive the confirmation message returned by the server for a long time, then he will give up the connection and restart a connection request; but the problem is : The server does not know that the client has not received it, so he will receive two connection requests, wasting a connection overhead.
Two, TCP releases the connection four-way handshake
(1) Four-way handshake process
Assuming that host A is the client and host B is the server, the process of releasing the TCP connection is as follows:
1) Close the connection from the client to the server: First, client A sends a FIN to close the data transfer from the client to the server, and then waits for the confirmation from the server. The termination flag bit FIN=1, the serial number seq=u
2) The server receives this FIN, it sends back an ACK, and the acknowledgment number ack adds 1 to the received sequence number.
3) Close the connection from the server to the client: also send a FIN to the client.
4) After the client segment receives the FIN, it sends an ACK message to confirm, and sets the confirmation sequence number seq to the received sequence number plus 1.
The side that shuts down first will perform an active shutdown, while the other side performs a passive shutdown.
After host A sends FIN, it enters the termination waiting state. After receiving the connection release segment of host A, server B immediately sends an acknowledgement to host A, and then server B enters the close-wait state. At this time, the TCP server process notifies the upper layer. application process, so the connection from A to B is released. This is the " half closed " state. That is, A cannot send to B, but B can send to A.
At this time, if B has no datagram to send to A, its application process notifies TCP to release the connection, and then sends the connection release segment to A, and waits for confirmation. After A sends the confirmation, it enters time-wait. Note that the TCP connection has not been released at this time, and then A enters the close state after waiting for the 2MSL set by the timer.
(2) Why wait for 2MSL ?
MSL is Maximum Segment Lifetime, which is the maximum packet lifetime . It is the longest time for any packet to exist on the network. After this time, the packet will be discarded. To quote from "TCP/IP Explained": "It (MSL) is the maximum time in the network before any segment is discarded". RFC 793 stipulates that the MSL is 2 minutes, and in practical applications, 30 seconds, 1 minute and 2 minutes are commonly used.
The TIME_WAIT state of TCP needs to wait for 2MSL. When one end of TCP initiates an active shutdown, it enters the TIME_WAIT state after sending the last ACK packet, that is, after the third handshake is completed and the ACK packet of the fourth handshake is sent, which must be here. Staying in the state for twice the MSL time, the main purpose of waiting for 2MSL time is to fear that the last ACK packet is not received by the other party, then the other party will resend the FIN packet of the third handshake after the timeout, and actively close the terminal to receive the retransmitted FIN packet. After that, an ACK response packet can be sent again. In the TIME_WAIT state, the ports at both ends cannot be used, and can continue to be used until the 2MSL time expires. Any late segments will be discarded while the connection is in the 2MSL wait phase. However, in practical applications, you can set the SO_REUSEADDR option so that you don't have to wait for the end of 2MSL to use this port.
The reasons are summarized as follows:
1. In order to ensure that the last ACK segment sent by A can reach B. That is, the last acknowledgment segment is likely to be lost, then B will retransmit it over time, and then A will confirm again, and start the 2MSL timer at the same time, and so on. If there is no waiting time, if the connection is released immediately after sending the confirmation segment, B cannot retransmit (the connection has been released, and no data can be sent out), so the confirmation cannot be received, and the steps cannot be followed. Enter the CLOSE state, that is, you must receive confirmation to close.
②, to prevent "invalid connection request segment" from appearing in the connection. After 2MSL, all segments generated during the duration of this connection can disappear from the network. That is to say, during the connection release process, there will be some invalid message segments stranded at the pavilion node, but after 2MSL these invalid message segments can definitely be sent to the destination and will not stay in the network. In this case, the request segment left over from the previous connection will not appear in the next connection.
It can be seen that B ends the TCP connection a little earlier than A, because B disconnects after receiving the confirmation, and A has to wait for 2MSL.
(3) Why does it take four times for TCP to release the connection?
A TCP connection requires a three-way handshake, and a disconnection requires four. This is due to the half-close of TCP. Because TCP connections are full-duplex (that is, data can be passed in both directions at the same time), each direction must be closed separately when closing. This unidirectional closing is called half closing. When one party completes its data transmission task , it sends a FIN to notify the other party that the connection in this direction will be terminated.
Notice:
1) Sending FIN just means that this end cannot continue to send data (the application layer can no longer call send to send), but it can still receive data. Receiving a FIN only means that there is no data flow in this direction. A TCP connection can still send data after receiving a FIN. For example, if host A receives a FIN from host B to disconnect the TCP connection request, it just means that host B has After sending the data, the host A responds after receiving the FIN, and terminates the data transmission in this direction, and is in a semi-closed state at this time. But host A can still send data. Only when host A finishes sending data and sends FIN to host B, host B stops data transmission in this direction and closes the TCP connection.
2) In many cases, the disconnection of the TCP connection will be automatically performed by the TCP layer. For example, if you terminate your program with CTRL+C, the TCP connection will still be closed normally. You can write code to try.
