雏鹰部落

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 957|回复: 0

[学习/资料] 【SPOTO思博网络】UDP协议,在现网中是不可缺少!!

[复制链接]
发表于 2021-8-30 21:48:34 | 显示全部楼层 |阅读模式
【SPOTO思博网络】UDP协议,在现网中是不可缺少!!

每一个网工应该都知道TCP、UDP协议。UDP是用户数据报文协议,属于OSI模型中的传输层。它是一种无连接的协议,也就说上一报文和下一报文在协议层没有任何联系,同时提供了简单的不可靠的传输服务。
也就是说UDP是不可靠的,如果要想让数据可靠,就需要在业务层做纠错和检错功能。比如:TFTP。
那可能就会有同学问了,既然是不可靠的,为什么不直接使用IP协议呢?还要这么大费周章增加一种协议UDP呢?
其实其中一个最重要的原因就是IP协议中没有端口(port)的概念,它只是规定了两台主机之间的通信,并没有解决不同主机上应用程序之间的通信。如果一个主机上的多个应用程序需要通信,直接用IP协议就无法数据区分数据到底哪个应用程序了。

可以理解为一个端口就是一个通信通道,当然UDP在IP协议的基础上增加了一些功能,所以我们来总结下:
· UDP无连接,没有连接。所以它的发送和接受的开销就会小很多。
· UDP不保证数据可靠交付,所以不需要维护复杂的连接关系。
· UDP是面向报文的,添加在应用层下来数据头部,直接塞给IP层。
· UDP没有拥塞控制
· UDP至支持多播。
· UDP头部小,说明传输更多的数据内容
下图展示是UDP和上下层的关系:

UDP的首部到底是怎样的呢?

先看下图:


从图中可以看出,UDP的首部由四部分组成:
· 各16bit的来源端口和目的端口用来标记发送和接受的应用进程。因为UDP不需要应答,所以来源端口是可选的,如果来源端口不用,那么置为零。当运输层从IP层收到UDP数据报时,就是根据首部中的目的端口,把UDP数据报通过相应的端口,上交***的终点--应用程序。
如果接收方UDP发现收到的报文中的目的端口号不正确,就会丢弃改报文,并由网际控制协议ICMP发送“端口不可达”差错报文给发送方。ICMP应用Traceroute,就是让发送的UDP用户数据报故意使用一个非法的UDP端口,结果ICMP返回“端口不可达”差错报文,因而达到了测试的目的。

· 在目的端口后面是长度固定的以字节为单位的报文长度域,用来指定UDP数据报包括数据部分的长度,长度最小值为8byte。
· 首部剩下地16bit是用来对首部和数据部分一起做校验和(Checksum)的,这部分是可选的,但在实际应用中一般都使用这一功能。
· UDP和TCP的校验和都覆盖到了他们的首部和数据,而IP首部的校验和只覆盖了IP首部。
UDP和socket怎样配合使用?
随着我们进入传输层,我们也可以调用操作系统中的API,来构建socket。Socket是操作系统提供的一个编程接口,它用来代表某个网络通信。应用程序通过socket来调用系统内核中处理网络协议的模块,而这些内核模块会负责具体的网络协议的实施。
这样,我们可以让内核来接收网络协议的细节,而我们只需要提供所要传输的内容就可以了,内核会帮我们控制格式,并进一步向底层封装。因此,在实际应用中,我们并不需要知道具体怎么构成一个UDP包,而只需要提供相关信息(比如IP地址,比如端口号,比如所要传输的信息),操作系统内核会在传输之前会根据我们提供的相关信息构成一个合格的UDP包(以及下层的包和帧)。看下图吧。

UDP使用场景

l  需要资源少,在网络情况比较好的内网,或者对于丢包不敏感的应用。如DHCP协议就是基于UDP的。一般的获取IP地址都是内网请求,而且一次获取不到IP又没事。又比如基于UDP的RTP,TFTP,丢一帧数据问题也不大。再比如一些设备发现协议等等。
l  不需要一对一沟通,建立连接,而是可以广播的应用。DHCP就是一种广播的形式。VXLAN也是需要用到组播,也是基于UDP协议的。
l  需要处理速度快,时延低,可以容忍少数丢包,但是要求即便网络拥塞,也毫不退缩,一往无前的时候。

l  QUIC是Google提出的一种基于UDP改进的通信协议,其目的是降低网络通信的延迟,提供更好的用户互动体验。
|| 备考不用慌,大佬带你飞 : 每三位IE,有两位来自思博
进入全国网络工程师交流群 ,请扫描下方二维码↓↓↓
群里有行业大咖、实战分享、技术交流、技术咨询、企业内推等机会
若群满,请添加老杨微信,邀你进群
【推荐阅读】


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|熊猫同学技术论坛|小黑屋| 网络工程师论坛 ( 沪ICP备09076391 )

GMT+8, 2024-12-22 13:16 , Processed in 0.083960 second(s), 19 queries , Gzip On.

快速回复 返回顶部 返回列表