【JavaEE】——Udp翻译器的实现（回显服务器）

​

目录

一：自定义协议

二：xml方案

三：json方案

四：protobuffer方案

五：传输层

六：UDP协议

七：校验和/检验和

一：自定义协议
程序员在调用操作系统提供的网络API写出来的代码都是属于应用层的（回顾五个层级：应用层，传输层，网络层，数据链路层，物理层），应用层自身就有许多已经创建好的协议，但多数情况下是需要程序员自定义协议的

1：自定义协议
主要约定好两方面的内容

（1）交互哪些信息
解释：服务器和客户端之间要交互哪些信息，由产品经理规定需要传输哪些信息

（2）数据的具体格式
解释：客户端按照约定构造、发送请求，解析返回的响应

服务器按照约定解析请求，构造、发送响应

2：（反）序列化
Client和Server之间交互的是“结构化数据”，网络传输的数据其实是“字符串”“二进制bit流”，约定协议的过程就是把“结构化数据”转化为“二进制bit流”的过程

结构化数据———转化———>字符串/二进制bit流       叫做“序列化”

字符串/二进制bit流———还原———>结构化数据        叫做“反序列化”

3：业界方案
为了让程序员更方便的约定这里的协议格式，给出了几个可以直接套用的方案

二：xml方案

1：优点
（1）可读性好：标签的名字能够对数据起到描述作用

（2）延展性好：后续增加属性，只需新增标签，不影响原有代码

2：缺点
整个数据冗余信息非常多，标签占据的空间可能反而比数据本身更多了，在网络传输中会消耗更多的网络带宽（网络带宽这种硬件资源很贵）

三：json方案

1：结构
键值对结构

键和值用   ： 分开

键值之间用     ,    分开

多个键值对用{}括起来，构成一个json对象

多个json对象用   ,   分开  整体用[]括起来形成一个json数组

2：优点
（1）可读性好

key对数据起到解释说明

（2）占用空间更小

相比较于xml中需要开始和结束两个标签，json只用了一个key，更节省网络带宽（这里的节省是相对的，json中的key也会被多次创建）

（3）延展性好

四：protobuffer方案
开发阶段（写代码）定义出有哪些资源，描述每个字段的含义，真正运行的时候，实际传输的数据是不包含这样的描述信息

优点：程序的运行效率高

缺点：不利于程序猿阅读

所以只有那些对性能要求非常高的场景才会使用protobuffer

五：传输层
在数据传输过程中，虽然传输层是操作系统内核中已经实现好的，但是我们也需要重点关注，我们使用的socket的API都是由传输层提供的

对于端口号，它是一个2字节的整数（0，2的16次方-1），在使用端口号的时候，[1,1024]都是属于系统保留的自用的端口号(知名端口号)

六：UDP协议
1：特点
回顾一下：无连接，不可靠传输，面向数据报，全双工，

UDP数据报=报头+载荷

UDP报头中4个字段，每个字段2个字节，共8个字节

协议中报头用2个字节表示端口号，能表示的范围为2^16-1=65535，即[0,65535]，

换算一下为64KB——即UDP数据报最大长度为64KB，载荷部分应该是64KB-8

七：校验和/检验和
1：比特翻转
验证数据在传输过程中是否正确，数据在网络传输中可能会坏掉，网络传输本质是发送方的物理层把二进制数据转化为光电信号发送出去。再由另一端的物理层接收光电信号在转化为二进制数据，在这个过程中，很有可能由于外界信号的干扰，发生“1->0”“0->1”这样的翻转情况，导致我们的数据出现问题，校验和的作用就是用来识别数据是否出现比特翻转的。

2：数据参与
校验和是拿着原始信息的一部分内容参与计算的，例如把这样一段字符串“张三今天想吃麻辣烫”传输，在传输之前会把字符串通过某种运算转化成例如“AD343SCSCAF2321”这样的密码串，校验的时候，再运算一次，（在运算转化的过程中，数据可能会超出范围，不打紧）通过比较两次运算的结果可以知道，该次数据传输是否是一致的正确的

3：CRC算法

4：md5算法特点
（1）定长

无论原始数据有多长，算出来的md5最终值都是固定长度

（2）分散

计算md5的过程中，原始数据只要变化一点点，最后得到的md5值就会差异很大

（3）不可逆

给定一个md5的值还原为原始的字符串，理论来说不可行，因为在字符串转化为md5的过程中，已经有很多数据丢失了，特点（1），有兴趣的友友可以在浏览器上搜一下（有点像加密——密码学）

​