最近中间件组开始尝试推送 goscon 流量压缩的更新，继上次用 libev 改写 goscon 提升效率后，又是一大改进了。可惜我们没机会上了，CM 觉得我们没有带宽的压力，引入更新只会增加潜在风险。站在团队角度看，我很能理解这个理由啦，但是单纯的从技术追求角度看，又心痒痒的很想上，纠结 ing

中间件组的实验报告很有意思，中间提到了一点，sproto 的 pack 算法反而会降低最终的压缩率，sproto 的 pack 是针对二进制串里连续的 0 做的压缩，应用层做了压缩后，反而影响到压缩算法的全局压缩效率了。目前为了快速实现，只是针对每个协议来单独压缩，而且选的是成熟的经典算法，如果换成 zstd 应该能更好一点。而且 zstd 能够预训练字典，对于 sproto 协议这种数据量相对小的样本，应该能取得更好的压缩比，zstd 的解压速度还特别快，完美！剩下的疑问是要不要搞成流压缩，流压缩可以根据前一段字节流来调整字典，有可能取得更好一点的压缩比，但是出现比特翻转的话，会导致后续的协议都解不开。如果上行不压缩，只压缩下行的，这个问题可能可以忽略，毕竟服务器都用上了 ECC 内存，而上行的协议流量也比较少

updated: 看了中间件同学后续的报告，用字典只有非常非常微小的提升，可能是因为sproto里就没有大段大段固定的字节吧，如果是msgpack之类的，字段名应该能用字典方式压缩不少