网络原理（五）—— UDP协议

UDP协议

在前面介绍的网络初始中，我们对于网络有了一个直观大体的认识与了解。
再到后来的网络编程中，让我们真正的通过敲写代码感受到了通信程序是什么样的。
在接下来的网络原理介绍中，我们将要进一步的理解网络是如何进行工作的！这里将主要以理论为主，也会有很多比较抽象难以理解的内容，同时这里也包含着大量的面试题。性质和多线程是类似的，都是比较重要的考点，工作中也是比较经常会用到的东西，所以应当加以牢记！！！

接下来我们将要按照网络协议这几个层次来展开讲解:

应用层

此处这里，咱们只是先简单地介绍，后面也会有一个专门地章节，“ HTTP 协议”，这是应用层地代表协议。
前面也说过，由于应用层是和代码直接相关地一层，所以应用层实际上是跟我们程序员打交道最频繁地一层，应用层，决定了数据要传输什么，拿到数据之后应该如何去使用的作用。虽然应用层这里已经存在了一些现有的协议（像 HTTP），但是也有很多情况是需要我们程序员自己去制定一组协议规则的，这就是：自定制协议。

这个自定制协议也没有大家想象的那么难，其实也是一件非常 easy 的事情！比如说下面这个栗子：

在这里，我们所约定的应用层数据报，数据格式，就是在自定义协议~当然了，上面这个栗子仅仅是为了能够说明自定制协议是怎么一回事儿，不能说明QQ 发送消息的时候，协议就是这样约定的，实际上人家 QQ 所采取的数据报是比这个栗子要更加复杂的！

那么，如何来自己制定并且来约定一个协议呢？（给大家举一个外卖程序的栗子，外卖程序有一个核心功能就是可以加载商家列表）
第1步：确定要传输哪些信息。（这个是跟产品需求走的）

以上给出的这些信息，都是根据产品需求来确定的，来自产品经理这个人。

第2步：确定数据是按照啥样的格式来组织的。（自己随意约定）
在网络上传输的，本质上都是 0101 这样的二进制位，也可视为是二进制的字符串~
我们需要把上述这些信息整合成一个字符串才行。

只要发送方能够按照这套格式来组织数据的话，然后接收方也能够按照这套格式来解析数据，俩者能对得上号，这样的格式就是可行的！

XML 格式
另外，在实际的开发中，有一些现成的格式是直接可以拿来使用的！
一种典型的格式 “xml” ，这种 xml 格式之前是非常流行的格式，但是现在用得比较少了，但是也还是经常能够遇到的， xml 是通过标签的形式来组织的。
请求：

100
100 - 100

xml 中包含了很多 标签。

问题：有些人觉得 xml 和 HTML 长得很像，它们俩到底有什么区别？
答: HTML 可以视为是 xml 的一种特殊情况。HTML 中的标签有哪些标签，标签的含义是什么，都是人家有一个标准委员会，这些大佬们约定的，咱们只能去遵守。而反观，xml 中的标签则是用户自己定义的！每个标签的名字也都是你乐意叫啥就叫啥。
韦恩图可描述为：

json 格式
另外还有一种非常流行的格式，json（xml 用得少了，主要也就是因为 json 火了）
{
userId: 100,
userPost: 100 - 100
}

json 是使用 { } 作为标识。{ } 里面是若干个键值对。
每个键值对之间是使用 逗号“,” 来分割
每个键和值之间是使用 冒号 : 来分割
“ 键 ” 必须是字符串，“ 值 ” 可以是数字，字符串，数组，也可以是另一个 json …

实际上数据组织的方式是有无数种的，只不过我们比较常见的是 xml 和 json 这俩种的。

传输层

传输层这里有俩个非常非常重要的协议，一个是 UDP协议，另一个是 TCP协议。

在学习一个协议的时候，其中一个最最重要的环节就是去认识协议报文格式，也就是弄明白协议是具体如何怎么组织的这个数据的。

UDP协议

UDP协议端格式

上图基本上是所有的计算机网络的教材都是这么画的这个图，但事实上这个图其实并不准确！！

真实的结构如下图：
源 ip，源端口 表示了数据从哪里来；目的 ip，目的端口 表示了数据到哪里去。

我们从 UDP协议 所规定的报文格式可以知道每个端口号 在 UDP报文里面，占两个字节，那么其实端口号的取值范围也就是 0 -> 65535（2^16 - 1)。
其中，< 1024 的端口，也称为 “知名端口号”，这是给一些名气比较大的服务器预留的端口。这部分端口咱们普通程序员在写代码的时候不应该使用，就是 VIP 端口（1-1023 的端口号才是 vip 席位，0 虽然是合法的端口但实际上并没有人去使用），也就是坐飞机的头等舱。这部分端口其实用了也没事儿，可能也就是需要你有管理员权限才能够去使用！

有一些很牛逼的服务器/应用程序是会有专属的 VIP 座位/席位，如 http服务器 有一个专属座位是 80，ssh 专属座位是 22 ，ftp 专属座位是 21。

另外需要注意的是，某个端口号如果已经被使用/占用了，那么就会发生冲突！！！

报文长度

