[TCP/IP] Detailed explanation of three-way handshake and four-way wave, as well as some abnormal situations

write in front

Six flags

TCP's urg, ack, psh, rst, syn, and fin are the six flag bits in the TCP protocol, which are used to control the establishment, maintenance, and closing of TCP connections.

Flag bit Logo description
URG(Urgent) Indicates urgent data. When this flag is set, it indicates that the urgent data in the TCP packet needs to be transmitted as soon as possible.
ACK(Acknowledgment) Indicates confirmation, used to confirm the sequence number of the received data packet, indicating the sequence number of the next byte that the receiver expects to receive.
PSH(Push) Indicates push. When this flag is set, it indicates that the sender should send data to the receiver as soon as possible without waiting for the buffer to fill up.
RST(Reset) Indicates reset. When this flag is set, it indicates that an error occurred in the TCP connection and needs to be reset, that is, the connection is forcibly closed.
SYN(Synchronize) Indicates synchronization, used to exchange synchronization sequence numbers when establishing a connection, that is, the sender and receiver negotiate the initial sequence number.
FIN(Finish) Indicates the end. When this flag is set, it indicates that the sender has finished sending all data and requests to close the connection.

Different combinations and setting states of these flag bits can achieve different TCP connection states and control operations.

ISN (Initialization Serial Number)

Initialization sequence number (English: Initial Sequence Number, referred to as ISN).

three handshakes

basic process

The three-way handshake is the process of establishing a TCP connection, which ensures that communication between the client and the server can proceed normally. The following is the detailed process of the three-way handshake:

1. The client sends a SYN segment: (SYN=1, ACK=0, ISNx)
The client sends a TCP segment to the server, in which the SYN flag is set to 1, indicating that the client requests to establish a connection. The client will also select a random initial sequence number (ISN, which can be recorded as ISNx) as the starting sequence number, and place this ISNx in the sequence number field of the message segment.

2. The server sends a SYN-ACK message segment: (SYN=1,ACK=1, ISNY,ISNx+1)
After the server receives the client's SYN segment, it will send a TCP segment in response. The SYN flag is set to 1, indicating that the server agrees to establish a connection. The server will also select a random initial sequence number (ISN, which can be recorded as ISNy) and place this ISNy in the sequence number field of the message segment. At the same time, the server will set the confirmation number field to the client's ISNx plus 1, indicating that it confirms receipt of the client's initial sequence number. In this way, both the server and the client know each other's initial sequence number.

3. The client sends an ACK message segment: (SYN=0, ACK=1, ISNY+1, ISNx+1)
After the client receives the server's SYN-ACK segment, it will send a TCP segment as confirmation. The ACK flag is set to 1, indicating the initial sequence number of the confirmation server. The client will set the confirmation number field to the server's ISN plus 1, indicating confirmation of receipt of the server's initial sequence number. At the same time, the client will also put its own initial serial number in the serial number field.

After these three handshakes, both the client and the server know the other party's initial sequence number and confirm the other party's initial sequence number. At this point, the TCP connection is successfully established and both parties can start data transmission.

It should be noted that during the three-way handshake, each message segment sent needs to wait for confirmation from the other party before proceeding to the next step. This ensures that both parties receive each other's packets correctly and establish a reliable connection.

abnormal situation

During the three-way handshake, some abnormal situations may occur, such as timeout, packet loss, repeated transmission, etc. Here are several possible exceptions and how to handle them:

1. Timeout : If a message segment in a certain stage does not receive a response from the other party within a certain period of time, a timeout will occur. This may be due to network latency or congestion. The way to handle timeout is to resend the corresponding message segment until a response from the other party is received or the maximum number of retransmissions is reached.

2. Packet loss : During network transmission, message segments may be lost. This may be due to network congestion, link failure, etc. The way to deal with packet loss is to wait for a period of time. If no response is received from the other party within a certain period of time, resend the corresponding message segment.

3. Repeated sending : During network transmission, message segments may be sent repeatedly. This may be caused by network delay, retransmission after packet loss, etc. The way to handle repeated transmission is that when the receiver receives a duplicate segment, it ignores the duplicate segment and only processes the first received segment.

4. Wrong sequence number : During the three-way handshake, if the sequence number received by the receiver is incorrect, the connection establishment may fail. The way to handle incorrect sequence numbers is to resend the corresponding segment until the receiver receives the correct sequence number.

5. Rejection of connection : During the three-way handshake, the server may reject the client's connection request. This may be caused by insufficient server resources, access restrictions, etc. The way a rejected connection is handled is that the client can try to connect to another available server, or wait for a period of time and then resend the connection request.

The above are some possible abnormal situations and handling methods. The specific handling methods will vary according to the specific network environment and application scenarios. In practical applications, factors such as network security and performance optimization also need to be considered to ensure the reliability and stability of the connection.

Abnormal downtime situation

If the server or client goes down during the three-way handshake, different situations will occur:

Server down:
If the server goes down after the client sends the SYN segment, the client will not be able to receive the server's response. The client will wait for a period of time. If it does not receive a response from the server within the timeout period, the client will resend the SYN segment. This process will be repeated multiple times until the client reaches the maximum number of retransmissions.

