Before the introduction of TCP packet format (” TCP protocol basic features “), TCP connection management, learn how to establish TCP connection, release the connection and some network installation problems, now there are still several key mechanisms of TCP, mainly TPC delayed reply and pigled-in reply, super……

Before the introduction of TCP packet format (” TCP Protocol basic Features “), TCP connection management, learning how to establish a TCP connection, release a connection and some network installation issues, now there are several key mechanisms of TCP. It mainly includes delayed reply and piggy-back reply of TPC, timeout retransmission, fast retransmission and fast recovery, sliding window mechanism and congestion avoidance algorithm. Then finally recorded TCP sticky packet problems and solutions!

The reliable transmission of TCP relies on the acknowledgement acknowledgement mechanism, that is, the receiver will send back an ACK confirmation number after receiving the data, representing the serial number he expects to receive next time, which means to tell the sender that I have received what data; Where do you start next time? The Sequence Number in TCP packets is not numbered by packet segments. Instead, all data transmitted during the lifetime of the connection is treated as a byte stream. The Sequence Number is the Number of each byte in the entire byte stream. A TCP packet contains multiple byte streams of data (known as data segments), and the data in each TCP packet may not be the same size. During the three-way handshake to establish a TCP connection, the communication parties have determined the initial serial numbers X and Y respectively. The serial number field in each TCP packet segment indicates the serial number of the first byte to be transmitted.

TCP acknowledgement reply

The confirmation mechanism provided by TCP allows each TCP packet to be Delayed instead of being Delayed (Delayed ACK mechanism), which greatly improves the utilization rate and transmission efficiency of the network. At the same time, the TCP acknowledgement mechanism can also confirm multiple datagrams at one time. For example, if the receiver receives the datagrams of 201,301,401, it only needs to confirm the data packets of 401. The confirmation of the data packets of 401 also means that all the data packets before 401 have been confirmed, which is called delayed reply. This can also improve the efficiency of the system.

As for piggyback replies, TCP acknowledgement and receipt data can be sent in a single packet.

TCP timeout retransmission

If the sender does not receive an acknowledgement from the receiver within a specified period of time, the unacknowledged packet must be resend. If the receiver receives an error packet, it discards the packet and does not send the confirmation message to the sender. Therefore, the retransmission mechanism of TCP packets is determined by a timeout timer. If no confirmation message is received within the specified time, TCP packets are retransmitted. The setting of the time value is very important. If the time value is too large, the delay of packet retransmission will be large; if the time value is too small, the network may be retransmitted again before receiving the confirmation from the sender of the packet, which will cause the endless retransmission process of the network. If the recipient receives a duplicate packet, it discards the duplicate packet and sends an acknowledgement message. Otherwise, the recipient sends the duplicate packet again.

However, host A does not receive any acknowledgement from host B, which may be because the ACK is lost. Therefore, host B receives a lot of duplicate data. TCP needs to be able to identify duplicate packets and discard duplicate packets. At this time we can use the serial number mentioned before, it is easy to achieve the effect of weight.

How is the timeout period determined?

TCP dynamically calculates the maximum timeout to ensure high performance communication in any environment: In Linux (BSD Unix and Windows are also the same), the timeout is controlled by a unit of 500ms, and the timeout time for determining the timeout retransmission is an integer multiple of 500ms. If there is still no reply after the retransmission, Wait 2 x 500ms for retransmission. If no reply is received, wait 4 x 500ms for retransmission. When a certain number of retransmission times is reached, TCP considers that the network or the peer host is abnormal and forcibly closes the connection

TCP Fast Retransmission (Redundant ACK)

Why fast retransmission when you have timeout retransmission? In fact, to ensure efficiency, TCP sends a redundant ACK to indicate the sequence number of the next expected byte whenever an out-of-order packet segment larger than the expected number arrives.

Timeout retransmission is baseline and functional, but fast retransmission is built on timeout retransmission for efficiency

TCP flow control

