【TCP/IP】自定义应用层协议，常见端口号

互联网中，主流的是 TCP/IP 五层协议

5G/4G 上网，是有自己的协议栈，要比 TCP/IP 更复杂（能够把 TCP/IP 的一部分内容给包含进去了）

应用层

可以代表我们所编写的应用程序，只要应用程序里面用到了网络通信，就可以认为这个代码就是属于应用层的代码

日常开发中最常用到的一层：

使用大佬们已经创建好的应用层协议
- 应用层知名的协议有很多，其中的佼佼者就是 HTTP
自己定义应用层协议
- 另外四层都是操作系统/硬件/驱动已经实现好了的，我们不可能“自定义”，只能使用人家的

协议就是约定

按照自己的规则，约定通讯方式——>自定义应用层协议

自定义应用层协议

自定义应用层协议，具体要做什么事情：

明确要传递的信息

明确前后端交货过程中，要传递哪些信息

举个例子：开发一个外卖软件，打开软件后，首先需要展示一个“商家列表”
此处就需要先确定传递的信息是什么

请求：用户是谁（用户的 ID），用户所处的位置
响应：商家列表，包含多个商家，每个商家信息中，又有商家的名字、图片、距离、评分

这里的信息如何确定，都是根据当前的需求来产生的

明确组织信息的格式

明确组织这些信息的格式
针对信息组织格式，也有很多种方式，使用哪种方方式都可以，只要确定前段和后端是同一种方式就可以了

举个例子：使用行文本的方式来组织上述数据

请求：用户id,用户位置\n
响应：商家的id,商家名称,商家的图片地址,商家的距离,商家的评分\n

关于组织数据的格式，还有一些说法，上述“行文本”简单粗暴的方案，在实际开发中，很少会这样做

XML 方案

Maven 中就会见到，通过“成对的标签”表示“键值对”信息

<request><userid>1001</userid><postion>E45N60</postion>
</request>

可以通过 XML 来传输网络数据，也可以作为程序的配置文件
不过 XML 进行网络传输的时候，又有一个明显的缺点——会消耗大量的带宽
- 网络通信中，带宽是一个非常贵的硬件设备
- 在传输标签的时候，都得传输成对的标签，传入的信息更多
所以现在 XMl 一般都是在配置文件，不进行网络传输了
XMl 里面的标签（键值对）都是程序员固定的，而 HTMl 里面的标签都是固定的（已经有一套标准，约定好哪些标签是合法标签，这些标签都是什么含义）

JSON 方案

当前主流的网络通信的数据格式，相比 xml 来说，可读性是很好的，同时能节省一定的带宽

{"userid":1001,"postion":""E45N60"
}

JSON 也是“键值对”格式，
- 键和值之间用 : 分割
- 键值对之间用 , 分割
- 所有的键值对，都使用 {} 括起来
这里的标签都只有一份，不需要结束标签了，节省了传递开销

YML（YAML）方案

强制要求了数据组织的格式，强制要求写成“可读性非常高”的格式

键值对必须独占一行
“嵌套”结构必须通过缩进来表示

protobuffer方案

前三个方案，都是关注可读性，而 protobuffer 关注性能，牺牲了可读性（通过二进制的方式组织数据）

protobuffer 直接通过“位置”约定字段的含义，不需要传输 key 的名字，也会针对传输的数值，进行二进制的编码，起到一些“压缩”的效果
极大地缩减了要传输的数据的体积——>带宽消耗就越小——>效率越高
但二进制数据无法肉眼阅读，调试相关程序的时候，就会比较麻烦

常见端口号

端口号是一个整数，用来区分不同的进程。

同一时刻，同一个机器上，同一个协议，一个端口号只能被一个进绑定
一个进程可以绑定多个端口号
端口号是通过两个字节的无符号整数表示的，取值范围 0~65535，但实际上 0 比较特殊，一般不会使用
- 1~1023 属于已经被预定好的（有一些知名的服务器，已经提前预定了这个端口），这样的端口称为“知名端口号”（其实里面的大部分服务器已经不再使用了，在 80、90 年代是知名的）
- 我们日常开发的时候，会避开这些端口

业务端口和管理端口

什么时候会涉及到一个进程（服务器）绑定多个端口？

编写服务器，肯定需要先绑定至少一个端口号，和客户端进行交互（称为“业务端口”）
服务器运行过程中，希望能够对这个服务器的行为，进行一些“控制”
- 比如让服务器重新加载某个数据/某个配置/修改服务器的某个功能
- 也可以通过网络通信完成上述功能
- 就可以让服务器绑定另一个端口，通过这个端口，编写一个客户端，给服务器发送一些“控制类“请求
- 上面的“另一个端口”就是“管理端口“

调试端口