If the server recovers before the client reaches the maximum number of retransmissions, the client will receive a response from the server and the connection can continue to be established. But if the server recovers after the client reaches the maximum number of retransmissions, the connection establishment will fail.

Client down:
If the client goes down after the server receives the client's SYN segment, the server will not be able to receive the client's confirmation. The server will wait for a period of time. If no confirmation is received from the client within the timeout period, the server will resend the SYN-ACK segment. This process will be repeated multiple times until the server reaches the maximum number of retransmissions.

If the client recovers before the server reaches the maximum number of retransmissions, the server receives an acknowledgment from the client and the connection can continue to be established. But if the client resumes after the server reaches the maximum number of retransmissions, the connection establishment will fail.

In summary , during the three-way handshake, if one of the parties goes down, the connection establishment will fail. In order to avoid this situation, you can improve the reliability of the connection by setting a reasonable timeout and number of retransmissions. In addition, you can also use the heartbeat mechanism to detect the survival status of the connection and detect and handle downtime in a timely manner.

heartbeat mechanism

The heartbeat mechanism is a method for detecting the aliveness of a connection. It confirms the availability of the connection by sending heartbeat messages periodically.

In network communication, the sender regularly sends heartbeat messages to the receiver. After receiving the heartbeat message, the receiver can send a confirmation message to the sender to indicate that the connection is still alive.

The heartbeat mechanism works as follows:

1. The sender sends heartbeat messages regularly:
The sender sends heartbeat messages to the receiver regularly, usually at a fixed time interval. The heartbeat message can be a specific message or a simple PING message, which is used to inform the receiver of the survival status of the connection.

2. The receiver receives the heartbeat message:
The receiver will listen for the heartbeat message on the specified port and wait for the arrival of the heartbeat message. Once the heartbeat message is received, the receiver knows that the sender is still active.

3. The receiver sends a confirmation message:
After receiving the heartbeat message, the receiver can choose to send a confirmation message to the sender to indicate that the connection is still alive. The confirmation message can be a specific message or a simple PONG message.

4. The sender receives the confirmation message:
After sending the heartbeat message, the sender waits for a period of time to receive the confirmation message from the receiver. If the sender receives an acknowledgment within the timeout period, it knows the connection is still alive. If no acknowledgment message is received after the timeout period, the sender can consider the connection to be disconnected.

Through the heartbeat mechanism, the sender and receiver can periodically exchange heartbeat messages to confirm the survival status of the connection . If no heartbeat message or confirmation message is received within a certain period of time, it can be considered that the connection has been disconnected, and corresponding processing measures can be taken, such as re-establishing the connection or performing error handling.

The heartbeat mechanism is widely used in network communications, especially in long connection scenarios, such as TCP, WebSocket and other protocols, to maintain the stability and reliability of the connection.

wave four times

basic process

Four waves is the process used to close a TCP connection, and it includes the following steps:

1. The sender sends a close connection request: (FIN=1)
The sender first sends a FIN (Finish) message segment to the receiver, indicating that the sender has no data to send and hopes to close the connection. Sender entersFIN_WAIT_1state.

2. The receiver sends a confirmation closing request: (ACK=1)
After receiving the sender’s FIN segment, the receiver sends an ACK (Acknowledgment) segment to the sender to confirm the closing request. Receiver entersCLOSE_WAITstate.

3. The receiver sends a close connection request: (FIN=1,)
After the receiver sends all the data, it will also send a FIN segment to the sender, indicating that the receiver has no data to send and also hopes to close the connection. . Receiver entersLAST_ACKstate.

4. The sender sends a confirmation closing request: (ACK=1)
After receiving the receiver’s FIN segment, the sender sends an ACK segment to the receiver to confirm the closing request. Sender entersTIME_WAITstate.

In the TIME_WAIT state, the sender will wait for a period of time (usually 2 times the maximum segment survival time, or 2MSL) before closing the connection.

This waiting time is to ensure that the receiver receives the sender's confirmation and that the receiver's confirmation can also be communicated to the sender.

If the sender receives the FIN segment in the TIME_WAIT state, it means that the receiver has not received the ACK segment (Because the receiver is in the LAST_ACK state at this time, it is waiting for the sender's ACK segment to enter the next state. If the ACK segment is not received, it will resend a FIN segment.)
Then the sender will continue to send ACK segments and enter the TIME_WAIT state. It will enter the CLOSED state to close the connection until the FIN segment is not received until the end of the time.

After the waiting time expires, the sender closes the connection and entersCLOSEDstatus, the connection is completely closed.

After receiving the confirmation from the sender, the receiver will also close the connection and enterCLOSEDstate.

It should be noted that during the four waves, each message segment requires confirmation from the other party. This is because TCP is a reliable protocol, ensuring reliable transmission of data.

By waving four times, both parties can negotiate and confirm the closure of the connection, ensuring data integrity and reliability.

Guess you like

Origin blog.csdn.net/m0_50401435/article/details/131573307