目录

1. 应用层

2. 自定义协议

2.1 根据需求 => 明确传输信息

2.2 约定好信息组织的格式

2.2.1 行文本

2.2.2 xml 

2.2.3 json

2.2.4 protobuf

3. HTTP 协议

 3.1 特点

4. 抓包工具

---

1. 应用层

在前面的博客中, 我们了解了 TCP/IP 五层协议模型:

1. 应用层
2. 传输层
3. 网络层
4. 数据链路层
5. 物理层

在实际开发中, 和我们程序员打交道最多的就是应用层, 我们写的的代码, 只要涉及到网络通信, 就可以认为是应用层的一部分.

应用层和应用程序直接相关, 也和我们程序员直接相关.

在应用层涉及到的网络通信协议, 通常分为以下两部分:

1. 大佬已经约定好的, 现成的协议
2. 我们程序员自定义的协议(我们写代码时, 自己规定的协议)

2. 自定义协议

上文说到, 应用层中的很多协议都是我们程序员自己规定的, 而自定义协议, 有以下两个关键步骤:

1. 根据需求, 明确传输哪些信息
2. 约定好信息组织的格式

2.1 根据需求 => 明确传输信息

客户端和服务器的交互, 首先第一步肯定是要明确传输哪些信息(请求和响应的内容), 而这些信息都是需要根据需求来确定的.

举个例子:

比如我们打开美团点外卖, 就会展示出很多的商家, 而这些商家都是在我们附近, 不会距离我们很远. 并且推荐的店铺是根据我们的口味来推荐的, 而不是随机的推荐.

这是因为我们(客户端)和服务器之间交互时, 客户端发出的请求以及服务器返回的响应, 都是根据我们的需求来确定好的.

• 请求: 用户的位置信息(一般来说是经纬度), 用户id(明确用户是谁), ....
• 响应: 商家id, 商家名字, 商家图片, 评分, 配送费, 种类, .....

2.2 约定好信息组织的格式

在明确好传输的信息后, 接下来来到第二个环节: 约定好信息/数据组织的格式.

信息组织的格式有很多种:

1. 行文本方式
2. xml 方式
3. json
4. protobuf

2.2.1 行文本

以行文本的方式来组织信息, 一条信息占一行, 一行中分为很多列, 每一列都表示了一小段信息.

而一个请求/响应, 就是由很多个行(很多条信息)构成的.

还是以上文外卖为例, 若以行文本组织数据, 

那么协议中请求的规定可能如下:

• 用户id, 用户位置\n

响应的规定可能如下:

• 商家id, 商家名称, 商家logo, 商家照片, 评分, 配送费\n

那么在发送请求或者响应时, 信息的格式就需要遵循以上的约定.

(我这里 行与行之间使用 \n 分割, 列与列之间使用 , 分割. 因为是自定义协议, 所以只要客户端和服务器遵循的是同一套规则就可以了)

但是, 以行文本的形式来组织信息, 是比较老的一种方案(十几二十年前使用的).

2.2.2 xml 

我们还可以通过 xml 格式, 去约定请求和响应中数据的格式.

xml 和 html 类似, 都是由成对的标签构成的键值对结构, 但是不同的是:

1. html 的标签是固定的, 是大佬们制定好的, 供我们使用, 我们不能使用不存在的标签(不允许自定义标签)
2. xml 的标签是自定义的, 我们可以自己制定标签来使用

注意, xml 只是和 html 结构类似(都是以标签构成的), 但是若以 xml 来规定数据的格式, 这些数据只是用来网络传输的, 和浏览器的显示无关(html 是规定浏览器怎么显示的).

还是以上文外卖软件为例:

若以 xml 格式来约定信息的格式, 那我们作为客户段, 发送的请求的内容, 以及服务器端, 返回的响应的内容, 可能如下:

此外, xml 能够组织格式化数据, 这些数据不仅能用来网络传输, 还可以作为配置文件 .....

总之, xml 有很多的应用场景.

以 xml 来组织信息格式, 有优点也有缺点:

1. 优点: 可读性好(键值对形式, 易读)
2. 缺点: 冗余信息太多(成对的标签), 消耗了更多的网络带宽资源 

要知道, 带宽是最贵的资源:

1.  硬盘最便宜
2. 内存其次
3. cpu 小贵
4. 带宽 特别贵!!

以 xml 来约定数据格式的方案, 在十年前, 用的还是很多的, 但是在 2024.11.17 的今天, 已经很少使用 xml 进行网络传输了.....

2.2.3 json

json, 是当下最流行的网络数据组织格式的方案.

json 也是使用键值对来表示数据的, 格式如下:

