部分解压并估计实际解压数据报文的大小

Question

我有一个简单的要求，如果消息超过 X 字节的上限，我想丢弃或不处理它。但是，发件人可以压缩消息并发送。如果用户创建一个随机消息，例如全 0 或 1 等，则压缩熵变化很大。然而，假设一个受信任的发件人有办法窥视压缩消息并在解压缩时估计其实际大小。我正在使用使用 java.util.zip 的 Zip 协议，但我对其他库或语言中的任何解决方案持开放态度。

Answer 1

不是真的。

Deflate 是一种流格式，它在开始之前对数据一无所知，因此无法嵌入解压缩后的大小（snappy、brieflz 等格式）。

您能做的最好的可能是使用流 API 最多解压缩 MAX_MESSAGE_SIZE 字节（您可能需要使用 MAX_MESSAGE_SIZE + 1；使用 zlib 很难判断是否到达流的末尾或者如果它只是处理所有可用的输入，除非你给它足够的空间来实际解压缩更多数据）。如果您认为消息太长，这不会让您提前停止处理，但会在消息真的太长时让您停止处理（这应该足以缓解 DoS）。

不幸的是，您不能仅根据您所看到的情况来估计总大小，因为有人可能很容易在流的开头拥有难以压缩的数据，然后是一百万个相同的字节，这将是非常 压缩得很好。