浅谈自定义应用层协议与UDP的报文结构和注意事项

目录

1.自定义应用层协议

2.UDP的报文结构和注意事项

---

1.自定义应用层协议

1.1 概念 

在我们的应用层中，不乏有许多现成的协议如HTTP或者DNS等等。但在实际工作中，为了满足我们的各种需求，仍然需要我们自定义应用层协议。那么什么是协议呢？

协议：

通俗地讲就是一种约定，规定了客户端和服务器以什么样的格式来传输数据

1.2 实际场景分析 

假如现在有一项前后端协同开发的工作需要A和B两个小组共同完成， 那么他们首先需要共同决定A要给B传输什么数据，数据是按照什么格式来组织的，B要给A回复什么数据，数据是按照什么格式来组织的。而这个决定的过程实际上就是在自定义协议。

我们再换一个更具体的场景来看。比如我们经常会用到的点外卖这个操作 ，而这实际上在客户端与服务器之间发生了以下交互。

 当然实际需求会比这更多，我们为了方便就简化了一部分。

关于自定义协议我们一般要从两方面考虑

1.交互过程传输的信息有哪些

2.这些信息的组织格式 

其中第一点我们已经完成，我们接下来看到第二点如何约定信息的格式

方式一： 

一种简单的约定方式就是直接使用简单的分隔符来对不同部分信息做区分，比如“\n”或者“；”等等，比如下图

 方式二：

另一种典型的数据约定格式就是使用固定长度来区分从哪里到哪里是一个信息

 

方式三：

 当然我们也可以将上面两种方法结合，有些字段使用分隔符，有些字段使用固定长度

方式四：

通过xml（一种标记语言）格式来约束，这个我们不多讲，大家感兴趣可以自行学习。

方式五： 

json，比xml应用更加广泛，同样不多讲

方式六：

 通过其他“二进制”数据组织格式，如protobuffer，thrift

区别 

 例如xml和json属于文本格式，它的优势在于可读性高，但是占用带宽更多，效率较低

 而protobuffer，thrift等二进制的格式它的格式更加复杂，可读性低，但是占用带宽少，效率高

而在服务器中带宽是一个很珍贵的资源，所以我们还是需要根据实际需求来选择合适的协议

2.UDP的报文结构和注意事项 

2.1 UDP的报文结构

我们在教科书上看到的一般都是下面这副图

不过我们可以转化成下面这张图会更好理解

 

如果将一次UDP通信比作一次网购，其中源端口号就相当于寄件人电话，目的端口号相当于收件人电话。

接下来UDP长度表示了UDP的数据报有多长，但是其中存在一个问题，2个字节能表示的最大数据是65535=>64KB，也就是说UDP数据报最大只有64KB，放在如今这是非常小的，所以这也是UDP的一个缺陷。

校验和是为了重新检测发送的数据与接收的是否一致，UDP采用的校验和检验算法是一种简单的CRC算法（循环冗余校验和）。核心原理就是把数据的每个字节都向上加，如果超出范围（2字节）则进行类似于取模的运算，所有字节累加完成后得到的结果就是校验和

2.2 注意事项 

由于UDP数据报的大小限制，我们在传输一些比较大的数据时有以下两种解决方案：

1.将数据拆分成多个部分，使用多个UDP数据报来发送，最后再进行组装

2.直接放弃UDP采用TCP

关于UDP校验和：
如果输入的数据都是相同的，那么CRC一定相同，但是CRC相同数据不一定相同（比如1+9和2+8这种情况）