The love-hate relationship between TCP and UDP

Recently, the epidemic in Qiaoxi District, Shijiazhuang, has been quite serious. I was locked in the company for three days last week. It was difficult to wash and eat. I finally applied to go home from the company and it has been locked in for another week. Every day, I am wandering around in various apps and WeChat groups to grab food. It is really grabbing instead of buying. The goods in Carrefour supermarket are sold out in two minutes after they are online. I don’t know how this group of people grabbed the food. Are they all people in the circle? There are also endless nucleic acid tests every day, which makes people helpless and headache. The double-digit new positive cases every day make people numb and see no hope. I just received a notice today saying that you can go out of the unit door to stretch your muscles...

Say something good:?

I have written many articles about TCP and UDP, but I have not discussed the differences between these two protocols. In this article, we will talk about this issue.

Regarding TCP and UDP, I believe everyone has seen a picture like this.

There is a little girl drinking water slowly from a bottle, with "Reliable Transmission" written below. The girl's clothes are not wet by the water. This picture is called TCP.

Then there was a little girl holding a water bottle and pouring water down at a very fast speed. The girl's hair was messy, her face was red, and her clothes were soaked by water. This picture is called UDP.

I think any programmer can roughly summarize the differences between the two transmission protocols from these two pictures (after all, they are clearly written on the pictures). Even many students have developed evil thoughts about UDP. Can't the author just draw a good picture? Why does he have to make his face red and his clothes wet? . . . . . .

Well, let's get back to the topic. The difference between TCP and UDP has always been the focus of interviews, and they are also the two protocols that are often used for various comparisons.

Differences in establishing connections

TCP needs three handshakes to establish a connection, and four handshakes to disconnect. This also means that TCP is a connection-oriented protocol. This connection does not use a network cable or a pipe to bind the two communicating parties together, but establishes a virtual communication pipe.

TCP three-way handshake process (the client sends a connection request to the server):

• The server process is ready to receive TCP connections from the outside, which is usually done by calling the bind, listen, and socket functions. This is considered a passive open. The server process is then in the LISTEN state, waiting for client connection requests.
• The client initiates an active open through connect​ and sends a connection request to the server. The synchronization bit SYN = 1 in the request header and selects an initial sequence number sequence, abbreviated as seq = x. The SYN segment is not allowed to carry data and only consumes one sequence number. At this point, the client enters the SYN-SEND state.
• After receiving the client connection, the server needs to confirm the client's message segment. In the confirmation message segment, both the SYN and ACK bits are set to 1. The confirmation number is ack = x + 1, and it also selects an initial sequence number seq = y for itself. Please note that this message segment cannot carry data, but it also consumes a sequence number. At this point, the TCP server enters the SYN-RECEIVED (synchronous received) state.
• After receiving the response from the server, the client needs to confirm the connection. The ACK in the confirmation connection is set to 1, the sequence number is seq = x + 1, and the confirmation number is ack = y + 1. TCP stipulates that this segment can carry data or not. If it does not carry data, the sequence number of the next data segment is still seq = x + 1. At this time, the client enters the ESTABLISHED (connected) state.
• After receiving the client's confirmation, the server also enters the ESTABLISHED state.

UDP is a datagram-oriented protocol, so UDP does not have the concept of connection at all, and there is no three-way handshake process to establish a connection.

After the data transmission is completed, the communicating parties can release the connection. After the data transmission is completed, both the client host and the server host are in the ESTABLISHED state, and then enter the process of releasing the connection.

(The client host actively closes the connection)

The process of TCP disconnection is as follows:

• The client application sends a message segment to release the connection, stops sending data, and actively closes the TCP connection. The client host sends a message segment to release the connection. The FIN bit in the header of the message segment is 1, it does not contain data, and the sequence number bit seq = u. At this time, the client host enters the FIN-WAIT-1 (termination wait 1) stage.
• After the server host receives the message segment sent by the client, it sends a confirmation response message with ACK = 1 in the confirmation response message, generates its own sequence number seq = v, ack = u + 1, and then the server host enters the CLOSE-WAIT state. At this time, the connection in the direction of client host -> server host is released, and the client host has no data to send. At this time, the server host is in a semi-connected state, but the server host can still send data.
• After the client host receives the confirmation response from the server host, it enters the FIN-WAIT-2 (Termination Wait 2) state, waiting for the client to send a connection release message segment.
• When the server host has no data to send, the application process will notify TCP to release the connection. At this time, the server host will send a disconnection message segment, in which ACK = 1 and sequence number seq = w. Because some data may have been sent in the meantime, seq is not necessarily equal to v + 1. ack = u + 1. After sending the disconnection request message, the server host enters the LAST-ACK (last confirmation) stage.
• After the client receives the disconnect request from the server, it needs to respond and send a disconnect message segment. In the message segment, ACK = 1, sequence number seq = u + 1, because the client has not sent any data since the connection was disconnected, ack = w + 1, and then enters the TIME-WAIT state. Please note that the TCP connection has not been released at this time. The client must wait for the time setting, that is, 2MSL​, before entering the CLOSED​ state. The time MSL is called the maximum segment lifespan (Maximum Segment Lifetime).
• After the server receives the disconnect confirmation from the client, it will enter the CLOSED state. Because the server ends the TCP connection earlier than the client, and the entire disconnection process requires sending four segments, the process of releasing the connection is also called four waves.

