传输层之UDP协议
目录
UDP协议报文
UDP数据报长度受限问题
UDP协议特点
UDP协议报文
UDP协议特点是,面向数据报,不可靠性传输,无连接,全双工-->传输层协议
- 源端口号
源端口号可以理解为从哪个进程发来的.-----源端口号
- 目的端口号
目的端口号可以理解为要到哪个进程.----目地端口号
两个端口号可以理解为从哪里来(源端口号) 到哪里去(目的端口号)
- 包长度
整个UDP数据报的长度(包括UDP数据首部长度+UDP载荷(数据)长度)
UDP数据报长度受限问题
这里有一个经典问题
- UDP数据报长度大小受限只有64KB如果数据超过64KB该怎么进行运输
第一种方案 :
- 将一个UDP数据报拆分成多个数据报运输给对端,多个数据报到达对端时,再将其进行组装.
这个方案也会有问题,在进行网络传输时会有一个特点"后发先至",后发的数据报先到达了,导致顺序乱了,组装的就是无效的数据报.
所以上面一种方案是被我们否决的.
第二种方案:
- 在应用层上利用TCP代替UDP
TCP的长度不受限制内部有可选项可以调整报文长度,另外可以利用TCP的一些重要机制,也可以实现可靠传输,引入序列号,确认应答,超时重传....等机制
还有一个问题
- 既然UDP报文长度大小受限,那么可以对UDP进行升级么,将长度变大一些???
因为UDP协议已经内置各个操作系统内核中,入股要进行通信就要让每个主机都对其操作系统升级,也就是要将全世界的各个操作系统都进行升级,如果有一部分没有升级就不能够传输数据,不能进行工作,因为主机进行通信时,要使用同样的协议进行传输数据.
所以,要将UDP协议进行升级,还不如创造一些其他的协议对其进行更新优化.
- 校验和
由于在传输数据的过程中有可能会导致数据报损坏(在进行数据传输时,由于是信号传输,这个信号会会根据频率/强弱使用0/1来替换,这时可能就会发生比特反转),有数据丢失,这时我们就需要校验和进行验证数据是否准确.
网络传输怎样利用校验和进行检验的
校验和就是在没有发送数据之前将数据描述准确和完整形成的"摘要",在接收到数据的时候再将数据计算,与发送之前的校验和进行比较.
举个例子:
就好像你在淘宝买电脑一样,买之前你要确定好电脑的配置是什么样的(cpu,几核,显卡 内存 外存....),选好电脑商家就会根据你选的配置给你发货,除了货以外还会给你发送配置单(描述你的电脑是什么配置),等你收到货之后,通过下载软件会查看配置是否一样,如果配置一样就可以使用配置不一样就要找商家了.
校验和是如何进行计算的呢???
利用CRC(循环冗余算法)计算,发送发方将每一个字节(16个比特位)进行累加起来,超过2字节就舍去,最终累加的结果,然后在进行反码运算结果就是校验和,接收方将所有每个字节的比特位与校验和一起加起来的之和的16位如果都是1则认为接收数据正确无差错,如果16个比特位中有一个是1就认为是不正确的.
- 一些特殊情况
当然如果在发送数据之前计算的校验和是错的,而你接收过来的数据计算之后和这个错的又相等这样的情况属于很少见的情况,在工程中可以忽略不计.
UDP协议特点
- 无连接
- 面向数据报
- 不可靠性传输
- 全双工
- 可以一对一,一对多,多对一,多对多进行通信
- 没有拥塞控制机制,出现网络阻塞不会影响发送效率
怎么样理解有连接和无连接
有连接就相当于打电话,电话拨通了就可以互相说话
无连接就相当于发微信,不需要建立连接就可以通信
怎么样理解面向数据报和面向字节流
首先面向数据报和面向字节流是相当于在应用层角度上.
面向数据报:比如UDP是以数据报为基本单元进行传输的.
面向字节流:比如TCP是面向字节流的,发送方会以数据报的形式发送给接收方,但是在读取时,接收方会将数据放到接收缓冲区里读取,应用程序是可以N个字节,分多次读取,一次想读几个字节就读几个字节.==>(对于应用层角度==>也就是写代码的角度看是面向字节流的)
怎么样理解可靠性传输和不可靠性传输
可靠性传输:是发送方发送数据给接收方时,发送方是知道接收方有没有接收到数据==>比如钉钉中的消息中有"已读未回"的字样.
不可靠性传输 : 是发送方发送数据给接收方时,发送方是不知道接收方有没有接收到数据==>比如发微信,发送方并不知道接收方看没看见消息.
怎么样理解全双工和半双工
可以想象一个管道,既可以A->B发送又可以B->A发送数据,这时就是全双工的.
如果只能A->B 或者 B->A发送数据===>就是半双工的
UDP协议使用场景
UDP适用于可靠性不高但性能要求很高的场景,比如广播,一对多的情境下(一个发送方多个接收方)