网络数据传输格式的思考

Posted 2020-11-25 ymaster

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了网络数据传输格式的思考相关的知识，希望对你有一定的参考价值。

相信大部分的开发朋友现在日常中用到的基本都是数据传输格式基本都是 JSON 格式，其好处在于通用性且可读性强、易理解，相对于 javascript 来说 JSON 看上去感官上基本就是一个对象多加些引号罢了非常亲切。

但是实际生产中并不是每一中情况都需要我们提供高通用、高易读性的数据传输，例如我们在进行一些实时数据传输过程中往往速度才是真理，这种情况下我们可能就会觉得 json 的数据量是不是有点大？是不是可以减小点传输体积？结构和含义可以文档搞定啊。

还有场景就是加密传输，这种场景也是不能直接使用 JSON 文本的，通常就是将我们的数据经过加密算法处理后得到一个新的数据（通常是字符串，为什么是通常这里不做阐述），但是现在我们通常前后端加密通讯基本都是加密算法+JSON，通过对 JSON 进行加密处理后进行传输，也可能是加密后的数据仍放在一个 JSON 中，单无论如何加密算法通常都是增加体积的，越是级别高的加密方式增加的体积量一定维度上来说是越高的，所以可以考虑给加密前的数据进行一个 “压缩” 处理，可以是实用压缩算法也可以是更换一个数据量更小的数据格式。

综上而言，我们最好需要知道一些更加高效的数据传输格式或具有制定高效的数据格式的能力，最后选择哪种方案取决于你的实际场景了，这里简述一些选用思路

主要的三种方式：

1. 自定义二进制（适用于拥有自制定规范能力的人群，需要对于计算机中数据存储与二进制的相关知识充足）

2. 使用一些已有的序列化与反序列化的协议（可以是开源可以是商用性的，取决于公司决策吧，为啥协议会有商用性的？万一人家申请了专利呢）或者简单数据结构通过自定义解析方案来做序列化反序列化

3. 使用现有的通用协议 JSON/XML 等（这些标准协议很多语言都通用并提供了语言层面或框架层面的序列化与反序列化的方案，属于开箱即用，学习成本极低）

对于 1 来说，如果你有协议编程经历，那么对你来说并没有什么难度，只需要根据实际场景来合理运用即可；对于没有先关经历的人来说最好需要扎实下位运算、数据存储，了解下 HTTP 传输过程中的各层协议的处理方式后再思考自己的方案。

对于 2 来说，你只需要选择一个前后端具有相同的协议规范的工具，然后根据文档来就行了。

对于 3 来说，这个我不需要说啥的了。

个人思考的各种方式推荐的协议推荐方向

方式 1

　　1. 参考 HTTP 各层协议的处理方式，即使用类似协议头方式来决定处理规则，对于像 JSON 这类原本就是嵌套的数据结构可以做较好的一个转换

　　2. 参考密码学中的一些思路，将固定字节位作为标示识别位，其他字节位作为数据位用于存放数据

方式 2

　　1. MessagePack（现有的一个自定义的方案）。

　　2. 数组，通常用于操作指令，自定义每个下标的内容的含义，需要自己梳理文档。

　　3. 字符串，与上面方式 1 的思考一致，不过这里不是用字节位，而是字符位，需要注意的是对于处理字符串需要明确编码格式，否则某些情况可能会出问题。同样需要自己梳理详细文档，理解成都上不及数组形式。该方式也适用于自定义的弱加密，其优势在于可以自定义，只需要自己编写并更新 sdk 或 npm 包即可实现一个弱鸡版更新算法的功能，推荐实用短缓存的 sdk 形式（js 中即为 script 中引入而非 npm 包）。

方式 3

　　1. XML

　　　　a. 易读性还可以，其可扩展性和严格的标签格式使其在配置文件中得到生存。

　　　　b. 由于其数据读取的麻烦已经被 JSON 在数据传输领域基本干掉了。

　　2. YAML

　　　　a. 由于实现简单，解析成本低，特别适合在脚本语言中使用。

　　　　b. YAML比较适合做序列化。因为它是宿主语言数据类型直转的，但跨语言支持没有得到多大支持，且易读性上也并不胜于 JSON。

　　　　c. 但和 JSON 对比显然 JSON 更得前端开发者的心。

　　3. JSON

　　　　a. 具有自我描述性，易于阅读编写，也易于机器解析与生成

　　　　b. 使用 Javascript语法来描述数据对象，但是 JSON 仍然独立于语言和平台。JSON 解析器和 JSON 库支持许多不同的编程语言，语言支持度极好。

　　4. Blob