TCP three-way handshake and four-way handshake

TCP Overview

TCP regards the connection as the most basic object. Each TCP connection has two endpoints. This breakpoint is called socket ), it is defined as a socket formed by splicing the port number to the IP address. For example, if the IP address is 192.3.4.16 and the port number is 80, the resulting socket is 192.3.4.16: 80.

However, for TCP-based communication, a two-way channel is established between the client and the server on the logic layer before communication. Note that on the logic layer, the physical layer is only a communication medium.

Suppose we build a road between A and B. I am at a. I want to tell B, "I want to build a road to your place." B agreed, so the road is repaired. But this can only be A to B. You can't drive in reverse direction, so you have to repair one from B to A. Then B tells, "I also want to build a path to your place." A agreed, so that a two-way path was repaired.

The above is the connection established by four requests or responses, but in the network, B's consent and request are used as a route. Because the efficiency of a software depends on the slowest point. If a and B constitute a software based on TCP communication, the execution efficiency of the software is measured by the efficiency of A, B, and the overall network, the network is the slowest point. The network delay time is limited by the existing physical level and cannot be solved. In program development, the fewer network transmission times, the better, the less time the network latency is.

In fact, the purpose of TCP three-way handshake is to establish a two-way channel for data transmission. However, no real data is being transmitted at this time, and TCP three-way handshake is preparing for data transmission, therefore, we need to quickly establish a two-way path, so the two in the middle can be used as one (because data is not transmitted at this time). This is the real three-way handshake, the reason for this introduction is to understand the four broken connections.

TCP packet header

1) The source port and the destination port each occupy 2 bytes, respectively written to the source port and the destination port;

2) The sequence number occupies 4 bytes. Each byte in the byte stream transmitted in the TCP connection is numbered sequentially. For example, the serial number field value of a packet is 301, and the data carried is a total of 100 fields. It is clear that the serial number of the next packet segment (if any) should start from 401;

3) The confirmation number (4 bytes) is the sequence number of the First Data byte expected to receive the next packet from the other party. For example, if B receives a packet sent by a, its serial number field is 501, and the data length is 200 bytes, this indicates that B has correctly received the data sent by a to sequence 700. Therefore, B expects that the next data sequence number received by a is 701, So B sets the confirmation number to 701 in the confirmation message segment sent to;

4) Data offset, which occupies 4 digits. It indicates how far the data of the TCP packet is from the beginning of the TCP packet segment;

5) reserved, which occupies 6 places. reserved for future use, but currently all places should be 0;

6) URG. When URG = 1, it indicates that the emergency pointer field is valid. Tell the system that there is urgent data in this packet segment;

7) Confirm ack. The check number field is valid only when ACK = 1. TCP stipulates that ack must be set to 1 for transmission of all packets after the connection is established;

8) Push Psh. When two application processes perform interactive communication, sometimes the application process at one end needs to receive the response from the other side immediately after a command is entered, in this case, PSH = 1;

9) reset the RST. When RST is set to 1, it indicates a serious error occurred in the TCP connection. You must release the connection and then re-establish the connection;

10) synchronize SYN, which is used to synchronize serial numbers when a connection is established. When SYN = 1, ACK = 0, it indicates a connection request message. If you agree to the connection, the response message should make SYN = 1, ACK = 1;

11) terminate fin to release the connection. When fin = 1, it indicates that the data of the sender of the message has been sent and needs to be released;

12) the window occupies 2 bytes. It refers to the notification recipient. how much space do you need to accept to send this article;

13) check, which occupies 2 bytes. Check the header and data;

14) the emergency pointer occupies 2 bytes, indicating the number of bytes of emergency data in this section;

15) optional, variable length, defining some other optional parameters.

Three-way handshake for TCP connection Establishment

At the beginning, both the client and server were in the closed state. The client actively opens the connection, and the server passively opens the connection.

1) The TCP server process first creates a transmission control block TCB and is always ready to accept connection requests from the client process. Then the server enters the listen status;

2) The tcp client process also first creates a transmission control block TCB, and then sends a connection request packet to the server. This is the synchronization bit SYN = 1 in the packet header, and selects an initial serial number seq = x. TCP stipulates that the SYN packet segment (the SYN = 1 packet segment) cannot carry data, but a sequence number must be consumed. At this point, the tcp client process enters the SYN-SENT (synchronous sent State) state.

3) After receiving the request message, the TCP server will send a confirmation message if it agrees to connect. Check that the message should contain ACK = 1, SYN = 1, ACK = x + 1, and initialize a sequence number seq = Y for yourself, the TCP server process enters the SYN-RCVD (synchronously received) state. This packet cannot carry data, but it also consumes a serial number.