这里的报文长度，是 2 个字节，所能表示的范围是 0 -> 65535 => 64KB，所以就能够得出一个 UDP 报文的最大长度就是，64KB！！！所以使用 UDP 编程的时候，一定要注意 UDP 数据报不能太长了，否则会出现问题。

问题1：请问这 64KB 是大呢，还是小？
放到当年的话，64KB 还算挺大的。但是放到现在，可能随便发一个表情包都不止这个大小了。
问题2：既然这么小，那为啥不把 UDP 报文扩一下呢？
答：为啥不扩展一下？这其实是一个政治性的问题，根本不是技术问题！
UDP 是在操作系统的内核中实现的，要想扩展 UDP 的话，就得升级系统~（这是其一）
另外，A 主机使用新的升级后的 UDP 的系统（假设长度增加了，长度为 4 字节）
B 主机使用旧的升级前的 UDP 的系统（长度依旧是 2 字节）
请问 AＢ能否使用 UDP 通信？？不能的！！！要想进行通信的话，就要升只能 AB 都升级！！
这样也就带来了第二个麻烦，那就是全世界的主机都得一起升级！（这是其二）
全世界的主机是用相同的操作系统嘛？？？不是的！有的是 Windows 系统，有的是 Linux 系统，有的是 Mac系统，因此这就非常得尴尬，不能一齐去升级。像 Steam 就做得非常好，它就要求你要想玩游戏就得必须强制先要升级系统~
也因此，这个问题得解决方案是无解的，想要扩展 UDP 长度没有那么容易，UDP 升级也是不可能升的，只能就先凑合着去用吧！
问题3：那万一要是真的需要传输一个比较大的数据，那该怎么办呢？
答：俩种思路。
第一种：可以把一个大的数据拆分成许多个部分，使用多个 UDP 数据报来传输~这套方案虽然可行，但是也比较复杂。
第二种：直接就放弃不用 UDP 了，使用 TCP ，因为 TCP 没有限制。

校验和
网络传输，其实并非那么稳定可靠，因为很有可能就会出 幺蛾子。原因也很简单，那就是你通过网线进行传输，网线上传的是电信号，而电信号就是使用高低电平来 表示 0 1 二进制位的，如果一旦外部的环境发生变化，受到强磁场之类的干扰，就很有可能会导致网线上的 高电平 -> 低电平 或 低电平 -> 高电平（比特翻转），所以就会出现数据传输出错了。

UDP 校验和 存在的意义就是为了用来判定一下当前传输的数据是否是出错了。

举个栗子🌰：比方说有一天你的家长叫你去超市买上四样菜回来，分别是 西红柿，鸡蛋，茄子，芹菜。当我看到我手里的菜是 3样 或者 5样的时候，那说明 100% 是买错了的！当我要是看到我手里的菜是 4样的时候，可以推断可能是对的，也可能是错误的！
这样以来，也就是说如果校验和不对，那么此时你的数据就 100% 一定是不对的！如果校验和是对的，但是数据也有一定概率是错误的！

大佬们为了让校验和能够识别率更高一些，计算的时候通常会以数据内容作为参数来进行计算。这样做的话，也就是说当数据内容发生变化的话，校验和也会发生变化~

校验和 往往都是取内容/内容的一部分，通过一些算术运算，数学公式变换，可以得到一个值。如果内容发生了改变的话，那么得到的校验和也就变了。比如我们在传输上述图片里的数据的时候，我就可以取 “飞雪开那天射白鹿，小鼠神侠倚碧鸳” 作为（带有内容的）校验和。

发送方，把载荷数据带入到校验和算法中，然后计算生成得到一个校验和的结果，设为 Sum1.

然后发送方就把这一整串数据发送给了接收方 ~
接收方收到的数据中，既有载荷，也有校验和 Sum1，因此接收方就可以把载荷按照同样的算法，再计算一遍校验和，得到了 Sum2 。
然后，接下来对比 Sum1 和 Sum2 是否是相同的！如果不相同，那么数据就一定百分百是出了问题的!!!

前提：

由这个逆否命题可以知道，如果校验和结果不一样，这时就可以视为传输出错了！！！

问题：那 Sum1作为数据报进行传输的时候不是也有可能会发生改变的嘛？这该怎么去判定呢
答：如果是 Sum1 变了，而内容却没有变，相当于是由相同的算法得到的校验和 Sum2 是 Sum1 变化前的值。但是此时 Sum1（变化后） 还是和 Sum2 （变化前）对不上了，仍然可以视为是传输错误。

校验和的实现算法，这个大家可以额外了解一下即可。UDP 这里使用的是 CRC 算法，这是一个简单粗暴的校验和算法。

总结：UDP 协议规定了 UDP 数据报是由 “报头” 和 “载荷” 组成的。其中载荷也就是一个完整的应用层数据报，报头是 UDP 的报头部分，包含了 4 个字段，且每个字段的大小是 2 个字节，它们分别是：16 位源端口号，16 位目的端口号，16位 UDP 长度，16位 UDP 校验和。这几个字段分别是什么含义需要重点去理解，尤其是这个长度以及长度所带来的问题（需要重点进行关注），这一点也会对我们使用 UDP 编程产生诸多的限制在里头。