JavaEE中的网络原理 Ⅰ-- 应用层

---

网络原理

以下TCP/IP协议中每一层里面的核心内容~

• 应用层
• 传输层
• 网络层
• 数据链路层
• 物理层

本篇介绍一部分网络原理中应用层的内容:

应用层

应用层和应用程序密切相关~
不同的应用程序,里面可能会涉及到不同的应用层协议~
开发代码的时候相当一部分工作量,就是在自定义应用层协议~

❓如何进行自定义?

1. 考虑要在客户端和服务器之间传输哪些信息[需求]
2. 考虑信息/数据按照什么格式组织[需求]

🎠举个例子: 点外卖

点外卖的典型场景:展示商家列表

针对这个场景,如何去自定义协议呢?

1. 明确传输的信息 (请求里有啥,响应里有啥)
   请求里有:用户的位置,用户的偏好(特殊要求)
   响应里有:商家列表,要包含多个商家信息,每个商家包含 商家的名称,图片,评分,距离
2. 明确数据的格式
   网络上传输的本质上都是bit流(二进制位),也可以把这些数据视为"字符串"
   以下给出一个典型例子:

请求:
经度,维度;偏好面条,麻辣烫,岐山臊子面,炸酱面;
请求中有两部分,位置信息和偏好信息,之间使用;来分割
位置信息和偏好信息内部的各个部分使用 ,来分割

---

响应:
魏家凉皮,图片,5星,1km
张良麻辣烫,图片,4星,1.5km
铁锅炖,图片,4星,2km
面片馆,图片,3星,1.8km
响应中包含多个商家信息,每个商家占一行,每行里面多个属性 使用 , 来分割
上述的数据传输格式,可以随心所欲地进行约定!!
不同的应用程序,里面约定的个数都不一定相同,只有你成为了对应产品的程序员,你才能知道他这个格式是怎么弄的~

回显程序,其实也是需要自定义应用层协议的~
只不过当时定义的非常简单~
前面定义的 请求 是一个字符串,以 \n 结尾
响应也是一个字符串,以 \n 结尾

自定义应用层协议

自定义应用层协议,尤其是这个数据格式的定义,太灵活了,未必是好事~

如果程序员A约定了一种格式
程序员B又约定了另一种格式
A和B相互看对方的代码,都会觉得很别扭~

因此,大佬们也给我们事先发明了一些特定的数据数据格式~ ~ 基于这些常用的格式来传输数据,就可以更通用,也更方便~

1. HTTP 应用层中最最重要,最最常用的协议(暂时先不展开,后续单独写博客介绍)
2. XML

比较典型的数据组织格式,经典古老的格式~
现在用的没那么多了,但是也还是会经常接触到~
格式非常有特点,是通过 “标签” 的形式来组织 键值对 数据的

---

例如 :商家列表功能

标签名字就是key,标签里的内容就是value 请求

HTML也是标签化的格式~
但是最本质的区别,xml这里的标签名字是自定义的 html这里的标签名字都是约定
好的

---

XML缺点:

1. 丑
2. 数据多了编写复杂
3. 这些数据要通过网络传输,消耗网络带宽~ 由于这里包含了大量的标签,就导致网络贷款占用的更高了~

3. JSON :
   当前最流行的一种数据组织格式,相当于XML的替代品

JSON首先是一个{ },{ } 里面包含多组键值对,键值对之间使用 , 来分割
键和值之间使用 ; 分隔

键只能是字符串类型(例如 position)
值可以是字符串,数字,数组(比如上面的{}就是数组),json

---

JSON 优点:

1. 可读性非常好
2. 看起来美观整洁
3. 扩展性强

---

JSON缺点:

引入额外的字符串,传输数据量变大了,消耗更多的带宽~

4. 刚才说的 xml 和 json 都是属于带宽占用较高,效率较低的格式,也存在一些格式,能够更高效的组织数据~
   这类的格式有很多,其中最典型的叫 protobuffer (谷歌搞的)
   protobuffer既是一个数据格式,同时也是一个库,来操作这种格式的数据~
   这个东西是一个二进制的格式,不太方便研究这里具体是怎么组织的,但是这种格式下,组织出来的数据占用空间比 json 和 xml 都要少 , 传输效率有明显的提升!
   但是二进制格式不方便人肉眼观察,于都和调试都比较复杂~
   这个东西适合于运行效率要求比较高的场景来使用~

总结

你可以叫我哒哒呀 本篇到此结束 “莫愁千里路，自有到来风。” 我们顶峰相见！