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

[LLaMA]

[silentsky]

如果请求量很大的话还是有必要考虑 protobuf ，毕竟带宽也是需要钱的

[weeei]

考虑一下 CBOR ？
https://news.ycombinator.com/item?id=14067747

[realpg]

brotli 之后比较呢

[wellerman]

就拿《我再也不敢装逼了》这个帖来说。一个新用户进去，啥也没干就能消耗掉接近 7M 的流量，json 换 MessagePack 就没什么必要了。

[Trim21]

@tool2d 现在 js 的二进制 API 太复杂了

[lolizeppelin]

主要是你前端怎么实现....
全用二进制请求得改多少接口呀....
又没法把 msgpack 结果包 json 里,用 b64 转码二进制的化又变大了反而没意义还不如直接 json 开 gzip

[duke807]

@icyalala 给别人用完全可以 json 和 msgpack 同时支持，收到 json 就回 json ，收到 msgpack 就回 msgpack

json 和 msgpack 结构类似，解析出来的数据也是一样的，服务器后面的处理完全相同，同时支持一点都不费事

[duke807]

@silentsky protobuf 太麻烦

[duke807]

@duke807 狗狗都不用

想节省流量，使用 msgpack 的时候，key 名用短一点即可

[xiangyuecn]

之前看了一篇文章，b 站直播 客户端之间的 p2p 网络内传输的数据，就是用的 message pack 作为传输协议，也用这个封装一下 hls 切片文件，简单粗暴，节省用户的带宽😅

[lianyue]

我做过一个应用

支持 proto 和 json
gzip 或 br 后 一般 proto 只比 json 大小浮动 -5%-+1% 小百分之五 到大百分之一

[Logtous]

接触过一款国内在线用户百万级别的手游传输协议用的 msgpack

[icyalala]

@duke807 如果你同时支持两种格式，那只能让功能向 json 对齐，msgpack 的额外功能就用不到，结果无非就是省些流量。如果再 gzip 一下，那两者连流量的差距都很小了，这只要在 nginx 配一下就行，对应用来说都是透明的。

如果说性能，正是因为 json 流行，现在各个语言都有一堆高度优化甚至 simd 加速的库，其他格式没这个待遇的。有特殊需求的，这里还有一堆二进制格式可选呢： https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats

[duke807]

@icyalala 不，我説了 msgpack 可以简化接口，因为可以传二进制，同一种 api 就可以传输图片文件

同时支持的时候，如果客户选择使用 json ，那么就只能麻烦一些用单独的文件上传下载 api ，由客户自行选择，服务器架构不用往 json 靠

对于文本解析，再怎么加速都没 msgpack 这样的二进制格式效率高

而且，现在很多嵌入式设备，mcu 解析 json 更是亦常的麻烦，譬如在没有 malloc 可用的环境，而此时 msgpack 解析则轻松省事

（对于 ram 很小的 mcu ，需要无损压缩数据的话，压缩格式我会选择 lz4 ，而不选 zip 类，因为前者对 mcu 来说轻量很多）

[duke807]

协议虽有很多，但 msgpack 是最简单、最接近 json 的格式，对开发者来説，换一下 序列化 和 反序列化 两个函数名就行了

[icyalala]

@duke807 接口方面，你不可能要求后端同学花费力气去专门为小众需求单独开发一个接口。而且即使对齐到 json 格式的话，支持多种格式也需要后端单独做开发和测试，这和运维同学改改 nginx 配置完全不是一个工作量。

我觉得性能方面你想当然了。simdjson 能用 simd 快速教研整个 json 的 UTF-8 编码，实际上现在解析速度也能达到 3GB/s ，甚至还能按需解析性能还会更高。msgpack 里面的字符串也是 UTF-8 的，但我没见有什么库愿意去写 simd 加速或者按需解析的。

如果你把应用范围限定在嵌入式，那和上面我们讨论的完全不是一回事儿了，性能又不是主要考虑的东西。如果你说没有 malloc ，那就算用 JSON 库也有很多允许自定义 allocator 或者自带 fixed memory allocation 功能的库，这完全没问题。

[Aloento]

你可以看看 SignalR

[whileFalse]

JSON 换 MessagePack 解决了什么问题？代价是什么？
你引用的那个帖子里的例子就是有病，那么大的请求量，连带宽都付不起，趁早倒闭

别什么事儿都想着上奇技淫巧。带宽都付不起的公司，不值得。

[dayeye2006199]

这边太多老哥做 2C 业务做的太多，觉得所有程序员都是做这个的。json 序列化 http 协议走天下。
其实见过好多分布式科学计算，高性能计算的框架，就用这个来做序列化的。好多传输的东西是向量，比如 numpy 的对象。这些东西还需要加上压缩之类的算法。json 搞这些其实挺麻烦的。msgpack 倒是处理起来不难。

都是看需求。json 不是万能的。

[raptor]

@knightdf 确实，我司曾经也试过一段时间 protobuf ，后来还是换回 json 了，还是方便比较重要。