OpenSearch HTTP REST API 在 zstd 压缩编码下的挂起问题分析

问题现象

近期在 OpenSearch 2.19.0 版本中发现了一个与 HTTP 压缩传输相关的重要问题：当客户端请求头中包含 zstd 压缩编码选项时，服务端响应会出现挂起现象。具体表现为：

1. 客户端发送带有 Accept-Encoding: deflate, gzip, br, zstd 头部的 HTTP 请求
2. 服务端返回 200 OK 响应，并指定 content-encoding: zstd
3. 但实际响应数据永远不会完成传输，导致连接挂起
4. 该问题在 2.18.0 版本中不存在，属于新引入的回归问题

技术背景

OpenSearch 作为 Elasticsearch 的分支，继承了其网络通信架构，底层使用 Netty 处理 HTTP 请求。在 HTTP 压缩方面：

• 传统支持 gzip 和 deflate 压缩算法
• Brotli(br) 是较新的压缩算法，具有更好的压缩率
• Zstandard(zstd) 是 Facebook 开发的高效压缩算法，平衡了压缩率和速度

问题根源分析

经过深入调查，发现问题源于以下几个技术因素：

1. Netty 版本升级影响：OpenSearch 2.19.0 升级了内嵌的 Netty 版本，其中包含了对 zstd 压缩的相关修改。虽然 OpenSearch 本身并未明确支持 zstd HTTP 压缩，但由于依赖库的变化，触发了这一行为。

2. 类路径冲突：OpenSearch 包含了 zstd-jni 库在类路径中，这使得 Netty 能够检测到 zstd 编解码器的可用性，从而尝试使用 zstd 压缩响应。

3. 不完整的实现：虽然服务端识别并声明使用 zstd 压缩，但实际的压缩数据流处理可能存在缺陷，导致数据无法正确传输。

影响范围

该问题影响所有使用以下配置的环境：

• OpenSearch 2.19.0 及以上版本
• 客户端请求中包含 zstd 压缩选项
• 未显式禁用 HTTP 压缩功能

临时解决方案

目前可采用的临时解决方案包括：

1. 客户端调整：在客户端请求中移除 zstd 压缩选项，仅保留 Accept-Encoding: deflate, gzip, br

2. 服务端配置：在 opensearch.yml 中显式禁用 HTTP 压缩：

   http.compression: false
   

3. 版本回退：暂时回退到 2.18.0 版本，等待官方修复

长期解决方案建议

从架构角度看，OpenSearch 项目组应考虑：

1. 明确压缩支持策略：在文档中清晰说明支持的压缩算法列表

2. 完整测试覆盖：对所有声明的压缩算法进行端到端测试

3. 依赖管理：审慎评估网络库升级对核心功能的影响

总结

这个案例展示了开源项目中依赖管理的重要性，以及看似无害的库升级可能带来的意外副作用。对于生产环境用户，建议密切关注官方更新，并在升级前充分测试关键功能。目前可通过调整客户端或服务端配置规避此问题，期待官方在后续版本中提供完整修复。