目录
一、UDP简介
UDP协议全称是用户数据报协议（User Datagram Protocol），在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。在OSI模型中，在第四层——传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。
UDP传输与IP传输非常类似。你可以将UDP协议看作IP协议暴露在传输层的一个接口。UDP协议同样以数据包的方式传输，它的传输方式也是"Best Effort"的（尽最大努力交付，但不保证可靠交付），所以UDP协议也是不可靠的。
那么，我们为什么不直接使用IP协议而要额外增加一个UDP协议呢？ 一个重要的原因是IP协议中并没有端口(port)的概念。IP协议进行的是IP地址到IP地址的传输，这意味者两台计算机之间的对话。但每台计算机中需要有多个通信通道，并将多个通信通道分配给不同的进程使用，一个端口就代表了这样的一个通信通道。
二、UDP的特点
2.1 面向无连接
首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。
UDP无连接，时间上不存在建立连接需要的时延。空间上，TCP需要在端系统中维护连接状态，需要一定的开销。此连接装入包括接收和发送缓存，拥塞控制参数和序号与确认号的参数。UCP不维护连接状态，也不跟踪这些参数，开销小。空间和时间上都具有优势。
具体来说就是：
- 在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了
- 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作
举个例子：
- DNS如果运行在TCP之上而不是UDP，那么DNS的速度将会慢很多。
- HTTP使用TCP而不是UDP，是因为对于基于文本数据的Web网页来说，可靠性很重要。
- 同一种专用应用服务器在支持UDP时，一定能支持更多的活动客户机。
2.2 有单播，多播，广播的功能
UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。
2.3 UDP是面向报文的
发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文。
对IP层交上来UDP用户数据报，在去除首部后就原封不动地交付给上层应用进程，报文不可分割，是UDP数据报处理的最小单位。
正是因为这样，UDP显得不够灵活，不能控制读写数据的次数和数量。比如我们要发送100个字节的报文，我们调用一次sendto函数就会发送100字节，对端也需要用recvfrom函数一次性接收100字节，不能使用循环每次获取10个字节，获取十次这样的做法。
2.4 不可靠性（无拥塞控制）
首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。
并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。
再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。
从上面的动态图可以得知，UDP只会把想发的数据报文一股脑的丢给对方，并不在意数据有无安全完整到达。
总的来说：
- UDP没有拥塞控制，应用层能够更好的控制要发送的数据和发送时间，网络中的拥塞控制也不会影响主机的发送速率。某些实时应用要求以稳定的速度发送，能容忍一些数据的丢失，但是不能允许有较大的时延（比如实时视频，直播等）
- UDP提供尽最大努力的交付，不保证可靠交付。因此主机不需要维持复杂的连接状态表。所有维护传输可靠性的工作需要用户在应用层来完成。没有TCP的确认机制、重传机制。如果因为网络原因没有传送到对端，UDP也不会给应用层返回错误信息
2.5 首部开销小，传输数据报文时是很高效的
UDP 头部包含了以下几个数据：
- 两个十六位的端口号，分别为源端口（可选字段）和目标端口
- 整个数据报文的长度
- 整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误
因此 UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的。
三、UDP首部
UDP首部有8个字节，由4个字段构成，每个字段都是两个字节，
- 源端口： 源端口号，需要对方回信时选用，不需要时全部置0。长度为16bit
- 目的端口：目的端口号，在终点交付报文的时候需要用到。长度为16bit
- 长度：UDP的数据报的长度（包括首部和数据），其最小值为8byte（只有首部）。长度为16bit
- 校验和（Checksum）：检测UDP数据报在传输中是否有错，有错则丢弃。该字段是可选的，当源主机不想计算校验和，则直接令该字段全为0。UDP和TCP的校验和都覆盖到了他们的首部和数据，而IP报文首部的校验和只覆盖了IP首部。长度为16bit
16bit的源端口和目的端口用来标记发送和接受的应用进程。因为UDP不需要应答，所以源端口是可选的，如果源端口不用，那么置为零。当运输层从IP层收到UDP数据报时，就是根据首部中的目的端口，把UDP数据报通过相应的端口，上交最后的终点——应用程序。
如果接收方UDP发现收到的报文中的目的端口号不正确（不存在对应端口号的应用进程0,），就丢弃该报文，并由ICMP发送“端口不可达”差错报文给对方。ICMP应用Traceroute,就是让发送的UDP用户数据报故意使用一个非法的UDP端口，结果ICMP返回“端口不可达”差错报文，因而达到了测试的目的。
以下为这四部分的示意图：
四、UDP校验
4.1 UDP校验和
在计算校验和的时候，需要在UDP数据报之前增加12字节的伪首部，伪首部并不是UDP真正的首部。只是在计算校验和时，临时添加在UDP数据报的前面，得到一个临时的UDP数据报。校验和就是按照这个临时的UDP数据报计算的。伪首部既不向下传送也不向上递交（但是会在发送方和接收方之间进行同层次[运输层]的传送），而仅仅是为了计算校验和。这样的校验和，既检查了UDP数据报，又对IP数据报的源IP地址和目的IP地址进行了检验。
UDP校验和的计算方法和IP数据报首部校验和的计算方法相似，都使用二进制反码运算求和再取反，但不同的是：IP数据报的校验和只检验IP数据报的首部，但UDP的校验和是把首部和数据部分一起校验。
在发送端，首先是将全零放入检验和字段，并且添加伪首部。再将伪首部以及UDP用户数据报（包括UDP首部和数据部分）看成是由许多16bit的字串接起来。 若UDP用户数据报的数据部分不是偶数个字节，则要填入一个全零字节(即：最后一个基数字节应是16位数的高字节而低字节填0)。 然后按二进制反码计算出这些16bit字的和(两个数进行二进制反码求和的运算的规则是：从低位到高位逐列进行计算。 0和0相加是0，0和1相加是1，1和1相加是0但要产生一个进位1，加到下一列。若最高位相加后产生进位，则最后得到的结果要加1)，即将伪首部、UDP首部、UDP数据部分的所有二级制数按照16位为一组分割出来，将所有的16位的二进制数求加和，然后将得到的结果取反存入到UDP报文的校验和字段中（修改初始的全零校验和），然后发送此UDP用户数据报。 在接收端，将收到的UDP首部、UDP数据连同伪首部(以及可能的填充全零字节)一起，按照上面相同的方法进行计算，求分割出来的16bit数据的二进制和，并且将结果取反。 当无差错时其结果应全为1。否则就表明有差错出现， 接收端就应将此UDP用户数据报丢弃(也可以上交给应用层，但附上出现了差错的警告)。
这种差错检验的检错能力不强，但是简单，速度快
4.2 TCP协议、IP协议、ICMP协议的校验方法
4.2.1 TCP协议
TCP 的校验和计算方法同UDP一样，同样要加上一个伪头部，区别是伪头部的协议码是0x06，长度是整个TCP报文的长度（包含TCP头部）。
4.2.2 IP协议
IP协议的首部检验和占16位。这个字段只检验数据报的首部，但不包括数据部分。这是因为数据报每经过一个路由器，路由器都要重新计算一下首部检验和（一些字段，如生存 时间、标志、片偏移等都可能发生变化)。不检验数据部分可减少计算的工作量。为了进一步减小计算检验和的工作量，IP首部的检验和不采用复杂的CRC检验码而采用下面的简单计算方法：在发送方，先把IP数据报首部划分为许多16位字的序列，并把检验和字段置零。用反码算术运算把所有16位字相加后，将得到的和的反码写入检验和字段。接收方收到数据报后，将首部的所有16位字再使用反码算术运算相加一次。将得到的和取反码，即得出接收方检验和的计算结果。若首部未发生任何变化，则此结果必为0，于是就保留这个数据报。否则即认为出差错，并将此数据报丢弃。下图说明了 IP数据报首部检验和的计算过程。
4.2.3 ICMP协议
ICMP校验和的计算方法一样，只不过只是对ICMP包整个进行校验和，没有伪头部，也不包括IP包头部。
四、UDP协议使用场景
- 需要资源少，在网络情况比较好的内网，或者对于丢包不敏感的应用。如DHCP协议就是基于UDP的。一般的获取IP地址都是内网请求，而且一次获取不到IP又没事。
- 不需要一对一沟通，建立连接，而是可以广播的应用。DHCP就是一种广播的形式。VXLAN也是需要用到组播，也是基于UDP协议的。
- 需要处理速度快，时延低，可以容忍少数丢包，但是要求即便网络拥塞，也毫不退缩，一往无前的时候。
- QUIC是Google提出的一种基于UDP改进的通信协议，其目的是降低网络通信的延迟，提供更好的用户互动体验。
- UDP常用一次性传输比较少量数据的网络应用，如DNS,SNMP等，因为对于这些应用，若是采用TCP，为连接的创建，维护和拆除带来不小的开销。UDP也常用于多媒体应用（如IP电话，实时视频会议，流媒体等）数据的可靠传输对他们而言并不重要，TCP的拥塞控制会使他们有较大的延迟，也是不可容忍的
参考资料：https://www.linuxidc.com/Linux/2018-09/154366.htm
计算机网络（第7版）-谢希仁