It's my understanding that TCP has logic for ensuring reliable communication, but UDP just naively sends information along the channel set up for it using IP and things in lower layers.
Does UDP actually do anything? I'm kind of confused by why it even has a name.
Interesting perspective and question!
Yes, most of what UDP does is supply a standard means for multiple applications to co-exist using the same IP address, by defining the concept of UDP ports.
The exciting part about UDP isn't so much the network protocol but the API implemented by operating systems and socket libraries. While not part of the UDP specifications itself, the ability to use abstractions like the POSIX socket API to easily develop software atop protocols like UDP is key to the success of the Internet Protocol stack.
UDP is a transport protocol, like TCP. That means it provides a protocol for an application to use IP. Like TCP, UDP has addressing (ports) to which applications bind so that datagrams destined to bound applications get sent by UDP to the correct applications. UDP for IPv4 also provides an optional checksum, but the checksum is required for IPv6.
UDP is a message-based protocol, where TCP is a stream-based protocol. UDP can be useful for application-layer protocols to provide some, but not all features of TCP, and many applications or application-layer protocols cannot make use of, or are even damaged by, the reliability of TCP. For example, real-time protocols, such as VoIP, video, or even gaming, cannot make use of lost datagrams after they are no longer useful, so having TCP resend the data would have a bad outcome. When you use VoIP, and the other person answers, you want to hear, "Hello," not, "Oh, hell."
Other things, such as multicast, are unidirectional, but TCP requires setting up a bidirectional connection between two applications, while a multicast application sends data to many receivers. TCP cannot really do that, but it is easy to use UDP with multicast.
I would encourage you to look at how higher level protocols that utilize UDP actually use it. Classic and well documented examples are DNS (in most cases at least, it's possible to do DNS over TCP but it's really uncommon), DHCP, NTP, and PTP.
All of these protocols have some specific things in common:
The first two points are trivially covered by any reasonable transport layer protocol (even exotic stuff like TIPC), including TCP. However, TCP is horrible for the other two points, because it requires you to roll your own message framing protocol on top of it's streams for message oriented protocols and the significant connection startup and maintenance overhead means that it's very inefficient for short infrequent exchanges of data.
In other words, the 'feature' of UDP that makes it worth worrying about at all is that it provides the bare minimum for those first two points without getting in your way like TCP does for these types of applications. It also has a bit of an advantage over TCP in that it's trivial to implement either purely in hardware or on a miniscule system with less than 1Kb of RAM and a miniscule amount of storage space for code (this is part of why BOOTP, RARP, TFTP, and other bootstrap protocols originally used it). The disadvantage is reliability and susceptibility to certain types of attacks if using long-lived stateful 'connections' over it without very careful management, but the protocols that use it and care about that handle it themselves (see TFTP for an example of dealing with the reliability issue, albeit at the cost of speed).
Now, there are options that can achieve similar feature sets (or even more comprehensive feature sets) to TCP with far less overhead and still allowing for message oriented communication (primary examples include RUDP, DCCP, and SCTP), they just haven't really caught on for a combination of reasons, so UDP just kind of sticks around.
There's an important point that UDP does not require setting up a "connection".
For example, it would be hard and complex, if not impossible, to implement DHCP on top of TCP, where a client has no IP address and zero knowledge of the existing network environment. It's therefore meaningless to "set up a connection", as the client doesn't know the target address and doesn't have a source address. UDP makes this easy by allowing a broadcast a DHCP request to the existing network, and one (and hopefully only one) DHCP server will respond with an offer.
Similarly, most network broadcast actions make little sense with TCP*, because you can't have a "connection" with a "broadcast target" where every single host accept and respond. Things like sequence numbers and checksums don't add up.
* We're not talking about stuff like MPI_Bcast(). They're really out of scope for this question.
To me the key thing that UDP does is provide both source and destination port numbers and hence allow not just multiple different application protocols, but also multiple instances of the same application protocol.
In principle you could build your application protocol directly on top of IP and obtain a protocol number for it. That works fine if you have only one instance of your application protocol on each host, however it does not work so well if you want to have multiple instances of the same application protocol on each host.
By having seperate source and destination port numbers and estalishing the conventions that clients use ephemeral ports while servers use well-known ports and that responses swap the port numbers UDP supports multiple instances of the same application protocol on the same host.
It offers multiplexing/demultiplexing services to the upper layers (App) so it can handle data from different processes. With the checksum, it will also bring you error detection.
UDP, being such a simple protocol, is useful for upper layer protocols that prefer fast communication, without the need for establishing a connection or reliable data transfer.
In addition to that, some protocols such as DNS, use UDP for their purposes...
I think it is important to note DHCP relies on UDP 100%, and it is extremely widely used.
Also DNS historically used UDP, and only uses TCP when the response is too big for a UDP packet.
