The difference between TCP and UDP and detailed explanation of flow control, congestion control, fast retransmission, and fast recovery algorithms

[[413351]]

Differences between UDP and TCP

In the previous article, the three-way handshake of TCP to establish a connection and the four-way handshake to release the connection were explained in detail. This tutorial explains other contents of TCP. First, the UDP protocol, which is also a transport layer protocol, what are the differences and connections between the two?

The similarities are that UDP and TCP are two important protocols in the transport layer of the TCP/IP architecture. The following figure is a diagram of the TCP/IP architecture:

An additional point to be added is that the IP protocol under the TCP and UDP protocols can provide services for various network applications and use the IP layer protocol to interconnect different network interfaces. The following is a structural diagram:

image-20210718234432031

The frequency of use of TCP and UDP is second only to the IP protocol at the Internet layer.

UDP is also called User Datagram Protocol, while TCP is called Transmission Control Protocol. The most significant difference is that UDP is connectionless, while TCP is connection-oriented. The following is a schematic diagram of the two communication methods:

As shown in the figure above, UDP can transmit data without establishing a connection. However, TCP needs to perform a "three-message handshake" to establish a connection before transmitting data. After data transmission is completed, a "four-message handshake" is required to release the connection.

It is precisely because of the connectionless nature of UDP that UDP supports unicast, multicast, and broadcast. For TCP, because of the connection established by the three-way handshake, it has a reliable channel and only supports unicast. The following is a schematic diagram of the two communication methods:

Next, let's analyze the detailed process of UDP and TCP data transmission.

It can be seen that UDP is application-message oriented. The sender's application process delivers the application message to the UDP of the transport layer. UDP directly adds a UDP header to the application layer message to make it a UDP user datagram, and then sends it. After the receiver's UDP receives the UDP user datagram, it removes the UDP header and delivers the application layer message to the application process. In other words, UDP neither merges nor splits the messages handed over by the application process, but retains the boundaries of these messages. In other words, UDP is application-message oriented.

Next, the right side of the above figure is the data transmission process of TCP. The sender's TCP regards the data blocks delivered by the application process as a series of unstructured byte streams. TCP does not know the meaning of these byte streams to be transmitted. It only numbers them and stores them in its own sending buffer. TCP extracts a certain number of bytes from the sending buffer according to the sending strategy, builds a TCP segment and sends it. The receiver's TCP, on the one hand, takes out the data payload part from the received TCP message and stores it in the receiving buffer, and on the other hand, delivers some bytes in the receiving buffer to the application process. TCP does not guarantee that the received data block has a corresponding size relationship with the data block sent by the sender's application process, but the byte stream received by the receiver's application process must be exactly the same as the byte stream sent by the sender's application process. At the same time, the receiver's application process must be able to identify the received byte stream and restore it to meaningful application layer data. In other words, TCP is byte stream-oriented, which is also the basis for TCP to achieve reliable transmission, flow control and congestion control.

Next, let's look at another comparison, the schematic diagram is as follows:

That is to say, for the TCP/IP architecture, the internet layer provides a connectionless and unreliable transmission service to the upper layer, and for UDP, its transport layer provides a connectionless and unreliable transmission service to the upper layer. Such a mechanism will cause the loss of data packets and bit errors, but for UDP transmission, it simply discards them and does nothing else; but for the TCP transmission protocol, the internet layer provides a connectionless and unreliable transmission service to the upper layer, and the transport layer where TCP is located provides a connection-oriented reliable transmission service to the upper layer, which realizes a reliable channel based on TCP connection, and there will be no transmission errors, bit errors, losses, disorder and duplication problems.

Let's compare the headers of UDP and TCP packets. A UDP user datagram consists of a header and a data payload. A TCP segment also consists of a header and a data payload. The UDP user datagram header is only 8 bytes, and only contains the source port, destination port, length, and checksum. For TCP, its header contains more information, and its minimum header size is 20 bytes and the maximum is 60 bytes.

summary

To sum up, the characteristics and differences between TCP and UDP are summarized as follows:

User Datagram Protocol (UDP)

• No connection
• Support one-to-one, one-to-many, many-to-one and many-to-many interactive communications
• Directly package the messages delivered by the application layer
• Best effort delivery, that is, unreliable; no flow control or congestion control
• The header overhead is small, only 8 bytes

Transmission Control Layer Protocol TCP

• Connection-Oriented
• Each TCP connection can only have two endpoints, and can only communicate one-to-one
• Byte stream oriented
• Reliable transmission, using flow control and congestion control
• The minimum header size is 20 bytes and the maximum header size is 60 bytes.

TCP Flow Control

Introduction of sliding window

In the previous article, we described the TCP three-way handshake and four-way handshake process. We know that for TCP communication, each data sent must be confirmed once. When the previous data packet receives a response, the next data packet is sent. The communication process is as follows:

It can be seen from the above diagram that if each time a data packet is sent, an ACK is sent before the next data packet is sent, the efficiency is too low. This is when the concept of sliding window is introduced. With a window, the size of the window can be specified. The window size refers to the maximum value of data that can be sent without waiting for an ACK. For example, if the current window is 3, the sender can send three TCP segments in succession. And as shown in the figure above, if one of the ACKs is lost, it can be confirmed through the next ACK. For example, if ACK 600 is lost, ACK 700 can replace ACK 600.