UDP does not have this connection, so it does not require four handshake operations.

So to sum up: TCP is connection-oriented. It needs to maintain a virtual connection before data transmission. Data transmission needs to be carried out on this virtual connection. After data transmission is completed, the connection needs to be disconnected. UDP transmission is not connection-oriented. UDP does not establish a connection when sending data, nor does it care about the status of the receiving end.

Difference in reliability

One of the main comparisons between TCP and UDP is reliability. TCP is a reliable transport layer protocol, while UDP is an unreliable transport layer protocol. The reliability of TCP is mainly guaranteed by the following features:

Reliability through sequence and acknowledgement numbers

The mutual communication between computer network hosts is very similar to the phone calls between two people in our daily life. This kind of conversation is usually in the form of question and answer. If you say a sentence and don't receive any response, you usually need to say it again to make sure whether the other party hears you. If the other party responds to you, it means that he has heard your speech. This is a complete call process (leaving aside the establishment of the connection, we focus on the period after the connection is established).

"The response from the other party" is called an acknowledgment (ACK) in computer networks. TCP uses ACK to achieve reliable data transmission. That is, after sending a request, the sender will wait for the response from the target host. If no response is received, the sender will retransmit the request after a period of time. Therefore, even if packet loss occurs during the sending process, TCP can still achieve reliability through retransmission.

The situation described above belongs to the sender's request loss. There is another situation that belongs to the response loss. That is to say, after the request is sent to the target host, the target host will send an ACK to the requester. This ACK may also be lost. If the ACK is lost in the link, the requester will not receive the ACK from the target host after a period of time, and will still choose to retransmit the request that did not receive the ACK.

In addition to message loss, there is also a phenomenon of delayed arrival. Delayed arrival refers to the phenomenon that after the sender sends a segment, the segment may not reach the target host due to network jitter or network congestion, or the target host's response ACK may not reach the sender. The standard for judging this period of time is the retransmission time. Once the retransmission time has passed, the sender will retransmit the segment. It is very likely that the first sent segment has just arrived after the retransmission segment arrives. This poses a problem: the target host receives two identical segments. One segment must be selected to be discarded, but which segment should be selected?

This can be achieved through sequence numbers (seq), which are numbers that are assigned to each byte of the sent data in order. The receiving end queries the sequence number and data length in the TCP header, and returns the sequence number that it should receive next as a confirmation response. Through the sequence number and confirmation response number, TCP can identify whether the data has been received and whether it needs to be received, thereby achieving reliable transmission.

As shown in the figure above, if the request is sent in sequence, seq = 1. This request will send the data from the 1st byte to the nth byte together, wait for the target host to confirm each byte once, and then send a request of seq = n + 1. After the confirmation is completed, send a request of seq = m + 1. This ensures that the sequence number will not be repeated.

UDP does not have so-called sequence numbers and confirmation numbers, so it will not confirm the data, and will not retransmit the data after it is lost, so UDP is an unreliable protocol.

If we use TCP and UDP to compare developers: TCP is the kind of engineer who wants to design everything and will not develop without design. He needs to take all factors into consideration before starting to work! So he is very reliable; while UDP is the kind of engineer who just starts working as soon as he receives the project requirements, regardless of design or technology selection. This kind of developer is very unreliable, but suitable for rapid iterative development because he can get started right away!

Orderly Difference

As we mentioned above, TCP will send requests separately, and the data carried by each request will be confirmed by the target host. After the target host confirms each request in turn, it will reassemble the data in the request. Since the requests are ordered by seq, TCP will also reassemble the data in order, while UDP does not have such orderliness guarantee.

Differences in segments

TCP and UDP are both transport layer protocols. The data transmitted by the transport layer protocols are collectively called message segments. The main differences between TCP and UDP message segments are as follows.

UDP segment structure