4) After receiving the confirmation, the tcp client process should also confirm with the server. Confirm the ACK = 1, ACK = Y + 1, and the serial number seq = x + 1. At this time, the TCP connection is established, and the client enters the established (established connection) status. TCP stipulates that ACK packets can carry data, but no serial number is consumed if no data is carried.

5) when the server receives the confirmation from the client, it also enters the established status, and then both parties can start to communicate.

Why does the tcp client send a confirmation message?

This is mainly to prevent the invalid connection request packet segment from being suddenly transmitted to the server, thus generating errors.

Assume that a connection request message segment sent by the client is not lost during transmission, but is stuck on a network node for a long time, so that the connection will arrive at the server at a certain time after the connection is released. This is a long-overdue packet segment. However, after the server receives the invalid Connection Request Message segment, it mistakenly thinks that the client has sent a new connection request, so it sends a confirmation message segment to the client and agrees to establish a connection. If three handshakes are not used, the new connection is established as long as the server sends a confirmation.

Because the client does not send a connection request, it does not accept the confirmation from the server or send data to the server. However, the server thought that the new transportation connection had been established and waited for the client to send data, which wasted a lot of resources.

TCP three-way handshake can prevent the above phenomenon. For example, as the client did not send a confirmation to the server just now, the server knows that the client does not require a connection because it cannot receive the confirmation.

Four Waves of TCP release connection

The purpose of TCP three-way handshake is to establish a two-way channel for data transmission. After the data transmission is completed, both parties can release the connection. At the beginning, the client and server are both in the established State, and the client closes the server.

1) The client process sends a connection release packet and stops sending data. Release the data packet header, fin = 1, and its serial number is seq = U (equal to the serial number of the last byte of the previously transmitted data plus 1). At this time, the client enters the fin-wait-1 (Termination wait 1) status and waits for confirmation from the server.

2) When the server receives a connection release packet and sends a confirmation packet, ACK = 1, ACK = u + 1, and its serial number seq = V, the server enters the close-Wait (close Wait) status. The TCP server notifies the High-level application process, and the client is released to the server. At this time, it is in the semi-closed state, that is, the client has no data to send, but if the server sends data, the client still needs to accept it. This status lasts for a while, that is, the entire close-Wait Status.

3) after the client receives the server's confirmation request, the client enters the fin-wait-2 (Stop wait 2) status, wait for the server to send the connection release packet (before that, the server must accept the final data sent ).

4) after the server sends the final data, it sends the connection release packet to the client, fin = 1, ACK = u + 1, because it is in the semi-closed status, the server is likely to send some data again, assuming that the serial number is seq = W at this time, the server enters the LAST-ACK (final confirmation) state, waiting for the client to confirm.

5) After receiving the server connection release packet, the client must confirm that ACK = 1, ACK = W + 1, and its serial number is seq = u + 1, the client enters the time-Wait Status. Note that the TCP connection has not been released yet. The TCP connection enters the closed State only after 2msl (maximum message segment life) is elapsed and the client revokes the corresponding TCB.

6) The server immediately enters the closed status after receiving confirmation from the client. Similarly, the TCP connection ends after the TCB is revoked. At this point, the entire process of TCP disconnection is completed four times. As you can see, the server end the TCP connection earlier than the client.

 Why is the client still waiting for 2msl?

MSL (maximum segment lifetime), TCP allows different implementations to set different MSL values.

First, ensure that the last ACK packet sent by the client can reach the server because the ACK packet may be lost. From the server's perspective, I have sent the FIN + ACK packet request to be disconnected, the client has not responded to me. It should be because the disconnection packet sent by me has not been received, and the server will send it again, the client can receive the retransmission packet in this 2msl period, then provide the response packet, and restart the 2msl timer.

Second, prevent the "invalid connection request packet segment" mentioned in the "three-way handshake" from appearing in this connection. After the client sends the last validation packet, all the packet segments generated during the connection duration will disappear from the network during this 2msl time. In this way, the request packets of the old connection will not appear in the new connection.

Why is it because the three-way handshake is established and the connection is closed for four times?

When a connection is established, the server receives the SYN Packet Of the connection request in the listen state, and then places ack and SYN in a packet and sends it to the client.
When the connection is closed, when the server receives the fin message from the other party, it only means that the other party no longer sends data but can still receive the data, and it may not send all the data to the other party, therefore, you can immediately disable the connection, send some data to the other party, and then send a fin message to the other party to agree to close the connection. Therefore, both ack and fin are generally sent separately, this leads to one more time.

What if a connection has been established but the client suddenly fails?

TCP also has a life-saving timer. Obviously, if the client fails, the server won't be able to wait until it is wasted. The server resets the timer every time it receives a request from the client. The timer is usually set to 2 hours. If no data is received from the client within two hours, the server sends a detection packet segment, which is sent every 75 minutes. If the server still does not respond when sending 10 detection packets in a row, the server considers the client to be faulty and closes the connection.

TCP three-way handshake and four-way handshake