11.应用层数据传输格式/端口号-bite

设计应用层协议,主要就是包含两个工作:明确传输的信息及明确数据的组织格式(参考现有模板:xml,json,protobuffer)

正是因为这里的应用层协议,可以随心所欲的来指定,这就导致两极分化非常严重!!
大佬设计的协议都非常好.
菜鸡设计的协议就非常糟糕
正因为如此,大佬们发明了一些比较好的协议的模板,可以让我们直接往上套:
当下比较流行的一些这种协议的模板(数据的组织格式)

可读性好,但是运行效率不高:
1.xml
2. json
3. 可读性不好，运行效率很高:
4. protobuffer

1.xml:
格式有标签名构成:<标签名>内容</标签名>
<标签名>:开始标签
</标签名>:结束标签

标签名就是key
内容就是value

提高了可读性:但引入了太多辅助信息,占用网络带宽更高了

因此, xml现在很少作为应用层协议的设计模板了,现在使用xml主要是作为一些配置文件.

2.json
通过{}构成了键值对结构.一个{(}中有很多个键值对.键值对之间使用逗号分割.键和值之间使用冒号分割.要求键必须是字符串类型的值允许很多种(数字,字符串,布尔,数组,另一个json…)
{
键: 值,
键: 值,
…
}

json要求key一定是字符串,因此 key这里的引号可以省略除非key中包含了一些特殊符号(比如像空格,或者- …)必须要加上引号

json 中表示字符串,单引号或者双引号都可以(类似于SQL)

最后一个键值对,后面可以有逗号,也可以没有.(标准要求是没有的,但是一般的json解析器,都不会在意这个细节)

相比于xml, json同样能保证可读性同时又没有xml那么繁琐(占用的带宽要更少一点)

但是,当表示一个更加复杂的数据,比如数组的时候此时这里的很多key 就会重复出现N次,也就占用了更多的额外带宽

3.protobuffer:
是一种二进制格式的数据:

在protobuffer的数据中,不再包含上面key 的名字了.而是通过顺序以及一些特殊符号,来区分每个字段的含义

同时再通过一个IDL文件来描述这个数据格式(每个部分是啥意思), IDL只是起到一个辅助开发的效果,并不会真正的进行传输.传输的只是二进制的纯粹的数据

这是一个简化的表示版本:
1\3\3蛋炒饭\210\21\210\3炒面\28\2\1\28通过二进制的数据重新对这里的内容进行编排,甚至可能还会进行一些数据压缩.

这样做传输效率会更高,但是也会让这个数据肉眼难以观察,调试起来就不方便了.

总结:
json的应用范围要比 protobuffer 更广开
发效率>运行效率

如果线上环境出问题
如果是用json,出问题的请求和响应，一目了然,如果是用protobuffer，二进制的数据,没法肉眼看,就得自己开发一个专门的程序来解析这个数据,分析这里的问题

最知名的应用层协议:HTTP

端口号

0-65535之间的整数

知名端口号:把0-1024这些端口号,给划分出了一些具体的作用,很多网络服务是属于非常常用,非常广泛的服务为了更好的管理就给这些服务分配一些专门的端口号,并不是强制要求,而只是建议:

80 http服务器
443 https服务器
22 ssh
23 ftp
…