文章目录

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

大家好 , 这篇文章给大家介绍网络协议中的应用层协议 , 在五层协议分层中 , 应用层协议相对来说还算是比较简单 , 各位准备好 , 我们要发车了~
推荐大家跳转到此链接查看文章
上一篇文章的链接也给大家贴在这里了
文章专栏在此

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

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

一 . 应用层协议

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

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

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

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

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

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

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

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

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

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

自定义应用层协议

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

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

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

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

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

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

约定好格式 , 代码才好写

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

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

方式三 : 方式一 + 方式二

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

---

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

方式四 : 通过 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、内存等要贵很多

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