The speed at which a receiver can process data is limited. If the sending end sends the packet too fast, the buffer of the receiving end will be filled up. If the sending end continues to send packets, packet loss will occur, which will lead to a series of chain reactions such as packet loss and retransmission. Therefore, TCP determines the sending speed of the receiving end according to the processing capability of the receiving end. This mechanism is called Flow Control;

In the communication process, the receiver dynamically adjusts the size of the sending window of the sender according to the size of its own receiving cache, that is, the receiving window RWND (the receiver sets the window field of the confirmation message segment to notify the sender of RWND). The sending window of the sender takes the minimum values of the receiving window RWND and the congestion window CWND. The receiving window is also the receiving buffer of the receiver. Congestion window simply means that the network is blocked. That is, there are many hosts using network bandwidth in the network, or they occupy a lot of resources, resulting in slow transmission

In the TCP header, there is a special window size field to inform the window size. The receiving host notifies the sender of the size of the buffer it can receive in this field. The larger the value of this field is, the higher the network throughput is. However, when the buffer on the receiving end is faced with data overflow, the value of the window size is also set to a smaller value to notify the sender, thus controlling the amount of data to be sent. That is, the sending host controls the amount of data to be sent according to the instructions of the receiving host. This forms a complete TCP flow control (flow control).

As can be seen from the figure, if the window update notification has not been received after the retransmission time, a probe message will be sent to detect the window of the receiver.

A sliding window can only slide to the right, but it can get bigger, it can get smaller, it can get zero; After receiving the first ACK, the sliding window moves back and continues to send the fifth section of data, and so on. In order to maintain the sliding window, the operating system kernel needs to open up the sending buffer to record what data is still unanswered; Only data that has been acknowledged can be deleted from the buffer. The larger the window, the higher the throughput of the network;

TCP congestion control

Because there are so many computers on the network, the current network state may already be congested. Sending large amounts of data without knowing the current state of the network is likely to make things worse. Generally speaking, computer networks live in a shared environment. Therefore, there is also the possibility of network congestion due to communication between other hosts. If you suddenly send a large amount of data in a congested network, it’s very likely that the entire network will crash and let’s see how TCP solves this problem.

TCP introduced a slow start mechanism: first send a small amount of data, explore the road, find out the current network congestion, and then decide how fast to transfer data.

The algorithm for slow start and congestion avoidance is shown in the figure below:

CWND refers to a packet segment (maximum packet segment length MSS). It starts with a packet segment and grows exponentially to the ssTHRESH initial value, which is slow start, and then performs addition and increase, which is congestion avoidance phase. When the threshold is reached, fast retransmission is triggered, which drops to the new SSTHRESH value. That’s half of the congestion. That’s the quick recovery strategy! When TCP traffic starts, network throughput increases gradually, but decreases rapidly as congestion occurs. Then it will enter the process of slowly increasing throughput again. So the throughput characteristics of TCP seem to be gradually occupying network bandwidth.

TCP sticky packet problem

First of all, it should be clear that the “packet” in sticky packet problem refers to the application layer packet.

In the TCP header, there is no packet length field like UDP, but a sequence number field. At the transport layer, TCP packets arrive one by one and are sequentially placed in the buffer. From the perspective of the application layer, the application can only see a string of consecutive bytes of data, so the application does not know from which part to which part is a complete application layer packet

So how to avoid sticky bag problem? What it boils down to is a clear boundary between two packages:

  • For fixed-length packages, ensure that they are read at a fixed size each time. For example, if a struct is of a fixed size, then sizeof(struct) is read from the beginning of the buffer;
  • For a variable length packet, you can specify a field of the total length of the packet at the position of the packet header, so as to know the end position of the packet.
  • For variable length packages, you can also use explicit delimiters between packages (application-layer protocol, determined by the program itself, as long as the delimiters do not conflict with the body).

Is there “sticky packet problem” for UDP? For UDP, if no upper-layer data has been delivered, the UDP packet length remains the same. At the same time, UDP delivers data to the application layer one by one, so there are clear data boundaries. At the application layer, UDP packets are received as a whole or not received at all.