Flow Control

According to the sliding window mechanism introduced above, we know that because of this mechanism, we can make the transmission rate faster, but if the sender's sending rate is too fast, the receiver may not have time to process it, which will cause data loss. The flow control that will be described is to make the sender's sending rate not too fast so that the receiver can receive it in time. The sliding window mechanism can easily implement the sender's flow control on the TCP connection.

Before introducing how flow control is implemented, let's take a look at the sliding windows of the sender and receiver respectively. First, let's introduce the sender's window. How big is this window for the sender? This depends on how much data the receiver can handle. That is to say, before sending data, the receiver will report a window size to the sender. This window size is also called the Advertised window. What does it mean specifically? See the following diagram:

LastByteAcked: the dividing line between the first and second parts

LastByteSent: the dividing line between the second and third parts

It can also be seen from the schematic diagram that for the Advertised window, the size of this window should be equal to the second part + the third part.

For the receiving end, the content recorded in its cache is simpler, as shown below:

Among them, MaxRcvBuffer is just as its literal meaning, which is the maximum amount of buffer. The window size of the receiver is shown in the blue box. At this point, a question is introduced: are the sizes of the receiving window and the sending window equal?

The answer is not exactly the same. The size of the receive window is approximately equal to the size of the send window.

The reason is that the sliding window is not static. For example, when the receiving application process reads data faster, the receiving window will be emptied quickly. However, this message needs to be transmitted over the network to the sender, so the dependency will be inconsistent. Therefore, it is approximately equal.

That's basically it for the sender and receiver windows. Next is the content about flow control:

First assume that the window remains unchanged, that is, 9. When the confirmation of 4 comes, the window will move one to the right. During this time, the packet with sequence number 13 can also be sent.

If the sender sends too fast at this time, it will send all 10, 11, 12, and 13 of the third part, and then stop sending. The unsent sendable part is 0

At this time, only when the confirmation of packet 5 arrives, it is equivalent to the window sliding one more grid on the client side. At this time, the 14th packet can be sent.

If the receiver processes too slowly, the window size can be adjusted through confirmation information. Now assume a more extreme case, that is, the receiver has not processed data. Then when the confirmation of data packet 6 arrives, the window size cannot be 9, and it needs to be reduced to 8. Below is the change of the window after the sender receives a confirmation packet of 6. It can be seen that the window does not change by moving one grid to the right, but the left side of the window shrinks by one grid, and the overall size of the window does not change.

If the receiving end does not process data, then as more and more packets are confirmed, the window will become smaller and smaller until it reaches 0. The following is the change of the receiving end's window:

The sending window corresponding to the receiver in the above figure is shown below. When the confirmation of 14 reaches the sender, the sender's window is also adjusted to 0 and the sending is stopped.

If this happens, the sender will periodically send window detection packets to see if there is an opportunity to adjust the window size. When the receiver is slow, to prevent low-energy window syndrome, do not immediately tell the sender when a byte is freed up and then fill it up again. When the window is too small, do not update the window until it reaches a certain size or half of the buffer is empty.

The above is the flow control in TCP.

TCP Congestion Control

If the demand for a resource in the network exceeds the available portion of the resource that can be provided over a period of time, network performance will deteriorate. This situation is called congestion.

In computer networks, link capacity (i.e., bandwidth), caches and processors in switching nodes, etc. are all network resources.

If congestion occurs and is not controlled, the throughput of the entire network will decrease as the input load increases.

The following figure is a graph of ideal congestion control, actual congestion control, and no congestion control. The curves are as follows:

TCP's congestion control algorithm mainly involves four aspects:

• Slow Start Algorithm
• Congestion Avoidance Algorithm
• Fast retransmission algorithm
• Fast recovery algorithm

Before explaining these four congestion control algorithms, assume the following conditions:

• Data is sent in one direction, and only confirmation is sent in the other direction
• The receiver always has enough buffer space, so the size of the window sent by the sender is determined by the degree of network congestion.
• The unit of discussion is the maximum segment size (MSS), not bytes.

That is to say, the communication between the sender and the receiver is like this. The specific process is shown in the following figure:

The sender sends a TCP data segment to the receiver, and after the receiver receives the entire segment, it returns a TCP acknowledgment segment to the sender.

That is, the sender maintains a state variable called the congestion window cwnd, whose value depends on the degree of congestion in the network and changes dynamically.

• The maintenance principle of the congestion window cwnd is: as long as there is no congestion in the network, the value of the congestion window will increase; but as long as there is congestion in the network, the congestion window will decrease.
• The basis for judging the occurrence of network congestion is that the confirmation message that should have been received was not received on time (that is, a timeout retransmission occurred).

The sender uses the congestion window as the sending window, that is, swnd = cwdn

Maintain a slow start threshold ssthresh state variable:

