大家好 , 这篇文章给大家介绍网络协议中的应用层协议 , 在五层协议分层中 , 应用层协议相对来说还算是比较简单 , 各位准备好 , 我们要发车了~

推荐大家跳转到此链接查看文章

上一篇文章的链接也给大家贴在这里了

文章专栏在此

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

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

一 . 应用层协议

咱们自己编写的应用程序 , 就是在应用层 , 这也是我们实际开发中最常打交道的

虽然应用层里面有一些现成的协议 , 但是咱们在工作中少不了一个重要的事情 : 自定义应用层协议

自定义应用层协议并不复杂 , 协议就是约定 , 就是约定好客户端和服务器按照啥样的格式来传输数据

比如 :

领导安排任务 , 让你跟进某需求的开发 需求评审 : 程序员    
    
    
、产品经理    


     


     


 、测试




 




 




 、运维 …聚集在一起来开个会 , 针对用户需求大家研究一下靠不靠谱以及好不好实现

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

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

这个时间点特别关键 . 你承诺的时间点 , 就一定要能够兑现 . 务必要在约定好的时间点之前 , 开发完成

开发不完的话 , 后果非常严重 . 一次没有完成 , 这一年的年终奖 , 以及升职加薪的机会都凉凉 . 需求涉及到多个组协同工作 , 尤其是前后端协同开发的时候 , 就需要约定好 前后端/多个模块 之间的交互接口

比如 A B 两个组协同开发 , A 要给 B 传输哪些数据 , 数据按照什么格式来组织 ; B 给 A 回复哪些数据 , 数据按照啥样的格式来组织

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

应用层协议该如何进行约定呢 ?

我们之前写过的回显服务器 , 其实已经隐含了约定了

约定了 : 每个请求都是以换行为结尾的 , 每个响应也是以换行结尾的

只不过这种约定非常简单

自定义应用层协议

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

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

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

交互中涉及哪些信息的传递 , 和需求密切相关

举个栗子 : 点外卖

启动程序 , 就涉及到网络交互

请求 : 用户信息(喜欢吃啥   

   

   

、地址…)     

     

     

、位置信息(附近的店铺信息)

响应 : 商家的信息(商家名称




  




  




  、商家评分
  


  


  

、商家位置     
     
     
、商家预览图)

点击某个商家 , 也涉及到网络交互

请求 : 用户信息 




   




   




  、点击的商家信息

响应 : 该商家的详细情况 (菜品

 



 



 

、价钱               、评价  




    




    




  、销量…) 考虑清楚 , 这些信息的组织格式

约定好格式 , 代码才好写

比如上面的例子 :

获取商家列表 , 约定的数据的组织格式 :

请求 : 用户 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    
    
    
、内存等要贵很多

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