Java Web 实战 16 - 计算机网络之应用层协议

深碍√TFBOYSˉ_ 2024-03-25 23:04 69阅读 0赞

#### 文章目录 ####

*  一 . 应用层协议
 *   *  自定义应用层协议
     *   *  方式一 : 通过简单的分隔符来对不同部分的信息做区分
         *  方式二 : 使用固定长度来区分从哪里到哪里是一个信息
         *  方式三 : 方式一 + 方式二
         *  方式四 : 通过 XML 的格式来约定数据
         *  方式五 : 通过 JSON 的格式来约定数据
         *  方式六 : 使用 "二进制" 组织数据格式

> 大家好 , 这篇文章给大家介绍网络协议中的应用层协议 , 在五层协议分层中 , 应用层协议相对来说还算是比较简单 , 各位准备好 , 我们要发车了~  
> 推荐大家跳转到[此链接][Link 1]查看文章  
> [上一篇文章][Link 2]的链接也给大家贴在这里了  
> [文章专栏][Link 3]在此  
> ![在这里插入图片描述][56f5ad88174a4d62b03995e5db51a010.png]

我们之前学习过 TCP/IP 五层协议栈

1.  应用层 : 自己的应用程序
2.  传输层 : 关注起点和终点
3.  网络层 : 关注两个点之间的路径规划
4.  数据链路层 : 两个相邻节点之间的传输
5.  物理层 : 网络传输的基础设施

## 一 . 应用层协议 ##

咱们自己编写的应用程序 , 就是在应用层 , 这也是我们实际开发中最常打交道的  
虽然应用层里面有一些现成的协议 , 但是咱们在工作中少不了一个重要的事情 : 自定义应用层协议  
自定义应用层协议并不复杂 , 协议就是约定 , 就是约定好客户端和服务器按照啥样的格式来传输数据

比如 :  
领导安排任务 , 让你跟进某需求的开发

1.  需求评审 : 程序员、产品经理、测试、运维 …聚集在一起来开个会 , 针对用户需求大家研究一下靠不靠谱以及好不好实现

(因为产品经理不懂技术 , 可能就会提出一些令人迷惑的需求 , 所以大家需要将产品经理领到正路上)

1.  反馈排期 : 需要给出一个时间点 , 大概啥时候能搞定. (根据这个需求的工作量 , 和你手头其他的工作量 , 综合评估)

这个时间点特别关键 . 你承诺的时间点 , 就一定要能够兑现 . 务必要在约定好的时间点之前 , 开发完成  
开发不完的话 , 后果非常严重 . 一次没有完成 , 这一年的年终奖 , 以及升职加薪的机会都凉凉 .

1.  需求涉及到多个组协同工作 , 尤其是前后端协同开发的时候 , 就需要约定好 前后端/多个模块 之间的交互接口

比如 A B 两个组协同开发 , A 要给 B 传输哪些数据 , 数据按照什么格式来组织 ; B 给 A 回复哪些数据 , 数据按照啥样的格式来组织  
这个过程 , 就是在自定义协议 (应用层协议)

1.  写代码
2.  提测 : 交给测试人员进行测试
3.  联调 : 多个功能模块放到一起来进行验证 . 其中 , 就需要用到上面的自定义协议来看大家实现的功能是否有误 , 接口返回信息是否出现偏差
4.  发布 / 上线 : 把程序部署到生产环境上 , 程序就可以被外面的用户访问到了
5.  产品经理统计发布后的项目效果. (有没有提升,具体提升多少.……) , 然后得出项目效果报告 , 就会出现在老板的桌子上

应用层协议该如何进行约定呢 ?  
我们之前写过的回显服务器 , 其实已经隐含了约定了  
约定了 : 每个请求都是以换行为结尾的 , 每个响应也是以换行结尾的  
只不过这种约定非常简单

### 自定义应用层协议 ###

#### 方式一 : 通过简单的分隔符来对不同部分的信息做区分 ####

自定义应用层协议需要从两个角度入手 :

1.  考虑清楚 , 交互过程中要传递的信息有哪些

交互中涉及哪些信息的传递 , 和需求密切相关  
举个栗子 : 点外卖  
启动程序 , 就涉及到网络交互  
请求 : 用户信息(喜欢吃啥、地址…)、位置信息(附近的店铺信息)  
响应 : 商家的信息(商家名称、商家评分、商家位置、商家预览图)

点击某个商家 , 也涉及到网络交互  
请求 : 用户信息、点击的商家信息  
响应 : 该商家的详细情况 (菜品、价钱、评价、销量…)

1.  考虑清楚 , 这些信息的组织格式