• When cwnd < ssthresh, start using the slow start algorithm
• When cwnd > ssthresh, stop using the slow start algorithm and use the congestion avoidance algorithm instead
• When cwnd = ssthresh, either the slow start algorithm or the congestion avoidance algorithm can be used.

Slow start and congestion avoidance algorithms

In order to explain the slow start algorithm, we give the following line graph, where the horizontal axis of the line graph represents the transmission round, and a transmission round means that after the sender sends a data segment to the receiver, the receiver sends a corresponding confirmation segment to the sender. The time experienced in a transmission round is actually the round-trip time, and the vertical axis is the congestion window, which is a dynamically changing value.

When the two TCP parties establish a logical connection relationship, the congestion window value is set to 1. In addition, the initial value of the slow start threshold needs to be set to 16. When the slow start algorithm is executed, the sender increases the congestion window value by 1 each time it receives a confirmation segment from the receiver, and then starts the next round of transmission. When the congestion window value increases to the slow start threshold value, the congestion avoidance algorithm is executed instead.

How to explain the above line graph? That is, if at the beginning, the sender's congestion window value is 1, the sender sends a TCP segment to the receiver, and after the receiver receives it, it sends a TCP confirmation segment to the sender. When the sender receives the confirmation segment, it adds 1 to the congestion window value, because here, the congestion window value is equal to the send window value. Therefore, the send window value is 2 at this time, then the sender can send two segments to the receiver. When the sender receives the confirmation segments of these two segments, it sets the congestion window to 4. At this time, the sender can send 4 TCP segments to the receiver. According to this principle, with each additional round of data packets in the figure, the congestion window value increases exponentially until it increases to the slow start threshold, which is 16. At this time, the congestion avoidance algorithm is used.

What is the congestion avoidance algorithm? That is to say, at present, after each transmission round, the value of the congestion window is changed to linear plus 1, instead of exponential growth like the slow start algorithm. For example, the sender can send data segments 15 to 30 at this time. When the sender receives the data confirmation segments 15 to 30, the congestion window value is increased by 1 to 17. Based on this principle, the sender and the receiver perform several rounds of data transmission, reaching a line graph as shown below:

If at this time, when the congestion window value reaches 24, the sender sends a series of data packets to the receiver again. Assuming that several of these segments are lost during transmission, this will inevitably cause the sender to time out and retransmit these lost segments. The sender judges that the network is likely to be congested based on this. At this time, the following work needs to be done: update the slow start threshold value to half of the congestion window value when congestion occurs, then adjust the congestion window value to 1, and re-execute the slow start algorithm. When the congestion window reaches the slow start threshold value, the congestion avoidance algorithm is executed. The specific process is shown in the figure:

Finally, the entire process is annotated, and the line chart after annotation is shown in the figure:

Fast retransmission algorithm

Sometimes, individual segments will be lost in the network, but there is no congestion in the actual network. This will cause the sender to time out and retransmit, and mistakenly believe that congestion has occurred. At this time, the sender sets the congestion window to the minimum value of 1 and mistakenly starts the slow start algorithm, thereby reducing transmission efficiency.

The fast retransmission algorithm allows the sender to know as early as possible that individual segments have been lost. In other words, fast retransmission allows the sender to retransmit as soon as possible instead of waiting for the timeout retransmission timer to expire before retransmitting.

What is it like specifically? That is, the receiver should not wait until it sends data to send a piggyback confirmation, but should send a confirmation immediately; even if it receives an out-of-order segment, it should immediately send a repeated confirmation of the received segment. Once the sender receives three consecutive repeated confirmations, it will retransmit the corresponding segment immediately, instead of waiting for the segment timeout retransmission timer to time out before retransmitting.

What is the specific process? See the following diagram:

From the above figure, we can see that when sending M2, it does not wait for the confirmation segment of M1 to arrive before sending it. Instead, it sends the M2 segment before the confirmation segment arrives. When sending M3, the datagram is lost. When sending M4, the receiver will continue to send back the confirmation of segment M2 after receiving it. Until sending M6, it is the confirmation packet of M2 that is sent back. At this time, 3 confirmation packets of M2 have been received cumulatively, so the M3 segment is retransmitted immediately. In this way, the timeout retransmission of the M3 segment will not be caused, and the congestion window will not be adjusted to 1, which can greatly improve the transmission efficiency of the network.

Fast recovery algorithm

Once the sender receives three duplicate acknowledgments, it knows that only individual segments are lost. Therefore, the slow start algorithm is not started, but the fast recovery algorithm is executed; the sender adjusts the slow start threshold and congestion window value to half of the current window, and starts to execute the congestion avoidance algorithm.

summary

In summary, we combine the slow start and congestion avoidance algorithms described above, as well as the fast retransmission and fast recovery algorithms to give an example, as shown below:

This diagram can be well explained in combination with the above theory, so I will not elaborate on it here.

Summarize

At this point, the discussion on TCP in computer networks ends here. It is better to read it in conjunction with the previous TCP tutorial.

This article is reprinted from the WeChat public account "wenzi Embedded Software", which can be followed through the following QR code. To reprint this article, please contact the wenzi Embedded Software public account.