（ 该图由我使用 AI 绘制 ）
目录
不需要重发的数据用 UDP 发送更高效
控制用的短数据
音频和视频数据
不需要重发的数据用 UDP 发送更高效
DNS
服务器查询
IP
地址的时候我们用的是
UDP
协议
简单的说就是，TCP之所以复杂，是因为他要确认的东西很多，比如发了10个包，7号包失败了，TCP可以知道哪个包失败，重发的时候只需要发这一个就好了
而UDP不知道，但是他也有他的好处，那就是，只发一个包的时候
控制用的短数据
像
DNS
查询等交换控制信息的操作基本上都可以在一个包的大小范围内解决
，
这种场景中就可以用
UDP
来代替
TCP
UDP
没有
TCP
的接收确认
、
窗口等机制
，
因此在收发数据之前也不需要交换控制信息
，
也就是说不需要建立和断开连接的步骤
，
只要在从应
用程序获取的数据前面加上
UDP
头部
，
然后交给
IP
进行发送就可以了
（
表
）。
接收也很简单
，
只要根据
IP
头部中的接收方和发送方
IP
地址
，
以及
UDP
头部中的接收方和发送方端口号
，
找到相应的套接字并将数据交
给相应的应用程序就可以了
。
除此之外
，
UDP
协议没有其他功能了
，
遇到
错误或者丢包也一概不管
。
因为
UDP
只负责单纯地发送包而已
，
并不像
TCP
一样会对包的送达状态进行监控
，
所以协议栈也不知道有没有发生错
误
。
但这样并不会引发什么问题
，
因此出错时就收不到来自对方的回复
，
应用程序会注意到这个问题
，
并重新发送一遍数据
音频和视频数据
还有另一个场景会使用
UDP
，
就是发送音频和视频数据的时候
。
音频和视频数据必须在规定的时间内送达
，
一旦送达晚了
，
就会错过播放时机
，
导致声音和图像卡顿
。
如果像
TCP
一样通过接收确认响应来检查错误并重
发
，
重发的过程需要消耗一定的时间
，
因此重发的数据很可能已经错过了
播放的时机
。
一旦错过播放时机
，
重发数据也是没有用的
，
因为声音和图
像已经卡顿了
，
这是无法挽回的
。
当然
，
我们可以用高速线路让重发的数
据能够在规定的时间内送达
，
但这样一来可能要增加几倍的带宽才行
。
此外
，
音频和视频数据中缺少了某些包并不会产生严重的问题
，
只是
会产生一些失真或者卡顿而已
，
一般都是可以接受的
。
在这些无需重发数据
，
或者是重发了也没什么意义的情况下
，
使用
UDP
发送数据的效率会更高
