table of Contents
The difference between TCP and UDP protocols
TCP provides connection-oriented services. The connection must be established before data transmission, and the connection must be released after data transmission. TCP does not provide broadcast or multicast services. Because TCP must provide reliable, connection-oriented transmission services (the reliability of TCP is reflected in the three-way handshake to establish a connection before TCP transmits data, and there are confirmation, window, retransmission, and congestion control mechanisms during data transmission. After the data is transmitted, the connection will be disconnected to save system resources), which inevitably increases a lot of overhead, such as confirmation, flow control, timers, and connection management. This not only increases the header of the protocol data unit a lot, but also takes up a lot of processor resources. TCP is generally used in scenarios such as file transfer, sending and receiving mail, and remote login.
UDP does not need to establish a connection before transmitting data, and the remote host does not need to give any confirmation after receiving the UDP packet. Although UDP does not provide reliable delivery, UDP is indeed the most effective way of working in some cases (usually used for instant messaging), such as: QQ voice, QQ video, live broadcast, etc.
How does the TCP protocol ensure reliable transmission
-
Application data is divided into data blocks that TCP considers most suitable for sending.
-
TCP numbers each packet sent, and the receiver sorts the data packets and transmits the ordered data to the application layer.
-
Checksum:
TCP will keep the checksum of its header and data. This is an end-to-end checksum, the purpose of which is to detect any changes in data during transmission. If there is an error in the received checksum, TCP will discard the segment.
-
The receiving end of TCP discards duplicate data.
-
flow control:
Each party of a TCP connection has a fixed-size buffer space, and TCP reception only allows the sender to send data that the receiver's buffer can accept. When the receiver is too late to process the sender's data, it can prompt the sender to reduce the sending rate to prevent packet loss. The flow control protocol used by TCP is a variable-size sliding window protocol.
-
Congestion control:
When the network is congested, reduce data transmission.
-
ARQ protocol:
It is also to achieve reliable transmission. Its basic principle is to stop sending every time a packet is sent and wait for the other party to confirm. After receiving the confirmation, send the next packet.
-
Timeout retransmission:
When TCP sends a segment, it starts a timer and waits for the destination to confirm receipt of this segment. If an acknowledgment cannot be received in time, the segment will be resent.
ARQ protocol
Automatic Repeat-reQuest (ARQ) is one of the error correction protocols in the data link layer and the transport layer in the OSI model. It realizes reliable information transmission on the basis of unreliable services by using the two mechanisms of confirmation and timeout. If the sender does not receive an acknowledgment frame within a certain period of time after sending it, it will usually resend it. ARQ includes stop-and-wait ARQ protocol and continuous ARQ protocol.
Stop waiting for ARQ protocol
The stop-waiting protocol is to achieve reliable transmission. Its basic principle is to stop sending every time a packet is sent, and wait for the other party to confirm (reply ACK). If after a period of time (after the timeout period), the ACK confirmation is still not received, it means that the transmission was not successful and needs to be retransmitted until the confirmation is received before sending the next packet;
In the stop-and-wait protocol, if the receiver receives a duplicate packet, it discards the packet, but at the same time it sends an acknowledgement;
Advantages: simple
Disadvantages: low channel utilization and long waiting time
Two situations to stop waiting for ARQ protocol
1. No errors
The sender sends the packet, the receiver receives it within the specified time, and replies to confirmation. The sender sends again.
2. An error occurs (timeout retransmission)
The timeout retransmission in the stop waiting protocol means that as long as the confirmation is not received for a period of time, the previously sent packet is retransmitted (it is considered that the previously sent packet is lost). Therefore, it is necessary to set a timeout timer every time a packet is sent, and its retransmission time should be longer than the average round-trip time of data in packet transmission. This type of automatic retransmission is often referred to as automatic retransmission request ARQ. In addition, if a duplicate packet is received in the stop-and-wait protocol, the packet is discarded, but an acknowledgment is also sent.
Confirm lost and confirmed late
Confirmation lost: The confirmation message was lost during transmission. When A sends an M1 message and B receives it, B sends an M1 confirmation message to A, but it is lost during transmission. And A does not know that after the timeout expires, A retransmits the M1 message, and B takes the following two measures after receiving the message again: 1. Discard the repeated M1 message and not deliver it to the upper layer. 2. Send a confirmation message to A. (It will not be considered that it has been sent, and it will not be sent again. A can retransmit, it proves that B's confirmation message is lost).
Confirmation late: The confirmation message was late during transmission. A sends an M1 message, and B receives and sends a confirmation. If the confirmation message is not received within the timeout period, A retransmits the M1 message, but B still receives and continues to send the confirmation message (B received 2 copies of M1). At this time, A receives the confirmation message sent by B for the second time. Then send other data. After a while, A receives the confirmation message for M1 sent by B for the first time (A also received 2 confirmation messages). The processing is as follows: 1. After receiving the repeated confirmation, A discards it directly. 2. After B receives the duplicate M1, it also directly discards the duplicate M1.
Continuous ARQ protocol
Continuous ARQ protocol can improve channel utilization. The sender maintains a sending window, and all packets within the sending window can be sent continuously without waiting for the other party to confirm. The receiver generally uses cumulative acknowledgments to send an acknowledgment to the last packet arriving in sequence, indicating that all packets up to this packet have been received correctly.
Advantages: High channel utilization, easy to implement, even if the confirmation is lost, there is no need to retransmit.
Disadvantages: Cannot reflect to the sender the information of all packets that the receiver has correctly received. For example: the sender has sent 5 messages and the third one is missing (No. 3). At this time, the receiver can only send confirmations to the first two. The sender cannot know the whereabouts of the last three packets, and has to retransmit all the last three. This is also called Go-Back-N, which means that it needs to go back and retransmit the N messages that have been sent.
Sliding window and flow control
TCP uses a sliding window to achieve flow control. Flow control is to control the sending rate of the sender to ensure that the receiver has time to receive. The window field in the confirmation message sent by the receiver can be used to control the window size of the sender, thereby affecting the sending rate of the sender. If the window field is set to 0, the sender cannot send data.
Congestion control
In a certain period of time, if the demand for a certain resource in the network exceeds the available part that the resource can provide, the performance of the network will deteriorate. This situation is called congestion. Congestion control is to prevent excessive data from being injected into the network, so that the routers or links in the network are not overloaded. There is a prerequisite for all congestion control, that is, the network can withstand the existing network load. Congestion control is a global process that involves all hosts, all routers, and all factors related to reducing network transmission performance. On the contrary, flow control is often the control of point-to-point traffic, which is an end-to-end problem. What the flow control needs to do is to suppress the rate at which the sending end sends data so that the receiving end can receive it.
In order to control congestion, the TCP sender must maintain a congestion window (cwnd) state variable. The size of the congestion control window depends on the degree of network congestion and changes dynamically. The sender makes its sending window the smaller of the congestion window and the receiver's acceptance window.
TCP congestion control uses four algorithms, namely slow start, congestion avoidance, fast retransmission and fast recovery. At the network layer, routers can also adopt appropriate packet discarding strategies (such as active queue management AQM) to reduce network congestion.
Slow start
The idea of the slow start algorithm is that when the host starts to send data, if a large amount of data bytes are injected into the network immediately, it may cause network congestion, because the compliance of the network is not known yet. Experience has shown that a better method is to probe first, that is, gradually increase the sending window from small to large, that is, gradually increase the congestion window value from small to large. The initial value of cwnd is 1, and after a propagation round, cwnd is doubled.
Congestion avoidance
The idea of the congestion avoidance algorithm is to slowly increase the congestion window cwnd, that is, add 1 to the sent cwnd after each round-trip time RTT.
Fast retransmission and fast recovery
In TCP/IP, fast retransmit and recovery (FRR) is a congestion control algorithm that can quickly recover lost data packets. Without FRR, if the data packet is lost, TCP will use a timer to request the transmission to be suspended. During the timeout period, no new or copied data packets are sent. With FRR, if the receiver receives an out-of-sequence data segment, it will immediately send a repeat confirmation to the transmitter. If the sender receives three duplicate acknowledgments, it will assume that the data segment indicated by the acknowledgment is missing, and immediately retransmit these missing data segments. With FRR, there is no delay due to the timeout required during retransmission. When individual data packets are lost, fast retransmission and recovery (FRR) can work most effectively. When multiple data packets are lost in a short period of time, it cannot work effectively.
You can read this article about congestion control, which is very good: