【JavaEE】应用层自定义协议及UDP协议

• 博主简介：想进大厂的打工人
• 博主主页：@xyk:
• 所属专栏: JavaEE初阶

本篇文章将为大家介绍应用层中UDP协议~~

在应用层这里，虽然存在一些现有的协议（HTTP），但是也有很多情况，需要程序猿自定制协议，对于自定制协议来说，就是个很简单的事情~~那么怎么理解这件事情？

---

目录

文章目录

一、应用层协议（自定义组织格式）

1.1 如何约定自定义协议

二、UDP格式

2.1 UDP报文的格式

---

一、应用层协议（自定义组织格式）

应用层在大多数情况下，可能需要程序猿自定义协议来约定~

什么是自定义组织协议？

比如说：qq发一个消息，构成一个应用层的数据报

此处只是模拟一下qq的数据报格式，真实的qq采取的数据报可能更加复杂

约定应用层数据报，数据格式，就是在自定义协议

1.1 如何约定自定义协议

约定：

1.要传输哪些信息（根据需求走的）

2.确定数据按照啥样的格式来组织（随意约定的）

网络上传输的，本质上都是 0101，视为二进制的字符串~~

需要把上述这些信息整合成一个字符串~~

 只要发送方按照这套格式来组织数据，接收方按照这套格式来解析数据，两者能对上，这样的格式就是可行的~~~

常见组织格式：

1. 分隔符
   • 以空格、回车…分割
   • 以分号…表示结束

实际开发会使用一些现成的格式：

1. 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
• 只有都升级，才能通讯，这不现实~

要传输大数据

1. 把一个大的数据拆分为多个数据部分，使用多个UDP数据报来传输~~
2. 不用UDP，直接用TCP去传输 ，TCP就没有限制~

---

2.2 校验和：

网络传输并非那么稳定，可能会出现误差

• 我们传递的数据本质是01…，而我们用高低电平表示01

难免会有一些干扰，例如强磁场（太阳黑子）

这样就会导致一些高电平转变为低电平，低电平转变为高电平

• 那么校验和的存在，就相当于定下了一个标准
  • 满足这个标准，数据不一定对；但是不满足这个标准，这个数据肯定错
  • 而这个校验和，要是中间数据发生01转变，大概率是对不上的
  • 可能校验和跟数据发生突变后，还对上了。很极端的情况

比如：去市场买菜

需要买西红柿，鸡蛋，茄子，芹菜，一共四样

如果买到的菜少于或者多于四样，100%是错的！

但是如果手里的菜是四样，也不一定是对的，可能是错误的~

---

为了让校验和能够识别率更高一些,计算的时候通常会以数据内容作为参数来进行计算.

数据内容发生变化,校验和也会变化~~

 带有内容的校验和：

发送方把这一串数据发给接收方，接收方收到的数据，既有载荷，也有校验和sum1

接受方就可以按照载荷按照同样的算法，再计算一边校验和，得到了sum2

对于sum1和sum2是否相同，如果不相同，数据一定出现了问题！！

udp这里使用的是CRC算法，是一个简单粗暴的算法，大家可以自行了解~~

UDP协议还是相对简单，下一篇我们介绍TCP协议~~~~