为什么很少见用 MessagePack 代替 JSON 的 Web 服务，不是更省流量吗？去一个 Discord 群问了 /t/932789 的问题，有个美国老外给我推荐这种方案。

[LLaMA]

[j20001112]

哪个 discord 群呀？

[crysislinux]

json 一眼就能看清是什么内容，大部分网站应该还不到扣这点性能的时候吧。以前看 Google 有些服务就不是 JSON

[adoal]

互联网的主流协议，大多都是底层需要效率和精确控制的用 binary ，上层易于理解和观察的用 text ，有特殊场景需要违背时才做反例。

[c1985382]

并没有省太多吧，key 还在数据里。要省流的话 protobuf 不是更好。

[knightdf]

单纯为了省流的话 protobuf 多好，但是现实是原来好多 protobuf 协议的接口现在都换成 json 了

[LLaMA]

@c1985382
@knightdf MessagePack 更省流吧

[Trim21]

gzip 一下差不了多少，甚至有可能 json 更小。

而且在浏览器里用 messagepack 还要额外消耗 messagepack 解析库的流量。

[billlee]

HTTP 本来就是基于文本的，用 HTTP 的情况下就不考虑这点性能了

[ch2]

纯文本压缩太简单了

[shyangs]

gzip 之後的比較呢？

[lesismal]

1. MessagePack 和 Json 都是自释的，都带有了 key 信息，都是相当于动态结构
2. MessagePack 二进制、省去了 Json 的那些双引号、冒号、逗号、括号之类的，能省一些但毕竟 key 信息还在
3. PB 这种是 c/s 各自都持有了消息体的定义，根据消息定义的字段顺序进行序列化、反序列化时根据消息定义的字段顺序从 buffer 里挨个取出来解析就可以了，不需要把 key 信息也放到序列化后的数据里，而且本身也不需要引号冒号那些，所以节省更多。一些数值类型会做一些压缩，比如 int64 需要 8 字节但当前的值比较小、2 字节就够了，那就省一点。MessagePack 是否也有这个数值压缩我不记得了，好像是也有的
4. 不管用哪种，如果消息结构定义的重复率比较高、序列化后的包体 size 比较大，通常 gzip 之类的压缩算法加一道，就省更多了

用 Json 更灵活、自由、方便，版本更新升级做兼容性也容易
用 PB 更严格、工程化、规范，版本升级要考虑协议兼容性的更多、要考虑 c/s 是否必须同步停服维护升级之类的
MessagePack 挺不错，但是不如 Json 那种明文、方便调试之类的，它相比于竞品，优点都是处于中间水平，省流优秀但不是最佳、自释义但不明文，而且出生也晚，所以反倒是用的人最少

[ikas]

跨语言用了好几年了,写好序列化通用模块,与 json 一样易用
比如 java 端,直接使用 jackson

[Nazz]

MessagePack 性能和便捷都不是最好的

[tool2d]

说到底，还是前端不善于处理二进制流数据。
js 有能完美处理二进制 api ，但是前端真正会的人群，估计不到 10%。

[iseki]

不差这点流量，现阶段人类可读比这点流量重要得多

[akira]

是能省，但是为啥要省。。。 而且，真要省流量的话，为啥不上个压缩算法，效果不更好么

[duke807]

msgpack 很好，代替 json 很方便

特别是支持二进制数据传输，图片、文件可以走同一套 api 传输

易用性和扩展性都是常规方案里面最优的，且序列化效率非常高

至于调试，把 msgpack 转字符串很容易，根本就不是借口

至于为何很多人不用 msgpack ，是因为没有眼光，不会选择好东西（也有一些是暂时不需要追求性能和传二进制，已经做好准备需要的时候再切换到 msgpack ）

[LLaMA]

@j20001112 一个不知名开源项目的技术群，400 多个人，看了下没几个国人

[icyalala]

如果服务仅限自己使用，那什么格式都无所谓，甚至自定义个私有格式也许在性能上更好。
如果你要给别人用，那当然要考虑最通用的，并不是每个人都有能力或者愿意去兼容其他更小众的格式。
何况 msgpack 在性能上并没有明显优势，不一定比得上 JSON 压缩+simdjson 。

在这个 json 已经是数据交换事实标准的情况下，你给别人提供服务用 msgpack ，那才是没眼光。

[ysjiang4869]

还有个 cbor ，效率更高好像，我之前和下位机对接使用的 cbor