【网络篇】 |
您所在的位置：网站首页 › udp协议的特征包括哪些 › 【网络篇】 |
【网络篇】
|
文章目录
前言1、UDP协议2、协议格式
2.1、协议格式模型2.2、字段分析3.协议特性4.编程影响总结
前言
1、UDP协议
UDP协议，又名数据报传输协议，是传输层协议之一！！！ 在TCP/IP五层模型中，在传输层中，对数据的封装时，会对上层应用层的数据，封装对应传输层协议的报头！！！可铁子，你知道UDP报头中长啥损样不？？
16位的报头长度，实则就已经限制了，UDP报文大小必须要小于64K 同时在套接字编程中，我们还接触一接口，sendto函数接口（UDP发送数据接口） 函数接口原型如下： ssize_t sendto(int sockfd, const void *buf, size_t len, int flags, const struct sockaddr *dest_addr, socklen_t addrlen);其中buf参数，为发送数据的数据长度，它的长度会有限制吗？？？ 当然！UDP报文的被限制于64K以内，而其中固定数据包含8字节（16位源端端口，16位对端端口，16位报头长度以及16位的校验和），而剩余的64K-8，即为发送数据的最大长度； 16位校验和： 用于检验接受到的数据是否于发送的数据一致； 之所以存在校验和，是因为，数据在传输给对端的时候，可能收到多方面因素的影响，例如网速，进而导致数据出现部分丢失，甚至数据到达对端的先后不同而产生错误；因而对端在接受数据时，首先就会通过一定算法，比较报文头部字段中的校验和，判断当前按数据是否与发送数据保持一致；一致则接受，反之则直接丢弃；而其中，关于用校验和验证接受到数据与发送数据是否一致，大佬们则想出了算法！！二进制反码求和算法，步骤如下： - 发送方将报文数据组织完毕，将校验和字段置为0； - 从第0个字段（包含头部），对每个字段进行取反，求和； - 再求和过程中，若数据大小超过16位，则截断，并于低16位进行求和； - 最终得到的32字节的校验和数据，填充UDP头部的校验和字段中； - 接受方接受到数据，同样对数据进行相同的操作！！！关于这种算法，博主，也没具体尝试过，不过倒是想起了数据的原码与反码的相互转换，其中，有一种方法，便是，对同一数据的原码，反码进行相同的数求反码操作，均会得到对方； 3.协议特性UDP协议，有三大特性，即无连接，不可靠与面向数据报传输； 无连接： 即收发数据双方，无需建立连接，便可接收发送数据；就比如咱们在一些聊天APP上，比如QQ，不一定需要对方在线才能发送数据，当然QQ的通信方式，以UDP为主，TCP-为辅； 不可靠： 即不能保住数据有序，且安全的到达对端；其原因也在于，UDP传输不存在丢包检测，重传机制以及无包序管理，上述提到的16校验和，实则仅仅只是验证数据的一致，而并没有做出任何使数据安全的措施; UDP说： 但是UDP，人家也是真的快啊！！！在无以上的操作，UDP的传输效率也得到了大大提升； 面向数据报： UDP的数据都是整条交付的，且数据有固定最大长度限制，必须小于64K； 4.编程影响 由于数据可能无法安全对端，那就让收拾这烂摊子吧！！！；程序猿，可在应用层进行对应操作： 但是要是数据大于64K呢？则需要分包处理！！(此处的分包，是在应用层方面对数据进行分包，与UDP数据的整条交付必定不冲突~~) UDP要求数据整条传输交付当接受方接受UDP数据时，会将其整条（带头部）置于接受缓冲区中！！ ~~~ 带头部，这嘛呢？？不带头部，嘛取数据呢？？！！对于UDP报文数据的解析，首先就先取出头部的16位报头长度，之后减去8字节固定数据，剩下的便是数据大小；（也正因为如此，UDP传输不存在数据的粘包问题！！！） 同时需要注意的是，程序员接受recvfrom接受数据的缓冲区，一定要足够大！！！否则，可能应为无法存放下数据而导致，数据丢失！！！ 总结传输层，不还有个TCP吗，博主觉的两个板块，分别写一个博客，会方便观看点~ 下期，TCP协议，仍会从以上方面，逐个分析，还有诸多面试题的详细分析！！！ 不想错过，就给博主，一个小小的关注吧？
|
这就为佬，你解密！！！
【本文地址】
今日新闻 |
推荐新闻 |