• Source Port: This field occupies the first 16 bits of the UDP header and usually contains the UDP port used by the application sending the datagram. The receiving application uses the value of this field as the destination address to send the response. This field is optional and sometimes the source port number is not set. If there is no source port number, it defaults to 0 and is usually used in communications that do not require return messages.
• Destination Port: Indicates the receiving port, the field length is 16 bits.
• Length: This field occupies 16 bits and indicates the length of the UDP datagram, including the UDP header and the UDP data length. Since the UDP header length is 8 bytes, the minimum value is 8 and the maximum length is 2 ^ 16 = 65535 bytes.
• Checksum: UDP uses checksum to ensure data security. UDP checksum also provides error detection function. Error detection is used to verify whether the integrity of the data has changed during the process of sending the message segment from the source to the target host.

TCP segment structure

The TCP segment structure has a lot more content than the UDP segment structure. However, the first two 32-bit fields are the same. They are the source port number and the destination port number. In addition, like UDP, TCP also contains a checksum field. In addition, the TCP segment header also has the following

• 32-bit sequence number field and 32-bit acknowledgment number field. These fields are used by TCP senders and receivers to achieve reliable data transmission.
• 4-bit header length field, which indicates the length of the TCP header in 32-bit words. The length of the TCP header is variable, but usually the option field is empty, so the length of the TCP header field is 20 bytes.
• 16-bit receive window field, which is used for flow control. It is used to indicate the number of bytes that the receiver is able/willing to accept.
• The variable options field is used by the sender and receiver to negotiate the maximum message length, that is, the MSS.
• 6-bit flag field. The ACK flag is used to indicate that the value in the acknowledgment field is valid and that the segment includes an acknowledgment of a successfully received segment. The RST, SYN, and FIN flags are used for connection establishment and closing. The CWR and ECE flags are used for congestion control. The PSH flag is used to indicate that the data is immediately handed over to the upper layer for processing. The URG flag is used to indicate that there is urgent data in the data that needs to be processed by the upper layer. The last byte of the urgent data is pointed out by the 16-bit urgent data pointer field. In general, PSH and URG are not used.

Therefore, from the comparison of the message segment structure, it can be seen that TCP has many more flags, sequence numbers and confirmation numbers than UDP, which are all part of TCP's connection control. In addition, there is also a receive window, which is part of congestion control and flow control. The TCP header overhead is larger than UDP, because the TCP header is fixed at 20 bytes, while the UDP header is fixed at only 8 bytes. Both TCP and UDP provide data verification functions.

Difference in efficiency

TCP segments are sent in a "question-and-answer" format. Each request will be confirmed by the target host before the next message is sent. This is very inefficient. Later, in order to solve this problem, TCP introduced the concept of window, which can control the decline in network performance even when the round-trip time is long and the frequency is high.

Each request we sent before was in the form of a segment. After the introduction of the window, each request can send multiple segments, that is, a window can send multiple segments. The window size refers to the maximum value of the segment that can be sent without waiting for a confirmation response.

In this window mechanism, a large number of buffers are used to confirm and respond to multiple segments at the same time.

As shown in the figure below, the highlighted part of the sent segment is the window we mentioned. Within the window, the request can be sent even if no confirmation response is received. However, before the confirmation response of the entire window arrives, if some segments are lost, the sender will still retransmit. For this reason, the sender needs to set up a cache to retain these segments that need to be retransmitted until their confirmation response is received.

The part outside the sliding window is the message segments that have not been sent yet and the message segments that have been received. If the message segment has been confirmed, it cannot be retransmitted. At this time, the message segment can be cleared from the buffer.

When a confirmation is received, the window will slide to the position of the confirmation number in the confirmation response, as shown in the figure above. In this way, multiple segments can be sent simultaneously in sequence to improve communication performance. This window is also called a sliding window.

The message segments sent by UDP do not need to be confirmed, and there is no concept of window, so UDP transmission efficiency is relatively high.

Differences in usage scenarios

TCP and UDP differ in efficiency, message segments, flow control, and connection management. These differences lead to different choices for application scenarios. Since each TCP packet needs to be confirmed, TCP is not suitable for scenarios where data is transmitted quickly. For example, UDP is used for Ping and DNS Lookup, which only require a simple request/reply and do not require a connection. UDP is sufficient. For example, the HTTP protocol needs to consider the reliability of request responses. In this scenario, the TCP protocol should be used. However, for application layer protocols such as HTTP 3.0, from a functional perspective, there are not many optimization points for the time being. However, if you want to optimize the network to the extreme, you will use UDP as the underlying technology and then solve the reliability problem based on UDP.