网络原理-传输层UDP

最新推荐文章于 2024-11-02 18:29:24 发布

toZxl777

最新推荐文章于 2024-11-02 18:29:24 发布

阅读量1.5k

点赞数 36

文章标签：网络

本文链接：https://blog.csdn.net/2301_79450337/article/details/142667926

版权

上集回顾：

上一篇博客中讲述了应用层如何自定义协议：确定传输信息，确定数据格式

应用层也有一些现成的协议：HTTP协议

这一篇博客中来讲述传输层协议

传输层

socket api都是传输层协议提供的（操作系统内核实现的了），IP地址（确定主机，网络层提供的概念）+端口号（主机上的应用程序，传输层提供的概念），端口号是一个整数，2个字节表示的无符号整数（0 - 65535），< 1024的端口号拿出来，称为“知名端口号”，把这些端口号分配给一些比较知名的服务器程序作为这些服务器的“默认端口号”，同一个机器上，同一时刻内，端口号不能重复被绑定

如何确认，在当前机器上，某个端口号是否被其他进程使用了呢？

netstat命令，查询出当前主机上是否使用8080端口的进程

后面就是绑定了主机端口的进程的id，之前绑定端口号的时候，没有做特殊指定，就把ipv4和ipv6两个协议的ip地址的9090都给绑定了，此时意味着，客户端可以使用ipv4来访问也可以使用ipv6来访问，也可以增加一些选项，只针对ipv4和ipv6来帮顶

两个进程，不能同时绑定同一个端口号，除非一个是UDP，一个是TCP，但是如果是两个UDP或者两个TCP，就会出现绑定失败的情况了，有一个进程A同时绑定10000，10001，10002是可以的，但是不能一个端口号同时被多个进程所绑定

一个进程绑定多个端口号比较常见：

一个服务器程序，首先服务器需要有一个端口号，给客户端提供服务，这样的端口称为”业务端口“，给普通用户使用的
如果程序员需要对这个服务器进行更精细的控制，比如控制让这个服务器重新加载配置/开启某个功能/重新启动/重新加载数据/修改某个选项设定，这样的操作，经常会通过网络来进行操作，服务器就会另外绑定一个端口号，称为“管理端口”，程序员想对这个服务器进行管理操作，就通过管理端口给服务器发送一些对应的请求，服务器执行对应的逻辑（搞个后门，给指定用户的账户余额增加1000，这样的操作势必要通过管理端口，不能通过业务端口）
日常开发会遇到一些bug，需要去查看服务器的一些运行状态（比如服务器中的一些关键的变量是什么样的值），服务器不能直接用调试器去调试（调试器一调试就会把服务器阻塞住，无法给别的客户端提供服务了），也会通过网络的方式，给服务器发调试请求，服务器返回对应的关键信息，称为“调试接口”

传输层主要为两个协议：UDP（无连接，不可靠传输，面向数据报，全双工）和TCP（有连接，可靠传输，面向字节流，全双工）

UDP

学习一个网络协议，最主要就是学习报文格式，对于UDP协议来说，应用层数据到达UDP之后，就会给应用层数据报前面拼装上UDP报头

UDP结构

UDP数据报 = UDP报头 + UDP载荷

UDP各个部分

每个部分，都有特定的含义，UDP长度，描述了整个UDP数据报，占多少个字节，UDP长度，描述了整个UDP数据报，占多少个字节，通过UDP长度，就能知道，当前载荷一共是多少字节

64kb，一个UDP数据报，最长就是64KB，不能更长了，有点短了，使用UDP开发程序，就会有很大的制约，确保传输的单个数据报，不能超过64KB

Question：既然UDP有上述限制，为啥发明UDP的大佬不对UDP做出改进升级呢？比如把报头中报文长度字段改成4字节，或者更长呢？

Answer：最初UDP诞生上个世纪70年代，当时设计成2个字节64KB是比较充裕的，升级上述的报头，不是技术问题，而是zz问题，升级到更高的字节数，成本非常高，单个主机升级，是没有意义的，需要对端也一起升级，世界上任何一个主机，都可能是发送端，也都可能是接收端，要升级，就得全世界所有的主机一起升级，所以，相比于对UDP升级，未来诞生新的协议，取代UDP，可能是更靠谱一些

UDP校验和

关于校验和（checksum）

比特翻转 0101二进制数据（电信号，光信号，电磁波），本来你传输的是0，时机到了对端变成了1，或者本来传的是1，到了对端变成了0，此时如果传输过程中遇到了一个变化的磁场，此时就会可能把本来的低电平变成高电平/高电平变成低电平；再比如，光信号，也可能会收到一些高能离子束的影响

此时就需要能够有办法，对传输的数据进行校验

能够发现是否出错
最好能发现是哪一位出错，并且能够进行纠错（代价大）

本质都是要引入额外的冗余信息，在UDP中，校验和只能够做到第一层，发现是否有错

假设多个bit位都发生改变，导致错误的数据和之前正确的数据得到了相同的数据和，理论上存在，实际上出现的概率非常低，主机A通过校验和转过去UDP数据报，B在这边按照同样的算法，针对数据内容，再算一遍校验和，得到校验和2，此时如果不一致，就说明传输出现问题了（比特翻转了）

UDP中使用的CRC算法进行校验和，CRC是一个简单粗暴的计算校验和的方式，循环冗余校验，设定2个字节的变量，把数据的每个字节取出来，往这个变量上进行累加，如果结果溢出，超出2个字节，溢出部分就舍弃，从AI中可以得出

循环冗余检查（Cyclic Redundancy Check，CRC）是一种广泛用于错误检测的算法，尤其是在数据通信和存储领域UDP协议中使用的校验和计算方法与CRC算法类似，但并不完全相同UDP校验和的计算方法是基于多项式算法的，它使用CRC的思想，但具体的实现和多项式可能有所不同

UDP校验和的计算过程大致如下：

准备数据：将UDP数据报的伪首部、首部和数据部分连续排列起来，形成一个待校验的数据序列
选择多项式：选择一个预定义的二进制多项式，这个多项式用于计算CRC在UDP中，通常使用的是CRC-16或CRC-32多项式，如CRC-16-CCITT或CRC-32标准多项式
除法运算：将待校验的数据序列视为一个大的二进制数，然后将这个二进制数除以选定的多项式这个除法运算是在模2算数下进行的，也就是说，不使用进位
得到余数：除法运算的余数就是CRC校验和这个余数通常是一个固定长度的二进制数，例如16位或32位
附加校验和：将计算得到的余数（CRC校验和）附加到UDP数据报的首部校验和字段中
接收端验证：接收端收到UDP数据报后，使用相同的多项式对数据报进行同样的除法运算如果余数为零，则认为数据报在传输过程中没有发生错误；如果余数非零，则认为数据报可能已经损坏

UDP校验和的计算方法可以有效地检测出数据在传输过程中的意外变化，包括单个比特的错误、双比特的错误以及数据的丢失和重复然而，它不能检测到所有的错误类型，比如数据的顺序错误，也不能对错误进行纠正

需要注意的是，UDP校验和是可选的，并且在某些情况下可能被禁用此外，由于网络环境的复杂性，即使校验和检测到错误，UDP协议也不会采取任何纠正措施，如重传数据报，这是UDP作为无连接、不可靠传输协议的特点

除了CRC算法，还有一个比较常见的方法：md5，md5是一个比较广泛的方法，最初就是一个字符串hash算法