约定好格式 , 代码才好写

比如上面的例子 :  
获取商家列表 , 约定的数据的组织格式 :  
请求 : 用户 ID ; 位置坐标  
响应 :  
商家1id ; 商家1名称 ; 商家1评分 ; 商家1位置  
商家2id ; 商家2名称 ; 商家2评分 ; 商家2位置  
商家3id ; 商家3名称 ; 商家3评分 ; 商家3位置  
这就是一种典型的约定方式 , 直接使用简单分隔符来对不同部分的信息做区分  
使用 ; 或者 \\n 都是可以灵活的替换成其他符号的

#### 方式二 : 使用固定长度来区分从哪里到哪里是一个信息 ####

![image.png][]

#### 方式三 : 方式一 + 方式二 ####

上述的两种风格,还可以混搭.  
有些字段使用固定长度 , 有些字段使用分割符

--------------------

上述格式 , 都比较的简单粗暴 , 除此之外 , 还有一些业界更通用的数据约定的格式 , 但是格式就要更复杂一些了

#### 方式四 : 通过 XML 的格式来约定数据 ####

<request>
      <userId>
        10
      </userId>
      <position>东京xxx,北纬xxx</position>
    </request>
    
    
    <response>
      <shops>
        <shop>
          <id>100</id>
          <nane>xxx</name>
          <rank>4.7</rank>
          <img>xxx.png</img>
        </shop>
    
        <shop>
          <id>100</id>
          <nane>xxx</name>
          <rank>4.7</rank>
          <img>xxx.png</img>
        </shop>
      </shops>
    </response>

xml 的格式和 html 确实是非常像的 ! 都是通过标签这样的结构来组织数据的  
形如 这样的就是标签 , 标签一般都是成对出现的 , 表达了"树形结构"(多级嵌套)  
就是开始标签 , 就是结束标签 , 我们可以在开始标签、结束标签之间添加数据

xml 用途非常广泛 , 很多地方都会用到 . 不仅仅是网络传输的时候用来组织数据 , 用来自定义协议格式 , 同时也可以作为一些配置文件.

#### 方式五 : 通过 JSON 的格式来约定数据 ####

请求:
    {
        
      userId:10,
      position:"xxx"
    }
    
    响应:
    {
        
      shops:[
        {
        
          id:1,
          rank:4.7,
          position:"xxxx",
          img:"xxxx"
    		},
      	{
        
          id:1,
          rank:4.7,
          position:"xxxx",
          img:"xxxx"
    		},
      ]
    }

使用 \{\} 包含一些键值对 , 键值对之间使用逗号分割 , 每个键值对的键和值之间 , 使用冒号分割  
JSON 要求键的部分必须是字符串  
而值的部分 , 可以是数字 , 可以是字符串 , 还可以是数组(`[]`) , 还可以是另一个 JSON

JSON 是当下用来自定义协议的时候 , 非常常用的格式  
也有很多第三方库 , 可以操作 JSON 数据

#### 方式六 : 使用 “二进制” 组织数据格式 ####

还有一些其他的 “二进制” 数据组织格式 . 比如 : protobuffer、thrift 等

像 XML 和 JSON 都是属于文本格式 , 优势是可读性高 , 劣势就是效率低 , 占用的带宽更多  
protobuffer 和 thrift 都属于二进制的格式 , 格式上就要更加的复杂 . 优势就是效率高 , 占用带宽低 . 劣势就是可读性差

> 带宽其实很关键 , 在国内相比于 CPU、内存、硬盘相比 , 带宽是更贵的硬件成本 .  
> (家庭用的带宽和服务器用的带宽是不同的概念)  
> 如果要升级服务器的带宽 , 花的钱要比 CPU、内存等要贵很多

咱们应用层协议中的数据格式 , 有很多可以参考的方式 , 在实际开发中 , 就要根据实际的情况来决定使用哪种更适合

[Link 1]: https://www.yuque.com/jialebihaitao/study/quamqwbr9hkdm7fm?singleDoc#%20%E3%80%8A6.%20%E7%BD%91%E7%BB%9C%E7%BC%96%E7%A8%8B%E5%A5%97%E6%8E%A5%E5%AD%97%E3%80%8B
[Link 2]: https://blog.csdn.net/m0_53117341/article/details/129680638
[Link 3]: https://blog.csdn.net/m0_53117341/category_12186238.html?spm=1001.2014.3001.5482
[56f5ad88174a4d62b03995e5db51a010.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/5aaa1dc26584434ba370a6dbfccce32d.png
[image.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/67ee709b3ea941d58e36b8650fa37d35.png