【JavaEE】应用层自定义协议及UDP协议
- 博主简介:想进大厂的打工人
- 博主主页:@xyk:
- 所属专栏: JavaEE初阶
本篇文章将为大家介绍应用层中UDP协议~~
在应用层这里,虽然存在一些现有的协议(HTTP),但是也有很多情况,需要程序猿自定制协议,对于自定制协议来说,就是个很简单的事情~~那么怎么理解这件事情?
目录
文章目录
一、应用层协议(自定义组织格式)
1.1 如何约定自定义协议
二、UDP格式
2.1 UDP报文的格式
一、应用层协议(自定义组织格式)
应用层在大多数情况下,可能需要程序猿自定义协议来约定~
什么是自定义组织协议?
比如说:qq发一个消息,构成一个应用层的数据报
此处只是模拟一下qq的数据报格式,真实的qq采取的数据报可能更加复杂
约定应用层数据报,数据格式,就是在自定义协议
1.1 如何约定自定义协议
约定:
1.要传输哪些信息(根据需求走的)
2.确定数据按照啥样的格式来组织(随意约定的)
网络上传输的,本质上都是 0101,视为二进制的字符串~~
需要把上述这些信息整合成一个字符串~~
只要发送方按照这套格式来组织数据,接收方按照这套格式来解析数据,两者能对上,这样的格式就是可行的~~~
常见组织格式:
- 分隔符
- 以空格、回车…分割
- 以分号…表示结束
实际开发会使用一些现成的格式:
- xml
- html是特殊的xml格式
- html标签名和含义都是固定的,是我们需要遵守的
标签的形式:< XXX > … </ XXX>
2.json
-
以{ }作为标识
-
内部有多个键值对,每个键值对之间用逗号分割
-
key与值之间使用冒号分割
- key必须是字符串,
- 值可以是数组,字符串,数字甚至是另一个json
二、UDP格式
2.1 UDP报文的格式
实际的格式不是这样子的,这样只是为了计算机网络的教材方便印刷~~~
载荷中存储的是一个完整的应用层数据报~
每个端口号 在UDP报文里,占两个字节~~
其实端口号的取值范围 0 -> 65535
< 1024 的端口号,称为“知名端口号”,给一些名气大的服务器预留的端口~~
比如:http :80,ssh : 22,ftp:21,
- “端口0”并不正式存在。 它被定义为无效的端口号。
至于“专属座位”有什么用
- 服务器一般端口号不需要怎么改变,所以保持在一个端口号是个正常的抉择
- 不然每次你都要去查这个常用的服务器端口号是多少~
2字节 表示的范围 0 -> 65535 => 64KB(64KB - 1B),表示一个UDP报文最大长度就是 64 KB!!!(近似)
- 代表UDP正文最大就是64KB大而已
- 不是说只能传一个“65535”大小的整数~
- 而是65535字节的数据量!
时代不同,现在64KB很小了,一个表情包都能几MB了~
- 但是如果要扩大这个限制,那么我们就要升级UDP系统,全世界主机太多了,用的都不是一样的操作系统,有windows,linux,mac
- 只有都升级,才能通讯,这不现实~
要传输大数据
- 把一个大的数据拆分为多个数据部分,使用多个UDP数据报来传输~~
- 不用UDP,直接用TCP去传输 ,TCP就没有限制~
2.2 校验和:
网络传输并非那么稳定,可能会出现误差
- 我们传递的数据本质是01…,而我们用高低电平表示01
难免会有一些干扰,例如强磁场(太阳黑子)
这样就会导致一些高电平转变为低电平,低电平转变为高电平
- 那么校验和的存在,就相当于定下了一个标准
- 满足这个标准,数据不一定对;但是不满足这个标准,这个数据肯定错
- 而这个校验和,要是中间数据发生01转变,大概率是对不上的
- 可能校验和跟数据发生突变后,还对上了。很极端的情况
比如:去市场买菜
需要买西红柿,鸡蛋,茄子,芹菜,一共四样
如果买到的菜少于或者多于四样,100%是错的!
但是如果手里的菜是四样,也不一定是对的,可能是错误的~
为了让校验和能够识别率更高一些,计算的时候通常会以数据内容作为参数来进行计算.
数据内容发生变化,校验和也会变化~~
带有内容的校验和:
发送方把这一串数据发给接收方,接收方收到的数据,既有载荷,也有校验和sum1
接受方就可以按照载荷按照同样的算法,再计算一边校验和,得到了sum2
对于sum1和sum2是否相同,如果不相同,数据一定出现了问题!!
udp这里使用的是CRC算法,是一个简单粗暴的算法,大家可以自行了解~~
UDP协议还是相对简单,下一篇我们介绍TCP协议~~~~