这将是一个有点抽象的问题，因为我什至不知道是否有这样的进展。
假设我们有一个应用程序尝试将文本数据从 A 点传送到 B 点。 A 和 B 相距很远，因此数据大小对我们想要优化的所有重要指标(速度、延迟和吞吐量)有重大影响。首先想到的是压缩，但是当我们必须压缩很多很多小消息时，压缩并不是那么有效，但当压缩数据的大小很大时，它非常有效。
我没有压缩算法的经验，但我的理解是输入越大，压缩率就越好，因为重复 block 和可以优化的东西的可能性更大。
我们可以采取的另一种方式是批处理，通过等待一些 N 时间段并收集所有小消息并创建一个压缩的大消息，我们可以获得良好的压缩率，但我们会牺牲延迟，首先到达的消息将占用不必要的延迟N。
我正在寻找的解决方案是这样的，当压缩算法遍历数据集时，它可能有一些它知道可以优化的事物的字典。每次我们完成压缩后，这个字典就会被丢弃，并且它总是与消息一起发送给 B。
rawMsg -> [dictionary|compressedPayload] -> 发送到 B
但是，如果我们可以将这个字典保存在内存中，并且仅在它发生更改时才发送，这意味着我们可以有效地压缩甚至很小的消息，并避免每次都将字典发送到另一端。 ..
rawMsg -> compress(existingDictrionaryOfSomeVersion, rawMsg) -> [dictionaryVersion|compressedPayload] -> 发送到 B
现在显然这里的假设是 B 也将保留字典的实例并在新版本到达时不断更新它。
请注意，这种情况已经在 protobuf 或 fix(在金融应用程序中)等协议(protocol)中发生。
对于任何消息，您都有模式(字典)，并且它在两端都可用，然后您只需发送原始二进制数据，高效且快速，但您的模式是固定且不变的。
我正在寻找可用于自由格式文本的东西。
是否有任何技术可以做到这一点(无需某些固定模式)？
最佳答案
您可以简单地在单个压缩流中发送许多小消息。然后他们将能够利用以前的小消息历史记录。使用 zlib，您可以刷新每条消息，这将避免在传输之前必须等待整个 block 建立起来。这会降低压缩性能，但不会像尝试单独压缩每个字符串那样严重(这可能最终会扩展它们)。对于 zlib，您的字典始终是您发送的最后 32K 消息。
关于java - 使用静态字典压缩字符串，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49787057/