当需要针对服务器运行状态进行检测和调试，需要查看服务器运行中某个关键变量的数值的时候，千万不能用调试器来进行调试，一旦使用调试器调试这个服务，就会使服务器的一些线程被阻塞住，无法给客户端正确提供服务了

虽然可以通过日志进行打印，但是不方便，需要修改代码并重启服务器
可以让服务器绑定另一个端口，然后实现一些相关的打印关键变量的逻辑，客户端发送对应的调试请求
这里的“另一个端口”就是“调试端口”

长连接和短连接

长连接

客户端连上服务器之后，一个连接中，会发起多次请求，接收多个响应

一个连接到底进行多少次请求是不确定的，Echo Client 就是这种模式

短连接

客户端连上服务器之后，一个连接只发一个请求，然后就断开连接了

UDP 协议报头

学习一个网络协议，主要就是学习“数据格式”/“报文格式”

源端口/目的端口

端口号是属于传输层的概念
UDP 报头使用两个自己的长度来表示端口号
之所以端口号的范围是 0~65535，是因为底层网络协议做出了强制要求
如果使用一个 10 w 这样的端口，就会在系统底层被“截断”

UDP 并不关心后面的正文里面是什么数据，只需要关心报头里面是怎么组织的
报头里面分为四个部分，每个部分固定是两个字节（16 bit），里面没有分隔符，就是通过固定长度来进行区分的

网络通信中，涉及到四个关键信息：源 IP/目的 IP，源端口/目的端口

源端口：发出数据报那个程序使用的端口号——>发件人电话
目的端口：接受这个数据报的程序使用的端口号——>收件人电话
源 IP：发出数据报那个程序的 IP——>发件人地址
目的 IP：接受这个数据报的程序的 IP——>收件人地址

UDP报文长度

UDP报文长度：报头长度 + 载荷长度

长度单位是字节，
比如，报文长度 1024,——>整个 UDP 数据报就是 1024 字节；由于是两个字节来表示这个长度，所以最大值 65535——64 KB（65536/1024）
64 KB 放在今天，是个很小的数字，所以如果使用 UDP 协议传输一个很大的数据，就会变得很麻烦

UDP 用了好多年，一直挺好用，但随着业务的发展，广告越来越多，越来越复杂，导致一个网络响应数据报的体积越来越大，逐渐逼近 64 KB。一旦数据超过了 64 KB，就可能到值数据被截断，这样广告可能就无法正常显示了。对于这样的情况，有两个解决方案：

把一个大的数据报，拆分成多个，分别进行传输
- 很快就被否决了；因为实现分包、组包的过程非常复杂，充满了不确定性
直接使用 TCP
- TCP 对于长度没有限制，其自身也带有可靠传输这样的机制，对于整体的通信质量来说也是有利的
- 代码的修改成本比较低

校验和

前提：网络传输过程中，非常容易出现错误

电信号/光信号/电磁波——>收到环境的干扰，使里面传输的信号发生改变

校验和存在的目的，就是为了能够“发现”或者“纠正”这里的错误。就可以给传输的数据中，引入“额外信息”，用来发现/纠正传输数据的错误

这里的额外信息就是 checksum
如果只是发现错误，需要携带的额外信息，就可以少一些（发现就会丢弃掉，不会让对方重发）
如果是想要纠正错误，携带的额外信息就要更多（消耗更多带宽）

举个例子：你妈让你去买菜，西红柿、鸡蛋、茄子、晃过，最后补充一句“一共四样”

这里的“一共四样”起到的作用就相当于是“校验和”。通过“一共四样”你可以对手里的菜进行检查，有没有买多、买少

但这样的“校验和”并不能准确的识别出问题，而且容易误判。所以我们希望校验和可以更严格地检查数据的内容，可以结合内容/内容的片段来生成校验和

比如你在默写金庸先生的十五部作品的名称，写完后，你可以通过“飞雪连天射白鹿，笑书神侠倚碧鸳”这一幅对联和你写的书名的第一个字对一下，若能对象，就说名此处的名字都是正确的
这样的校验和就是基于内容来进行校验的

虽然出错的数据恰好没有被校验出来，这可情况也是可能会发生的
但是一个良好的校验和算法，可以让上述问题发生的可能性非常低

CRC 校验和（循环冗余校验）

把 UDP 数据报整个数据都进行遍历，分别取出每个字节，往一个两个字节的变量上进行累加

由于整个数据可能会很多，所以加着加着可能就结果溢出了，但溢出也没关系
我们重点关心的不是最终加和是多少，而是校验和结果是否会在传输中发生改变

例如：我们去传输一个 UDP 数据报

发送方整合整个 UDP 数据，基于这些数据，计算得到一个 checksum1
接收方收到的数据：
数据的内容
校验和 checksum1

接收方就可以根据数据的内容，按照同样的算法，再算一遍校验和，得到 checksum2

如果传输的数据在网络通信过程中，没有发生任何改变，则一定有 checksum1 == checksum2