概述:
UDP只在IP的数据报服务之上增加了两个最基本的服务:复用和分用以及差错检测
UDP不保证可靠交付,但是不意味着应用对数据的要求是不可靠的,只是所有维护可靠性的工作可由用户在应用层完成
UDP是面向报文的,发送方UDP对应用层交下来的报文直接添加首部后就交付给IP层,一次一个报文,不合并也不拆分,保留这些报文的边界;接收方UDP对IP层交付来的UDP数据报除去首部后原封不动交付给上层应用进程,一次交付一个完整的报文
UDP报文不可分割,是UDP数据报处理的最小单位。应用程序必须选择合适大小的报文,如果报文太长,交付给IP层时可能会导致分片;如果报文太短,交给IP层后,会使IP数据报的首部的相对长度太大,两者都会影响IP层的效率
UDP的优点:
UDP无须连接
无连接状态
分组首部开销小
应用层可以更好地控制要发送的数据和发送时间
支持一对一、一对多、多对一和多对多的交互通信
UDP的应用场景:
效率要求相对高,对准确性要求相对低的场景,如:QQ聊天(即时通讯,速度要求高,允许偶尔出现断续,但是完全不可以使用重发机制)
常用于一次性传输较少数据的网络应用,如:DNS,SNMP
多媒体应用(如IP电话、实时视频会议、流媒体等)
广播通信(广播、多播)
为什么即时通讯使用UDP协议时完全不可以使用重发机制?
因为一般来说用户可以接受图像稍微模糊一点,声音稍微不清晰一点,但是难以接受在几秒钟以后再出现之前丢失的画面和声音
为什么DNS会用UDP?
准确的来说,DNS既使用TCP也使用UDP。区域传送使用TCP传输,服务器返回给客户端查询域名时使用UDP传输。
当进行区域传送(主域名服务器向辅助域名服务器传送变化的那部分数据)时会使用TCP,因为数据同步传送的数据量比一个请求和应答的数据量要多,而TCP允许的报文长度更长,因此为了保证数据的正确性,会使用基于可靠连接的TCP。
当客户端向DNS服务器查询域名(域名解析)的时候,一般返回的内容不会超过UDP报文的最大长度,即512字节,用UDP传输时,不需要创建连接,从而大大提高了响应速度,但这要求域名解析服务器和域名服务器都必须自己处理超时和重传从而保证可靠性。
UDP协议为什么不可靠?
四点原因:
不保证消息交付:不确认,不重传,无超时
不保证交付顺序:不设置包序号,不重排,不会发生队首阻塞
不跟踪连接状态:不必建立连接或重启状态机
不进行拥塞控制:不内置客户端或网络反馈机制
UDP首部格式
![](https://img-blog.csdnimg.cn/img_convert/03aa4b5b57f83317b64a38567b173af2.png)
UDP数据报包含两部分:UDP首部和用户数据
UDP首部占8B,4个字段各占2B
各字段意义:
源端口:源端口号,在需要对方回信时选用,不需要时可用全0
目的端口:目的端口号,在终点交付报文时必须使用到
长度:UDP数据报长度(包括UDP首部和数据),最小值为8(只有首部)
校验和:检测UDP数据报在传输中是否有错,错误则直接丢弃。字段可选,当源主机不想计算校验和时,则该字段直接全0
UDP基于端口的分用
![](https://img-blog.csdnimg.cn/img_convert/8bf4573232c36312603a8b8581b45731.png)
UDP协议实现分用时所依据的头部字段是目的端口号
当传输层从IP层收到UDP数据报时,根据首部中的目的端口号,把UDP数据报通过相应端口上交给应用进程
如果接收方UDP发现收到的报文中的目的端口号不正确(不存在对应端口号的进程),直接丢弃该报文,并由ICMP发送“端口不可达”差错报文给发送方
UDP校验
计算校验和时,要在UDP数据报之前添加12B的伪首部,伪首部并不是UDP的真正首部,伪首部既不向下传送也不向上递交,只是为了计算校验和临时添加的
IP数据报校验和只校验IP数据报的首部,UDP的校验和检查首部和数据部分
步骤
发送方:
发送方首先将全0放入校验和字段并添加伪首部,然后把UDP数据报视为许多16位字串接起来
如果UDP数据报的数据部分不是偶数个字节,则要在数据部分末尾填入一个全零字节(该字节和伪首部一样,是不发送的)
然后按二进制反码计算出这些16位字的和,将此和的二进制反码写入校验和并发送
接收方:
接收方把收到的UDP数据报加上伪首部(如果不是偶数个字节,还需要补上全零字节),按二进制反码求这些16位字的和
如果无差错结果为全1,否则表明有差错出现,接收方应该丢弃这个UDP数据报
注:
如果校验出UDP数据报是错误的,可以丢弃,也可以交付给上层,但是需要附上错误报告(告诉上层这是错误的数据报)
通过伪首部不仅可以检查源端口号、目的端口号和UDP数据报的数据部分,还可以检查IP数据报的源端口号和目的端口号