json 保留的了 xml 的优点, 但也存在缺点:

1. 优点: 可读性高
2. 缺点: 依旧存在冗余信息, 消耗带宽(虽然相对于 xml 来说, 键的表示只有一个, 但是仍消耗了带宽)

2.2.4 protobuf

protobuf 方案, 约定的数据格式是二进制.

protobuf 使用二进制的格式, 对传输的数据进行压缩, 虽然这样一来, 没有了 xml / json 的冗余信息, 使得消耗的带宽最少, 但是也使得可读性变差.

1. 优点: 消耗的带宽最少(性能高)
2. 缺点: 可读性低

显而易见. protobuf 方案, 就是使用 开发效率换取执行效率(比较少见), 所以 protobuf 的方案, 更多的应用于对性能要求高的常见的下.

要知道, 在实际开发中, 开发效率(尽可能让代码好写)是要比执行效率重要的, 所以在平时开发中, 还是更建议使用 json 方案来约定数据格式.

到这里, 我们对上文提到的四种信息组织的格式进行一下小总结:

1. 行文本(最原始)
2. xml(比较原始, 冗余较多, 可读性高)
3. json(目前最流行, 冗余一般, 可读性高) => Java Web 开发的基本盘
4. protobuf(高性能场景下使用, 冗余最小, 可读性差)

---

3. HTTP 协议

在应用层中, 除了我们程序员自己制定的协议外, 还有很多大佬们搞好的现成的协议.

其中, HTTP 协议是应用层中最重要的一个协议, 也是 Web 开发中最核心的协议.

HTTP 协议诞生于 1991 年, 到目前为止已经有好几个版本的 HTTP 了, 但是目前最流行的 HTTP 版本依旧是二十年前的 HTTP 1.1 版本.

在本篇博客中, 也是围绕 HTTP 1.1 展开介绍.

 3.1 特点

HTTP 协议是 一问一答 模式的协议.

所谓一问一答, 就是客户端发起一个请求, 服务器就返回一个响应(请求和响应是一一对应的).

在网络统一中, 当然也存在其他的问答模式:

1. 多问一答: 上传大文件(上传时将一个大文件拆分为几个小文件分别上传, 上传成功后服务器返回一个响应)
2. 一问多大: 下载大文件(我们只需点一下下载, 而服务器会将大文件拆分为几个小文件, 分别传送给客户端进行下载)
3. 多问多答: 远程控制(ToDesk)

而像 浏览器打开网页, 手机 APP 加载数据这样的场景, 就是典型的一问一答的场景, 非常适合使用 HTTP.

4. 抓包工具

要学习 HTTP 的报文格式, 需要搭配一个重要的工具进行学习, 这个工具就是 --- 抓包工具.

抓包工具, 是一个软件, 能够获取到网络资源包, 将其中详细的格式都解析出来, 而我们就可以通过抓包工具来查看网络传输的信息.

简单来说, 就是我们电脑的上所有的网络通信, 都会先发送给这个抓包工具, 再由这个抓包工具把数据发送给客户端.

也就是说, 抓包工具能够洞察到我们的电脑和服务器间所进行的一切的通信内容, 而我们就可以通过抓包工具来查看这些内容.

抓包工具, 相当于 "代理", 分为正向代理和反向代理:

1. 正向代理: 代表客户端干活
2. 反向代理: 代表服务器干活

 举个例子:

汤老湿想吃辣条了, 但是老湿比较懒, 不想动, 于是他就命令小汤去超市帮他买辣条.

此时, 老湿和超市老板之间的交易, 小汤是非常清楚的. 所以, 小汤就是老湿的"代理" , 并且是"正向代理".

这个过程就如下图:

如果超市老板也很懒, 也让他的儿子替他看店, 自己进去躺会, 那么超市老板的儿子也是一个"代理", 并且是"反向代理":

注意:

在使用抓包工具时, 一定要关闭和抓包工具产生冲突的软件, 例如: 梯子/梯子类浏览器插件.

我这里使用 fiddler 来进行演示(fiddler 只能抓取 http, 功能简单, 使用方便, 但也够用)

通过抓包工具, 我们就可以获得请求和响应的原始数据:

对响应进行解压缩, 仔细观察, 返回的响应其实就是 HTML.

也就是说, 我们在浏览器上进行一系列操作, 会向服务器发送请求, 而服务器返回的响应, 就是一份 HTML, 这份 HTML 就构建了一个新的网页(满足我们访问需求的网页).

本篇博客对应用层和 http 协议的介绍就到这里, 后续博客详细来聊 http 的协议格式.(请求和响应在 http 中的格式)

---

END