directory title
1. TCP Retransmission (TCP Retransmission)
1.1 Retransmission Principles and Mechanisms
TCP (Transmission Control Protocol) is a connection-oriented, reliable transport layer protocol. In order to ensure the reliable transmission of data, TCP adopts the strategy of data packet retransmission to deal with problems such as packet loss, error packet, and out-of-sequence that may occur during the transmission process in the network. Below we introduce the principle and mechanism of TCP retransmission in detail.
(1) Acknowledgment Mechanism
In TCP communication, the receiver will return an acknowledgment message (ACK) after receiving the data packet to notify the sender that the data has been successfully received. The sender waits for the receiver to return a confirmation message after sending the data packet. If no confirmation message is received within the specified time, the sender will consider the data packet lost and trigger the retransmission mechanism.
(2) Sliding window (Sliding Window)
TCP uses the sliding window mechanism to implement flow control and congestion control. The sender's window size determines the number of packets it can send. When the receiver returns an acknowledgment message, the sender's window slides and can continue to send new data packets. If there are unacknowledged data packets, the window will no longer slide until the confirmation packet is received or the retransmission mechanism is triggered.
(3) Sequence Number
TCP assigns an independent sequence number to each data packet to ensure the orderly transmission of data packets. After receiving the data packets, the receiver will sort the data packets according to the sequence numbers to ensure the correctness of the final transmission results. If the receiver detects data packets with discontinuous sequence numbers, it means that there is packet loss in the middle, and will request the sender to retransmit.
(4) Retransmission Timer
The TCP sender maintains a retransmission timer to monitor each data packet that has been sent but has not received an acknowledgment message. When the timer expires, the sender will consider the corresponding data packet lost and trigger the retransmission mechanism. In order to cope with different network environments, TCP also adopts an adaptive timer adjustment strategy to dynamically adjust the timeout threshold.
Summary: The core of the TCP retransmission principle and mechanism is to ensure the reliable transmission of data through various means such as confirmation mechanism, sliding window, sequence number and retransmission timer. When the sender does not receive the confirmation message from the receiver, it will resend the data packet through the retransmission mechanism, so as to ensure the integrity and correctness of data transmission.
1.2 Conditions for Retransmission Triggering
The TCP retransmission mechanism is a key strategy designed to ensure reliable data transmission. In order to better understand TCP retransmission, we need to understand the specific conditions that trigger retransmission. The following are the main situations that lead to TCP retransmissions:
(1) Timeout Retransmission
When the sender sends a data packet, it will start a retransmission timer and wait for the receiver to return a confirmation message. If the acknowledgment message is not received before the timer expires, the sender will consider the data packet lost and trigger a timeout retransmission. The time threshold for overtime retransmission will be dynamically adjusted according to network conditions.
(2) Fast retransmission (Fast Retransmission)
Fast retransmission is a retransmission strategy to improve TCP performance. When the receiver receives three acknowledgment messages (Duplicate ACKs) with the same sequence number consecutively, the sender will consider that the corresponding data packet is lost. In order to resend lost data packets as soon as possible, the sender will retransmit immediately without waiting for the retransmission timer to expire. This approach reduces delays due to packet loss.
(3) Selective Acknowledgment Retransmission (Selective Acknowledgment Retransmission)
Selective Acknowledgment (SACK) is a TCP extension that allows a receiver to inform a sender which packets have been successfully received and which need to be retransmitted. SACK can improve TCP performance, because the sender can know which data packets need to be retransmitted more accurately, and avoid unnecessary full retransmission.
(4) Congestion-triggered Retransmission
Retransmissions may be triggered when the sender detects network congestion. This is because in a congestion situation, the probability of packet loss increases, causing the sender to need to resend the packet. Congestion control algorithms (such as TCP Tahoe, Reno, NewReno, etc.) will dynamically adjust the sender's window size and limit the sending rate when congestion occurs, thereby reducing the degree of congestion.
To sum up, the TCP retransmission trigger conditions include timeout retransmission, fast retransmission, selective acknowledgment retransmission and congestion-triggered retransmission. Understanding these trigger conditions helps us better understand the TCP retransmission mechanism and provides ideas for network performance optimization.
1.3 Retransmission Strategy Optimization
In order to improve TCP transmission performance and reduce the delay caused by retransmission, we can optimize the TCP retransmission strategy from the following aspects:
(1) Optimizing Retransmission Timer (Optimizing Retransmission Timer)
Adjust the timeout threshold of the retransmission timer to make it more suitable for the current network environment. For example, an adaptive adjustment strategy is adopted to dynamically adjust the retransmission timeout (RTO) value in combination with round-trip time (RTT) and round-trip time variation (RTTVAR). Reduce unnecessary retransmission delays and improve TCP transmission performance.
(2) Enable Fast Retransmission and Fast Recovery (Enabling Fast Retransmission and Fast Recovery)
Fast retransmission and fast recovery mechanisms can reduce delays caused by packet loss. When the sender receives three repeated acknowledgment messages in a row, it retransmits immediately without waiting for the retransmission timer to expire. The fast recovery algorithm allows the sender to continue to transmit new data packets after fast retransmission, avoiding global synchronization and improving network throughput.
(3) Use Selective Acknowledgment
Enables the Selective Acknowledgment (SACK) mechanism, allowing the receiver to more precisely tell the sender which packets have been received and which need to be retransmitted. In this way, the sender can avoid unnecessary full retransmission, and only resend the lost data packets, improving transmission efficiency.
(4) Optimizing Congestion Control Algorithms
Choose a congestion control algorithm that is more suitable for the current network environment, such as CUBIC, BBR, etc., to reduce retransmissions triggered by congestion. These algorithms can more effectively control the sending rate, avoiding packet loss and increased latency due to congestion.
(5) Using forward error correction technology (Forward Error Correction, FEC)
Forward error correction technology can improve the reliability of data transmission without increasing the number of retransmissions. By adding redundant information to the data packets, the receiver can still try to recover the original data when receiving partially damaged or lost data packets. In this way, even in a network environment with a high packet loss rate, the integrity and accuracy of data transmission can be guaranteed.
By optimizing the retransmission strategy, we can improve network performance and user experience without affecting TCP reliability. The specific optimization method needs to be selected and adjusted according to the actual network environment and application requirements.
Two, TCP timeout (TCP Timeout)
2.1 Timeout Detection Principles
TCP timeout means that the sender fails to receive the confirmation message within the predetermined time while waiting for the receiver to return the confirmation message after sending the data packet. Timeout detection is one of the key mechanisms in the TCP protocol to ensure reliable data transmission. In this section, we will discuss the principle of TCP timeout detection in detail.
(1) Round-trip time (Round-Trip Time, RTT)
The round-trip time refers to the time it takes for a data packet to be sent from the sender to the time it takes for the receiver to return an acknowledgment message. The sender needs to estimate the RTT in order to set an appropriate timeout threshold according to the network conditions. Estimates of RTT are usually based on how long it takes for a packet to be sent and acknowledged.
(2) Retransmission Timeout (RTO)
RTO is the maximum time that the sender waits for the receiver to return an acknowledgment message. When the sender does not receive the confirmation message within the RTO, the retransmission mechanism will be triggered. In order to adapt to different network environments, the sender needs to dynamically adjust the RTO value according to the RTT.
(3) Weighted average round-trip time (Smoothed Round-Trip Time, SRTT) and round-trip time variation (Round-Trip Time Variation, RTTVAR)
TCP senders typically use Weighted Average Round Trip Time (SRTT) and Round Trip Time Variation (RTTVAR) to estimate the RTT of the current network. SRTT is a weighted average of historical RTTs, and RTTVAR is the magnitude of change in historical RTTs. The combination of these two values can more accurately reflect the network conditions and help the sender set an appropriate RTO.
(4) Karn/Partridge algorithm
The Karn/Partridge algorithm is a method for dealing with the RTT estimation problem of retransmitted packets. Using the original RTT directly may lead to misestimation of the RTO when packets are retransmitted. The Karn/Partridge algorithm avoids the misestimation problem and improves the accuracy of timeout detection by not updating the SRTT and RTTVAR values during the retransmission process.
To sum up, the principle of TCP timeout detection mainly includes RTT estimation, RTO setting, SRTT and RTTVAR calculation and Karn/Partridge algorithm. Understanding these principles will help us better understand the TCP timeout mechanism and provide a basis for optimizing network performance.
2.2 Timeout Detection Optimization
In order to reduce the impact of TCP timeout on network performance, we can optimize the timeout detection mechanism from the following aspects:
(1) Accurate estimation of round-trip time (Accurate RTT Estimation)
Improving the accuracy of round-trip time estimates helps to set an appropriate retransmission timeout threshold. The sender can estimate the RTT of the current network by weighting the historical RTT and calculating the RTT variation range. More accurate RTT estimation can avoid triggering retransmission too early or too late, and improve network performance.
(2) Dynamically adjust the retransmission timeout (Dynamic RTO Adjustment)
Dynamically adjust the retransmission timeout threshold according to network conditions. The sender can combine the SRTT and RTTVAR values to calculate an appropriate RTO. Dynamically adjusting RTO can make the sender respond more sensitively to network changes and reduce unnecessary retransmission delays.
(3) Use more accurate timeout detection algorithms (Employing More Accurate Timeout Detection Algorithms)
Choose a more accurate timeout detection algorithm, such as the Karn/Partridge algorithm, to improve the accuracy of timeout detection. The Karn/Partridge algorithm can avoid misestimation problems when processing retransmission packets, thereby improving the accuracy of timeout detection and network performance.
(4) Try to use more advanced transport protocols (Exploring Advanced Transport Protocols)
Consider using some advanced transport protocol with better timeout detection mechanism, such as QUIC. The QUIC protocol uses a single encrypted connection, reducing handshake and timeout delays. In addition, QUIC also adopts a new packet loss recovery mechanism, which can perform packet retransmission without relying on retransmission timeout, thereby reducing latency.
By optimizing the timeout detection mechanism, we can reduce the impact of timeouts on network performance while maintaining TCP reliability. The specific optimization method needs to be selected and adjusted according to the actual network environment and application requirements.
2.3 Impact of Timeout on Network Performance
While ensuring the reliability of data transmission, the TCP timeout mechanism has a certain impact on network performance. In this section, we discuss how timeouts affect network performance.
(1) Increased Latency
When a TCP timeout occurs, the sender needs to wait for the retransmission timer to expire before resending the data packet. This increases the overall time for data transfers, resulting in increased network latency. In network environments with high packet loss rates, latency issues may become more severe.
(2) Decreased Throughput
TCP timeouts can cause the sender's send window to decrease, limiting the sending rate. Since the sender needs to wait for the confirmation message, a long timeout may cause the sender to wait for a long time, further reducing the network throughput.
(3) Affected Congestion Control
TCP timeouts are closely related to congestion control. When the timeout occurs, the sender usually thinks that the network is congested, thus triggering the congestion control algorithm. This causes the sender to reduce the sending rate to alleviate network congestion. However, in some cases, too early or too late timeout may lead to misjudgment of the congestion control algorithm and affect network performance.
(4) Global Synchronization (Global Synchronization)
TCP timeouts may cause global synchronization phenomena. When multiple TCP connections experience timeouts and retransmissions at the same time, their send window size and send rate may decrease synchronously, resulting in fluctuations in network throughput. The phenomenon of global synchronization may lead to waste of network resources and performance degradation.
By understanding the impact of timeouts on network performance, we can better optimize the TCP protocol and improve network performance. In practical applications, we can reduce the impact of timeouts on network performance by adjusting timeout detection strategies, optimizing congestion control algorithms, and trying to use advanced transport protocols.
2.4 Linux C++ TCP timeout detection code
Example 1: Setsockopt sets the timeout period
#include <iostream>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <string.h>
#include <stdexcept>
int main() {
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0) {
perror("socket creation failed");
return -1;
}
struct sockaddr_in server_addr;
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(12345);
inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr);
if (connect(sockfd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {
perror("connect failed");
close(sockfd);
return -1;
}
// 设置接收超时
struct timeval timeout;
timeout.tv_sec = 3; // 超时时间设置为3秒
timeout.tv_usec = 0;
if (setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, (char *)&timeout, sizeof(timeout)) < 0) {
perror("setsockopt failed");
close(sockfd);
return -1;
}
char buffer[1024];
ssize_t recv_len = recv(sockfd, buffer, sizeof(buffer) - 1, 0);
if (recv_len < 0) {
if (errno == EWOULDBLOCK || errno == EAGAIN) {
std::cout << "TCP receive timeout" << std::endl;
} else {
perror("recv failed");
}
close(sockfd);
return -1;
}
buffer[recv_len] = '\0';
std::cout << "Received message: " << buffer << std::endl;
close(sockfd);
return 0;
}
Example 2: Set the timeout period through select
#include <iostream>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <string.h>
#include <sys/select.h>
int main() {
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0) {
perror("socket creation failed");
return -1;
}
struct sockaddr_in server_addr;
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(12345);
inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr);
if (connect(sockfd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {
perror("connect failed");
close(sockfd);
return -1;
}
fd_set read_fds;
FD_ZERO(&read_fds);
FD_SET(sockfd, &read_fds);
// 设置超时时间为3秒
struct timeval timeout;
timeout.tv_sec = 3;
timeout.tv_usec = 0;
int max_fd = sockfd + 1;
int result = select(max_fd, &read_fds, nullptr, nullptr, &timeout);
if (result < 0) {
perror("select failed");
close(sockfd);
return -1;
} else if (result == 0) {
std::cout << "TCP receive timeout" << std::endl;
close(sockfd);
return -1;
} else {
if (FD_ISSET(sockfd, &read_fds)) {
char buffer[1024];
ssize_t recv_len = recv(sockfd, buffer, sizeof(buffer) - 1, 0);
if (recv_len < 0) {
perror("recv failed");
close(sockfd);
return -1;
}
buffer[recv_len] = '\0';
std::cout << "Received message: " << buffer << std::endl;
}
}
close(sockfd);
return 0;
}
3. TCP Congestion Control and Retransmission
3.1 Practical Application Scenarios of Retransmission and Timeout
TCP retransmission and timeout mechanisms play a key role in different types of network application scenarios. This section will introduce several practical application scenarios and illustrate the importance of retransmission and timeout in these scenarios.
(1) File Transfer
In file transfer applications, such as FTP and HTTP file downloads, the integrity and correctness of data is of paramount importance. The TCP retransmission and timeout mechanism can ensure the reliability of the data packet during the transmission process, and can ensure the complete and error-free transmission of the file even in the case of an unstable network environment.
(2) Real-time Communication
Real-time communication applications, such as VoIP and video conferencing, have high requirements for latency and data integrity. The TCP retransmission and timeout mechanism can ensure the reliability of data transmission to a certain extent. However, since real-time communication is very sensitive to delay, excessive retransmissions and timeouts may cause communication quality degradation. Therefore, in real-time communication scenarios, reliability and delay need to be weighed, and other protocols such as UDP may be used to transmit real-time data.
(3) Online Gaming
Online games usually have high requirements for latency and data integrity. Key data in the game, such as player operations and status updates, need to be transmitted reliably through TCP retransmission and timeout mechanisms. At the same time, in order to reduce latency, game developers need to optimize the retransmission strategy and timeout detection to improve game performance and user experience.
(4) Streaming Media
Streaming media transmission applications, such as online video and audio playback, usually need to reduce latency and buffering while ensuring data transmission reliability. The TCP retransmission and timeout mechanism can ensure the correct transmission of streaming media data, but too many retransmissions and timeouts may cause playback freezes. In these scenarios, adaptive streaming technology may be used, combined with TCP and other protocols such as UDP, to achieve efficient data transmission.
To sum up, TCP retransmission and timeout mechanisms play an important role in different types of network application scenarios. Understanding these application scenarios and their requirements for retransmission and timeout will help us better optimize network performance and improve user experience.
3.2 Challenges and Improvement Directions of Retransmission and Timeout
TCP retransmission and timeout mechanisms play a key role in ensuring the reliability of data transmission, but they still face some challenges in practical applications. This section discusses these challenges and directions for improvement.
(1) Accurate Identification of Packet Loss Causes
During TCP transmission, packet loss may be due to network congestion or other reasons such as link errors. The sender needs to accurately identify the cause of packet loss in order to adopt an appropriate retransmission strategy. However, the current TCP retransmission and timeout mechanism is difficult to accurately identify the cause of packet loss, which may lead to misjudgment and performance degradation. Future improvement directions include research on more accurate packet loss identification techniques to improve the intelligence of retransmission strategies.
(2) Distinguishing Different Application Scenario Requirements
Different types of network applications have different requirements for retransmission and timeout. For example, real-time communication and online gaming are latency-sensitive, while file transfer and streaming are more concerned with data integrity. Future TCP protocol improvements need to provide more flexible retransmission and timeout strategies for different application scenarios.
(3) Improve network congestion control effect (Enhancing Network Congestion Control)
TCP retransmission and timeout mechanisms are closely related to network congestion control. The current congestion control algorithm may misjudgment in some cases, affecting network performance. Future improvement directions include research on more accurate and efficient congestion control techniques to reduce the impact of retransmission and timeout on network performance.
(4) Exploring New Transport Protocols
Considering the limitations of the TCP protocol, researchers and engineers are developing new transport protocols to improve network performance. For example, based on the traditional TCP protocol, the QUIC protocol introduces a series of improvement measures, such as encrypted connection, more effective packet loss recovery mechanism, etc. Exploring new transport protocols can help solve the challenges faced by TCP retransmission and timeout mechanisms and improve network performance.
By addressing these challenges and taking corresponding improvement measures, we can further improve the performance of TCP retransmission and timeout mechanisms, and better meet the needs of different network application scenarios.
3.3 Evaluation and Monitoring Methods for Retransmission and Timeout
In order to optimize the TCP retransmission and timeout mechanism, we need to evaluate and monitor it. This section describes several methods for evaluating and monitoring retransmissions and timeouts.
(1) Packet Sniffing Tools
Network packet capture tools, such as Wireshark, can capture data packets passing through network interfaces and help us analyze retransmission and timeout phenomena in TCP connections. By analyzing the captured data packets, we can calculate the packet loss rate, retransmission times, retransmission timeout and other indicators, so as to evaluate the effect of TCP retransmission and timeout mechanism.
(2) Network Performance Testing Tools
Network performance testing tools, such as Iperf, can establish a TCP connection between two network nodes to measure performance indicators such as network delay and throughput. Through these tools, we can evaluate the impact of TCP retransmission and timeout mechanism on network performance, so as to optimize it.
(3) Application-layer Performance Monitoring
At the application layer, we can evaluate the effects of TCP retransmission and timeout mechanisms by monitoring application response time, throughput and other indicators. For example, we can use APM (Application Performance Management) tools to collect and analyze application performance data to find performance bottlenecks related to retransmission and timeout.
(4) Machine Learning and Big Data Analysis
With the help of machine learning and big data analysis technology, we can mine information about TCP retransmission and timeout from massive network data. By training machine learning models, we can predict retransmissions and timeouts that may occur in the network, so that measures can be taken in advance for optimization.
(5) Simulation and Modeling
By establishing a simulation model of the TCP protocol, we can evaluate the impact of different retransmission and timeout strategies on network performance in a controlled environment. For example, we can use network simulators such as NS-3 to simulate TCP connections and study retransmission and timeout behaviors under different network conditions.
By adopting these evaluation and monitoring methods, we can better understand the operation of the TCP retransmission and timeout mechanism, so as to make targeted optimization and improve network performance.
3.4 Linux C++ code example
#include <iostream>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <cstring>
#include <ctime>
#include <chrono>
#define SERVER_IP "127.0.0.1"
#define PORT 8080
#define BUFFER_SIZE 1024
#define TIMEOUT_DURATION 500 // ms
bool send_with_timeout(int sockfd, const char *buffer, size_t len, int flags, unsigned int max_retries) {
auto start = std::chrono::steady_clock::now();
auto end = std::chrono::steady_clock::now();
std::chrono::milliseconds timeout(TIMEOUT_DURATION);
// 当前重传次数
unsigned int retries = 0;
while (retries < max_retries) {
ssize_t sent = send(sockfd, buffer, len, flags);
// 数据发送成功，返回 true
if (sent == len) {
return true;
}
end = std::chrono::steady_clock::now();
// 超时，增加重传次数，重置计时
if (std::chrono::duration_cast<std::chrono::milliseconds>(end - start) > timeout) {
retries++;
start = std::chrono::steady_clock::now();
}
}
// 达到最大重传次数仍未成功发送，返回 false
return false;
}
int main() {
int client_fd;
struct sockaddr_in server_addr;
char buffer[BUFFER_SIZE];
// 创建socket
client_fd = socket(AF_INET, SOCK_STREAM, 0);
// 设置服务器地址
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = inet_addr(SERVER_IP);
server_addr.sin_port = htons(PORT);
// 连接到服务器
connect(client_fd, (struct sockaddr *)&server_addr, sizeof(server_addr));
// 与服务器进行数据通信
size_t window_size = 1;
size_t num_packets_sent = 0;
size_t num_acks_received = 0;
while (true) {
// 发送数据
for (size_t i = 0; i < window_size && num_packets_sent < 10; ++i) {
std::string packet = "Packet " + std::to_string(num_packets_sent);
std::cout << "Sending: " << packet << std::endl;
send_with_timeout(client_fd, packet.c_str(), packet.size(), 0, 3);
++num_packets_sent;
}
// 接收ACK
memset(buffer, 0, BUFFER_SIZE);
int read_size = recv(client_fd, buffer, BUFFER_SIZE, 0);
if (read_size <= 0) {
break;
}
std::cout << "Received ACK: " << buffer << std::endl;
++num_acks_received;
// 调整窗口大小
if (num_acks_received == num_packets_sent) {
window_size *= 2;
} else {
window_size = 1;
}
}
// 关闭连接
close(client_fd);
return 0;
}
4. TCP Flow Control and Retransmission
4.1 Selective Acknowledgment（SACK）机制（Selective Acknowledgment Mechanism）
In order to further optimize the TCP retransmission and timeout mechanism, researchers and engineers introduced the Selective Acknowledgment (SACK) mechanism. This section will introduce the basic principle of the SACK mechanism and its advantages.
(1) Basic Principles of SACK Mechanism (Basic Principles of SACK Mechanism)
The traditional TCP confirmation mechanism adopts cumulative confirmation, and the receiver only confirms the last data packet received in sequence. When the network environment is poor, this mechanism may lead to multiple unnecessary retransmissions. The SACK mechanism allows the receiver to more precisely acknowledge received packets, even if they were received out of order.
In the SACK mechanism, the receiver can use the SACK option (SACK Option) to carry the received discontinuous data segment information in the TCP message, and notify the sender of the correctly received data packet. The sender only retransmits unacknowledged data packets according to the received SACK information, thereby reducing unnecessary retransmissions.
(2) Advantages of SACK Mechanism (Advantages of SACK Mechanism)
- Reducing Unnecessary Retransmissions (Reducing Unnecessary Retransmissions): The SACK mechanism can help the sender accurately understand the data packets that the receiver has received, thereby reducing unnecessary retransmissions and improving network performance.
- Enhancing Congestion Control: The SACK mechanism can reduce network congestion caused by retransmission, thereby improving congestion control.
- Adapting to Out-of-order Packet Transmission Environments (Adapting to Out-of-order Packet Transmission Environments): The SACK mechanism has better performance in a transmission environment with many out-of-order packets. ) network, SACK can effectively improve the reliability and efficiency of data transmission.
By introducing the SACK mechanism, the TCP protocol can more effectively deal with data packet loss and out-of-order problems, further improving the reliability and performance of data transmission.
4.2 Fast Retransmit and Fast Recovery
Fast retransmission and fast recovery are two optimization mechanisms in the TCP protocol, which are used to reduce unnecessary retransmission timeout waiting, thereby improving network performance. This section will introduce the basic principles and advantages of fast retransmission and fast recovery.
(1) Fast Retransmit
The purpose of the fast retransmission mechanism is to detect packet loss before waiting for retransmission timeout, and retransmit as soon as possible. In a TCP connection, when the receiver receives three repeated ACKs in a row, the sender thinks that the earliest unacknowledged data packet has been lost, and immediately retransmits it without waiting for the retransmission timer to expire. In this way, the waiting time when the data packet is lost can be reduced, and the efficiency of data transmission can be improved.
(2) Fast Recovery (Fast Recovery)
The fast recovery mechanism is started after fast retransmission to recover the congestion window more quickly during a round of retransmission. When the sender enters the fast recovery phase, it halves the congestion window instead of resetting the congestion window to 1 as in traditional congestion control. This avoids network throughput degradation caused by too small a window size. At the same time, the sender will also adjust the congestion window according to the received new ACK information, so as to continue sending data during recovery.
(3) Advantages of Fast Retransmit and Fast Recovery
- Reducing Retransmission Delay: The fast retransmission mechanism can detect packet loss before the retransmission timer expires, thereby reducing retransmission delay.
- Avoiding Global Synchronization: The fast recovery mechanism can avoid global synchronization caused by resetting the window size and maintain the stability of network throughput.
- Enhancing Congestion Control: The fast retransmission and fast recovery mechanism can reduce the negative impact of congestion control on network performance to a certain extent, thereby improving network performance.
To sum up, fast retransmission and fast recovery, as the optimization mechanism of TCP protocol, can significantly improve network performance, reduce the waiting time when data packets are lost, and improve the reliability and efficiency of data transmission.
4.3 Congestion window verified fast retransmission (TCP NewReno)
Congestion Window Authenticated Fast Retransmission, or TCP NewReno, is an improved version of TCP Reno to address performance issues when multiple packets are lost simultaneously. This section will introduce the basic principles of TCP NewReno and its advantages.
(1) Basic Principles of TCP NewReno (Basic Principles of TCP NewReno)
TCP Reno is somewhat limited when dealing with multiple packet losses, as it can only recover one lost packet within one round of the timeout period. TCP NewReno improves on this so that multiple lost packets can be recovered within one timeout period.
In TCP NewReno, when the sender receives three duplicate ACKs, it enters the fast recovery phase and sets a "partial ACK" flag at the same time. When the sender receives a partial ACK, it retransmits the unacknowledged packets instead of waiting for the retransmission timer to expire. In this way, within one timeout period, TCP NewReno can recover multiple lost packets.
(2) Advantages of TCP NewReno (Advantages of TCP NewReno)
- More Efficient Packet Loss Recovery (More Efficient Packet Loss Recovery): TCP NewReno can recover multiple lost packets within a timeout period, improving the efficiency of packet loss recovery.
- Reducing Retransmission Delay: By retransmitting unacknowledged packets immediately upon receipt of a partial ACK, TCP NewReno can reduce retransmission delay.
- Improved Congestion Control (Improved Congestion Control): TCP NewReno can better handle multiple packet losses, thereby improving the effect of congestion control.
In conclusion, TCP NewReno, as an improved version of TCP Reno, can handle multiple data packet losses more effectively, improve network performance and reliability of data transmission. By adopting TCP NewReno, we can further optimize the TCP retransmission and timeout mechanism to meet the needs of different network application scenarios.
4.4 Implementation steps of flow control and retransmission
- Import necessary libraries: When using C++ to implement TCP flow control and retransmission, you need to import the following libraries:
#include <iostream> #include <cstdlib> #include <cstring> #include <unistd.h> #include <arpa/inet.h> #include <sys/socket.h> #include <netinet/in.h> #include <netinet/tcp.h> #include <fcntl.h> #include <errno.h> - Create Socket: Create a TCP socket and bind it to the specified address and port. Then use
listen()a function to listen for connection requests.int sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); - Set socket options: In order to achieve flow control and retransmission, some socket options need to be set, such as TCP_NODELAY (disable Nagle algorithm) and TCP_QUICKACK (enable quick acknowledgment).
int flag = 1; setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(int)); setsockopt(sockfd, IPPROTO_TCP, TCP_QUICKACK, (char *)&flag, sizeof(int)); - Connect and receive data: Use
accept()the function to receive a client connection and create a new socket. Then userecv()the function to receive the data.int client_sock = accept(sockfd, (struct sockaddr *)&client_addr, &addr_len); char buffer[1024]; ssize_t bytes_received = recv(client_sock, buffer, sizeof(buffer), 0); - Implement flow control: Use a sliding window algorithm to implement flow control. The (send buffer size) and (receive buffer size) options can be
setsockopt()set using the function to adjust the size of the sliding window.SO_SNDBUFSO_RCVBUFint send_buffer_size = 4096; int recv_buffer_size = 4096; setsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &send_buffer_size, sizeof(send_buffer_size)); setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &recv_buffer_size, sizeof(recv_buffer_size)); - Implement a retransmission mechanism: You can use
select()a function orpoll()function to monitor the readability and writability of a socket to implement a timeout and retransmission mechanism. At the same time, you can use thesetsockopt()function to setTCP_USER_TIMEOUToptions to specify the retransmission timeout.struct timeval timeout; timeout.tv_sec = 5; timeout.tv_usec = 0; fd_set read_fds; FD_ZERO(&read_fds); FD_SET(client_sock, &read_fds); int user_timeout = 5000; setsockopt(client_sock, IPPROTO_TCP, TCP_USER_TIMEOUT, &user_timeout, sizeof(user_timeout)); int ret = select(client_sock + 1, &read_fds, nullptr, nullptr, &timeout); if (ret < 0) { perror("select"); } else if (ret == 0) { std::cout << "Timeout, retransmitting data..." << std::endl; } else { if (FD_ISSET(client_sock, &read_fds)) { ssize_t bytes_received = recv(client_sock, buffer, sizeof(buffer), 0); // 处理接收到的数据 } } - Send data: Use
send()the function to send data. Before sending data, the socket can be checked for writability to prevent blocking.ssize_t bytes_sent = send(client_sock, buffer, strlen(buffer), 0); - Close Socket: Use the function to close the socket after the data transfer is complete
close().close(client_sock); close(sockfd);
The above code only provides a simple overview for implementing TCP flow control and retransmission. In practical applications, you need to adjust and optimize the code according to specific requirements.
4.5 Complete code for flow control and retransmission
In the code, we use a unacked_packetsvector called to store unacknowledged packets. Each data packet has a sequence number which is used to identify a particular data packet between sender and receiver. After successfully receiving a data packet, the receiver will send an acknowledgment message (ACK) to the sender, which contains the sequence number of the data packet to confirm receipt.
After the sender receives the ACK, it checks unacked_packetsthe vector and updates it based on the sequence number of the received ACK. All packets in the vector that have a sequence number less than or equal to the ACK sequence number are considered acknowledged because it means that the receiver has already received them.
#include <iostream>
#include <cstring>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <sys/select.h>
#include <string>
#include <algorithm>
#include <vector>
#include <thread>
#define USE_SEPARATE_SEQUENCE_NUMBERS 1
struct Packet {
#if USE_SEPARATE_SEQUENCE_NUMBERS
uint32_t seq_number;
#endif
char data[1024];
int retry_count;
};
void retransmit_data(int client_sock, std::vector<Packet>& unacked_packets) {
const int max_retries = 5; // Maximum number of retransmission attempts
const int initial_backoff = 1000; // Initial backoff time in milliseconds (1 second)
std::vector<Packet> new_unacked_packets;
for (auto& packet : unacked_packets) {
// Check if the retry counter has reached the maximum number of attempts
if (packet.retry_count >= max_retries) {
#if USE_SEPARATE_SEQUENCE_NUMBERS
std::cerr << "Maximum number of retransmission attempts reached for sequence number: "
<< packet.seq_number << std::endl;
#else
std::cerr << "Maximum number of retransmission attempts reached for the packet" << std::endl;
#endif
continue;
}
// Send the packet
ssize_t bytes_sent = send(client_sock, &packet, sizeof(packet), 0);
// Error in send()
if (bytes_sent < 0) {
std::cerr << "Error in send: " << strerror(errno) << std::endl;
} else {
#if USE_SEPARATE_SEQUENCE_NUMBERS
std::cout << "Data retransmitted. Sequence number: " << packet.seq_number << std::endl;
#else
std::cout << "Data retransmitted." << std::endl;
#endif
// Increment the retry counter
++packet.retry_count;
// Apply exponential backoff
int backoff_time = initial_backoff * (1 << (packet.retry_count - 1));
std::this_thread::sleep_for(std::chrono::milliseconds(backoff_time));
new_unacked_packets.push_back(packet);
}
}
unacked_packets.swap(new_unacked_packets);
}
int main(int argc, char *argv[]) {
std::vector<Packet> unacked_packets;
// 1. 创建套接字
int sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (sockfd < 0) {
std::cerr << "Error in socket: " << strerror(errno) << std::endl;
return -1;
}
// 2. 绑定地址和端口
struct sockaddr_in server_addr;
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
server_addr.sin_port = htons(8888);
if (bind(sockfd, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) {
std::cerr << "Error in bind: " << strerror(errno) << std::endl;
close(sockfd);
return -1;
}
// 3. 监听连接
if (listen(sockfd, 5) < 0) {
std::cerr << "Error in listen: " << strerror(errno) << std::endl;
close(sockfd);
return -1;
}
// 4. 接受连接
struct sockaddr_in client_addr;
socklen_t addr_len = sizeof(client_addr);
int client_sock = accept(sockfd, (struct sockaddr *)&client_addr, &addr_len);
if (client_sock < 0) {
std::cerr << "Error in accept: " << strerror(errno) << std::endl;
close(sockfd);
return -1;
}
// 5. 设置流量控制
int send_buffer_size = 4096;
int recv_buffer_size = 4096;
setsockopt(client_sock, SOL_SOCKET, SO_SNDBUF, &send_buffer_size, sizeof(send_buffer_size));
setsockopt(client_sock, SOL_SOCKET, SO_RCVBUF, &recv_buffer_size, sizeof(recv_buffer_size));
// 6. 初始化select
fd_set read_fds;
FD_ZERO(&read_fds);
FD_SET(client_sock, &read_fds);
struct timeval timeout;
timeout.tv_sec = 5;
timeout.tv_usec = 0;
// 7. 使用select等待数据
// Initialize a temporary file descriptor set for select()
fd_set temp_fds;
// Main loop
while (true) {
// Update the timeout structure
timeout.tv_sec = 5;
timeout.tv_usec = 0;
// Copy the original file descriptor set (read_fds) to a temporary set (temp_fds)
temp_fds = read_fds;
// Use select() to wait for events on the client socket (data available to read or timeout)
// The last argument (timeout) specifies the maximum time select() should wait for an event
int ret = select(client_sock + 1, &temp_fds, nullptr, nullptr, &timeout);
// Error in select()
if (ret < 0) {
std::cerr << "Error in select: " << strerror(errno) << std::endl;
break;
}
// Timeout occurred, indicating that no ACK was received during the specified time interval
// This is used to detect lost packets and trigger retransmission
else if (ret == 0) {
std::cout << "Timeout, retransmitting data..." << std::endl;
retransmit_data(client_sock, unacked_packets);
continue;
}
// If data is available to read on the client socket, process the ACK
if (FD_ISSET(client_sock, &temp_fds)) {
//从客户端接收到的ACK序列号
uint32_t ack_seq_number;
ssize_t bytes_received;
#if USE_SEPARATE_SEQUENCE_NUMBERS
// Receive the ACK sequence number from the client
bytes_received = recv(client_sock, &ack_seq_number, sizeof(ack_seq_number), 0);
if(bytes_received<=0) goto ret_process;
#endif
Packet data_packet;
// Receive the ACK sequence number and data from the client
bytes_received = recv(client_sock, &data_packet, sizeof(data_packet), 0);
ack_seq_number = data_packet.seq_number;
ret_process：
if (bytes_received < 0) {
std::cerr << "Error in recv: " << std::strerror(errno) << std::endl;
if (errno == EAGAIN || errno == EWOULDBLOCK) {
// No data available for reading temporarily
std::this_thread::sleep_for(std::chrono::milliseconds(100)); // Wait for 100ms before continuing the loop
continue;
} else if (errno == ECONNRESET) {
// Connection reset by the other party
std::cout << "Connection reset by peer." << std::endl;
close(client_sock); // Close the socket
client_sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); // Create a new socket and reconnect
if (connect(client_sock, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) {
std::cerr << "Error in connect: " << strerror(errno) << std::endl;
close(client_sock);
return -1;
}
continue;
} else {
// Other error codes
std::cerr << "recv error: " << std::strerror(errno) << std::endl;
break;
}
}
// Client disconnected
else if (bytes_received == 0) {
std::cout << "Client disconnected." << std::endl;
break;
}
// Valid ACK received
else {
// Convert the received sequence number to host byte order
ack_seq_number = ntohl(ack_seq_number);
// Remove the acknowledged packets from the unacked_packets vector
#ifdef USE_SEPARATE_SEQUENCE_NUMBERS
// Handle separate sequence numbers for each packet
unacked_packets.erase(std::remove_if(unacked_packets.begin(), unacked_packets.end(),
[&ack_seq_number](const Packet& packet) {
return packet.seq_number == ack_seq_number;
}), unacked_packets.end());
#else
// Handle cumulative sequence numbers
unacked_packets.erase(std::remove_if(unacked_packets.begin(), unacked_packets.end(),
[&ack_seq_number](const Packet& packet) {
return packet.seq_number <= ack_seq_number;
}), unacked_packets.end());
#endif
std::cout << "Received ACK for sequence number: " << ack_seq_number << std::endl;
std::cout << "Received data: " << data_packet.data << std::endl;
}
}
}
// 8. 关闭套接字
close(client_sock);
close(sockfd);
return 0;
}
client:
#include <iostream>
#include <cstring>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string>
#include <thread>
#define USE_SEPARATE_SEQUENCE_NUMBERS 1
int main(int argc, char *argv[]) {
// 1. 创建套接字
int sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (sockfd < 0) {
std::cerr << "Error in socket: " << strerror(errno) << std::endl;
return -1;
}
// 2. 连接到服务器
struct sockaddr_in server_addr;
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = inet_addr("127.0.0.1");
server_addr.sin_port = htons(8888);
if (connect(sockfd, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) {
std::cerr << "Error in connect: " << strerror(errno) << std::endl;
close(sockfd);
return -1;
}
// 3. 发送数据和ACK序列号给服务器
uint32_t seq_number = 1;
while (true) {
std::string input;
std::cout << "Enter data to send: ";
std::getline(std::cin, input);
if (input == "exit") {
break;
}
// Convert the sequence number to network byte order
uint32_t network_seq_number = htonl(seq_number);
#if USE_SEPARATE_SEQUENCE_NUMBERS
// Send the ACK sequence number to the server
ssize_t bytes_sent = send(sockfd, &network_seq_number, sizeof(network_seq_number), 0);
if (bytes_sent < 0) {
std::cerr << "Error in send: " << strerror(errno) << std::endl;
break;
}
// Send the data to the server
bytes_sent = send(sockfd, input.c_str(), input.size() + 1, 0);
#else
struct Packet {
uint32_t seq_number;
char data[1024];
};
Packet data_packet;
data_packet.seq_number = network_seq_number;
strncpy(data_packet.data, input.c_str(), sizeof(data_packet.data));
// Send the data packet to the server
ssize_t bytes_sent = send(sockfd, &data_packet, sizeof(data_packet), 0);
#endif
if (bytes_sent < 0) {
std::cerr << "Error in send: " << strerror(errno) << std::endl;
break;
}
std::cout << "Data sent. Sequence number: " << seq_number << std::endl;
// Increment the sequence number
++seq_number;
}
// 4. 关闭套接字
close(sockfd);
return 0;
}
5. TCP Retransmission and Timeout Optimization Practices
5.1 Introducing TCP's relatively new congestion control algorithms (Adopting Newer TCP Congestion Control Algorithms)
In order to further optimize the TCP retransmission and timeout mechanism, you can try to use some relatively new congestion control algorithms. These algorithms have better performance in different network environments, can effectively reduce retransmission delay and improve network throughput. This section will introduce several newer TCP congestion control algorithms.
(1) CUBIC: The CUBIC algorithm is a congestion control algorithm for high-bandwidth networks and long-distance transmission. By introducing a cubic congestion window growth function, it can better balance network throughput and delay. The CUBIC algorithm performs particularly well in high-speed networks and can significantly improve data transmission performance.
(2) BBR (Bottleneck Bandwidth and RTT): The BBR algorithm adjusts the congestion window by estimating the bottleneck bandwidth and round-trip delay of the network, avoiding the excessive sensitivity to packet loss in traditional congestion control algorithms. The BBR algorithm has better performance in the environment of congested network and high packet loss rate.
(3) Compound TCP: Compound TCP is a congestion control algorithm that combines congestion window and receive window adjustments to improve performance in high-bandwidth networks. By considering both the congestion window and the receive window, Compound TCP can better balance network throughput and latency.
(4) Vegas: The Vegas algorithm predicts congestion by measuring the round-trip delay, thereby adjusting the congestion window in advance. The Vegas algorithm performs better in networks with low latency and low packet loss rate, and can effectively reduce congestion and retransmission delays.
By introducing these newer TCP congestion control algorithms, we can choose the appropriate algorithm according to different network environments and application requirements, thereby optimizing the TCP retransmission and timeout mechanism and improving network performance.
5.2 Using Forward Error Correction (Forward Error Correction, FEC)
Forward Error Correction (FEC) is a method of improving the reliability of data transmission by adding redundant data. By using FEC, we can reduce the number of TCP retransmissions to a certain extent, thereby reducing retransmission delays and improving network performance. This section will introduce the basic principle of FEC and its application in TCP retransmission and timeout mechanism.
(1) Basic Principles of FEC (Basic Principles of FEC)
FEC adds redundant information to the original data, so that the receiver can still reconstruct the original data when it receives some damaged or lost data packets. There are many methods of FEC coding, such as Hamming Code, Reed-Solomon Code and so on. These encoding methods can provide a certain degree of error correction for data transmission without adding too much additional overhead.
(2) Application of FEC in TCP Retransmission and Timeout Mechanisms (Applications of FEC in TCP Retransmission and Timeout Mechanisms)
In TCP transmission, we can reduce the number of retransmissions and improve network performance by combining FEC technology with the traditional TCP retransmission mechanism. For example, the sender can add FEC-encoded redundant data when sending data packets, and the receiver can use these redundant data for error correction when receiving partially damaged or lost data packets, thereby avoiding errors in some cases. Retransmission.
It should be noted that although FEC technology can reduce TCP retransmission to a certain extent, it will increase certain calculation and bandwidth overhead. Therefore, in practical applications, it is necessary to weigh the relationship between the performance improvement brought by FEC and its overhead to find the best solution for a specific scenario.
In short, as a method to improve the reliability of data transmission, FEC technology can be combined with TCP retransmission and timeout mechanism to further optimize network performance. By using FEC, we can reduce the number of retransmissions and reduce the retransmission delay while ensuring the reliability of data transmission.
5.3 Using Multipath Transmission
Multipath transmission is a method of transmitting data simultaneously by utilizing multiple paths in the network, thereby improving network performance and reliability. In the TCP retransmission and timeout mechanism, the probability of data packet loss can be reduced by using multipath transmission, and the number of retransmissions and delay can be reduced. This section will introduce the basic principle of multipath transmission and its application in TCP retransmission and timeout mechanism.
(1) Basic Principles of Multipath Transmission
In multipath transmission, the sender distributes data packets over multiple network paths for transmission, and the receiver receives and reassembles these packets from different paths. In this way, even if a problem occurs on a certain path and data packets are lost, data packets on other paths can be used to ensure reliable data transmission.
(2) Application of Multipath Transmission in TCP Retransmission and Timeout Mechanisms (Applications of Multipath Transmission in TCP Retransmission and Timeout Mechanisms)
In TCP transmission, multipath transmission can be supported by implementing multipath TCP (MPTCP). MPTCP is extended on the basis of traditional TCP, allowing simultaneous establishment of TCP connections on multiple network paths, thereby improving the reliability and performance of data transmission.
By using multi-path transmission, the probability of packet loss on a single path can be reduced, thereby reducing the number of TCP retransmissions and delays. At the same time, multi-path transmission can also achieve load balancing among different paths and improve the throughput of the network.
It should be noted that the multipath transmission needs to extend the existing TCP protocol, which may bring certain complexity. In addition, multipath transmission also has higher requirements on path selection and load balancing strategies in the network. Therefore, in practical applications, it is necessary to choose whether to use the multipath transmission technology according to specific scenarios and requirements.
In short, as a method to improve the reliability and performance of data transmission, multipath transmission can be combined with TCP retransmission and timeout mechanism to further optimize network performance. By adopting multi-path transmission, we can reduce the number of retransmissions and delay while ensuring the reliability of data transmission.
5.3 Using Multipath Transmission
Multipath transmission is a method of transmitting data simultaneously by utilizing multiple paths in the network, thereby improving network performance and reliability. In the TCP retransmission and timeout mechanism, the probability of data packet loss can be reduced by using multipath transmission, and the number of retransmissions and delay can be reduced. This section will introduce the basic principle of multipath transmission and its application in TCP retransmission and timeout mechanism.
(1) Basic Principles of Multipath Transmission
In multipath transmission, the sender distributes data packets over multiple network paths for transmission, and the receiver receives and reassembles these packets from different paths. In this way, even if a problem occurs on a certain path and data packets are lost, data packets on other paths can be used to ensure reliable data transmission.
(2) Application of Multipath Transmission in TCP Retransmission and Timeout Mechanisms (Applications of Multipath Transmission in TCP Retransmission and Timeout Mechanisms)
In TCP transmission, multipath transmission can be supported by implementing multipath TCP (MPTCP). MPTCP is extended on the basis of traditional TCP, allowing simultaneous establishment of TCP connections on multiple network paths, thereby improving the reliability and performance of data transmission.
By using multi-path transmission, the probability of packet loss on a single path can be reduced, thereby reducing the number of TCP retransmissions and delays. At the same time, multi-path transmission can also achieve load balancing among different paths and improve the throughput of the network.
It should be noted that the multipath transmission needs to extend the existing TCP protocol, which may bring certain complexity. In addition, multipath transmission also has higher requirements on path selection and load balancing strategies in the network. Therefore, in practical applications, it is necessary to choose whether to use the multipath transmission technology according to specific scenarios and requirements.
In short, as a method to improve the reliability and performance of data transmission, multipath transmission can be combined with TCP retransmission and timeout mechanism to further optimize network performance. By adopting multi-path transmission, we can reduce the number of retransmissions and delay while ensuring the reliability of data transmission.
6. Conclusion
This blog conducts in-depth discussions on TCP retransmission, timeout, congestion control, flow control, etc., to help readers better understand how the TCP protocol ensures data reliability and efficiency during network transmission. We analyzed various retransmission principles, trigger conditions and optimization strategies in detail, as well as timeout detection, dynamic adjustment and the relationship with retransmission. At the same time, we also discuss the importance of congestion control and flow control in adjusting the network transmission rate and synergizing to ensure network stability.
In practice, we provide optimization strategies for different network environments, and analyze and solve common performance problems. In addition, we also look forward to the development trend of TCP retransmission and timeout in the future, and provide guidance for further improving network performance.
We believe this blog will be of high value to those readers who wish to gain an in-depth understanding of the TCP protocol to solve challenges in network transport. Please bookmark, follow and like, so that more people can benefit from this knowledge. We look forward to more success in your future study and practice!