The thing about the UDP protocol

Recently, I was reviewing the knowledge of computer networks. I didn't study it seriously in class before, and I only remembered a few high-level terms. So taking advantage of this review, I recorded the knowledge I learned in the form of a blog, firstly to deepen my impression, and secondly Come and hope to give you a deeper understanding of these basics. Of course, I will try my best to make the UDP protocol clear and clear, so that you can make your trip worthwhile.


The UDP (User Datagram Protocol) protocol is translated as the User Datagram Protocol . Like the TCP protocol, it is located in the transport layer of the OSI model. However, compared with the TCP protocol, the UDP protocol is much simpler, because it does not have complex processing mechanisms such as "flow control" and "congestion control". It doesn't even have a retransmission mechanism, that is to say, if your data packets are lost halfway, they can't be found, so the UDP protocol is unreliable. Of course, this retransmission mechanism is for the transport layer . You can write a protocol at the application layer to handle packet loss. For example, like TCP, add ACK and sequence number mechanisms.

Then you may be wondering, why not use the reliable TCP protocol, but choose the UDP protocol?

UDP segment structure

This of course depends on the needs of the application, but before we talk about this topic, let's take a closer look at the UDP protocol.

To be honest, the segment structure of UDP is much simpler than that of TCP (see the figure below). After all, there is no redundant mechanism in the UDP protocol.

Closer to home, the "source port number" and "destination port number" in the message segment are to tell the transport layer where (which process) my message came from and where (which process) it is going to. But be careful: a UDP socket is identified by a two - tuple , which refers to the destination IP address and destination port number , that is, the corresponding process on the server, does not care which client you are from I put it into a socket for processing, and after processing, send the response information to the client according to the source port number and source IP address. In contrast, TCP sockets require a four-tuple to identify: source IP address, source port number, destination IP address and destination port number . This point will be discussed in detail when talking about the TCP protocol, so I won't go into details here.

PS: You may ask, why is there no IP address in this segment? This is because the IP address is stored in the IP protocol segment of the network layer, and of course not in the packet segment of the transport layer.

not connected

Every time we mention the TCP protocol, the first thing that comes to our mind is the three-way handshake and the four-time wave . For the UDP protocol, this is nothing. When using the UDP protocol, if the client wants to send a segment to the service The terminal is sent directly without handshake , and because of this, the UDP protocol is called connectionless .

It is easy to think that if there is no need for the handshake process, there will be no delay caused by establishing a connection . One word, fast! This is also a large part of the reason why DNS (Domain Name System) runs on top of the UDP protocol.

But the UDP protocol is unreliable. What should I do if packets are lost during transmission? The easiest thing to do is - ignore it! (Otherwise, as mentioned at the beginning of the article, the retransmission mechanism must be implemented at the application layer) Take DNS as an example, if the packet is lost, the client will retransmit it (with a timeout mechanism), and under normal circumstances, the lost The probability of a package is very low. However, if the TCP protocol is used, the domain name query will be much slower because a connection needs to be established. In addition, the network overhead of using the UDP protocol is smaller - the UDP segment has an 8-byte header overhead, while the TCP protocol There is 20 bytes of overhead (see the previous two figures for segments). Low network overhead means that the DNS server can accept more client requests.

On the other hand , the TCP protocol has a congestion control mechanism, which will contain the TCP sender when the network is congested, so as to delay the transmission of the segment , so for some real-time programs that require small transmission delay and can tolerate some data loss, That said, the UDP protocol might be a better choice. Routing Protocol (RIP) and Network Management Protocol (SNMP) also choose UDP as the underlying transport protocol.

Finally, this is a flow chart of the communication between the client and the server using the UDP protocol:

There is not much to talk about in the UDP protocol. The next time I will talk about the TCP protocol, it will be more brain-burning, so be prepared!

If this article is helpful to you, welcome to pay attention to the ravings of my public account tobe , and take you deep into the world of computers~ There are surprises in the background of the public account to reply to the keyword [computer]~

{{o.name}}
{{m.name}}

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324148016&siteId=291194637