本文要介绍的是UDP传输协议，相比前面一篇Blog介绍的TCP协议来说要简单的多。UDP不需要建立连接也不需要考虑对方是否收到数据包，也不用考虑丢包重传机制，所以对于UDP的设计要解决的问题来说要简单的多了，UDP更关注的是把用户的数据发送出去就即可完成任务。
UDP适用于不需要或在程序中执行错误检查和纠正的应用，它避免了协议栈中此类处理的开销。对时间有较高要求的应用程序通常使用UDP，因为丢弃数据包比等待或重传导致延迟更可取。
UDP短数据
UDP协议更关注的是用户的数据和发送用户的数据达到互联网上，剩下的步骤就交给物理的网络链路设备了，至于对方能不能收到此数据包UDP协议是不用关心的；但程序员自己可以参考类似于TCP那样的协议在设置超时机制来判断对方是否收到，或者说通过对方回传UDP数据包的方式来保障，那这种UDP通信方式把数据包的传输可靠性交给了用户来控制。
udp协议的包头部分相比tcp的包头字段要少得多了，发送端口、接收端口、数据长度、数据包完整性校验和组成的一个数据包，udp只需要关注的是一次性传输的数据。比如DNS的域名查询请求，用户态的程序只需要把数据放入缓冲区然后使用系统调用接口即可发送出去数据包。
UDP设计原则
第一发送数据之前不需要建立连接，传输数据因为每次适用于小数据包场景也不用考虑丢失重传机制，即使如果真的要重新传输用户态程序可以自定义重传规则，因为没有通信连接状态机所以断开连接也不需要进行复杂的状态机同步断开机制。
udp协议可以发送的数据最大长度为IP包的最大长度减去IP包头和自己本身的UDP包头的长度，这里的长度和MTU、MSS不是一个层面的东西，MTU和MSS是基于以太网和通信链路上网络包的最大长度来计算的。从IP协议来看包最大长度为65535，这里减去前面所有包头部分剩下65507字节，当然这么长的长度肯定是超过了MTU允许的范围，所以大数据包传输的时候还是依赖于IP模块拆分包的，所以建议使用UDP协议传输数据的时候使用数据量不多的时候。
udp协议常用场景就是直播视频和实时语音通话了，因为追求的是实时性不需要考虑丢包重新传输情况，所以udp非常适合；如果像tcp协议去做的话，数据包丢失了还要考虑重传，可能用户程序会出现卡顿重新加载情况，重新发送数据也会消耗时间，重新发送数据也没有用因为实时性很强的程序是追求的是实时性而不是消息可靠性。此外我们日常使用微信打视频或者语音的时候因为网络情况不好也会出现卡顿情况，这对用户来说是网络问题，而不是实时性问题，用户没有听到也可以要求对方人为重复一遍，哈哈哈哈。
小 结
由于UDP缺乏可靠性且属于无连接协议，所以应用程序通常必须容许一些丢失、错误或重复的数据包，某些应用程序如TFTP可能会根据需要在应用程序层中添加基本的可靠性机制，具体怎么运用UDP这得看开发者自己的需求了，如果开发者足够了解这些协议应该会做出明智的选择。
