为什么重新排序 gzip 数据包会损坏输出？答案

【问题标题】：Why does reordering gzip packets damages the output?为什么重新排序 gzip 数据包会损坏输出？
【发布时间】：2013-10-30 00:19:41
【问题描述】：

我正在使用zlib 中发布的 gzip 代码的想法。对于初始化，我使用deflateInit2(p_strm, Z_DEFAULT_COMPRESSION, Z_DEFLATED, (15+16), 8, Z_DEFAULT_STRATEGY)。我正在压缩流。每个数据包都带有Z_FULL_FLUSH，除了我使用Z_FINISH的最后一个数据包。压缩每个数据包后，我正在重新排序数据包。

数据包中的数据 ---> [zip] ---> [重新排序] ---> ...

如果我在压缩后膨胀数据，我会在压缩前得到准确的文件。如果我在对数据包重新排序后对数据进行膨胀（同样：每个数据包都用Z_FULL_FLUSH 放气，最后一个Z_FINISH 除外）我得到一个与压缩前的原始文件非常相似的文件。不同之处在于文件的末尾：它缺少字节。那是因为当我给它充气时，我收到最后一个数据包的错误 (Z_DATA_ERROR)。如果我膨胀，比方说，用 50KB 的块，重新排序后的膨胀文件是与输入相同的文件，小于 Z_DATA_ERROR，但现在我在膨胀时丢失的数据更少（在我的示例中，我从原始文件中缺少一个字节）。

我不会重新排序最后一个数据包 (Z_FINISH)。我尝试使用Z_FULL_FLUSH 发送所有数据包，然后发送另一个“空”数据包（仅Z_FINISH，即10 个字节）。

为什么会这样？如果我使用 Z_FULL_FLUSH，为什么充气机不能正确充气？它还记得放气包的顺序吗？

任何信息都会有所帮助，谢谢。

【问题讨论】：

是什么让您觉得 zip 可以灵活地应对数据包重新排序？
它只是工作，我对文件进行膨胀并且它工作（除了最后一个膨胀块）。然后我明白了Z_FULL_FLUSH负责它...

标签： c networking gzip zlib gzipstream

【解决方案1】：

由于您使用的是Z_FULL_FLUSH，它会在每次刷新时删除历史记录，您可以重新排序数据包，除了最后一个。你在Z_FINISH 上所做的那个必须是最后一个数据包。但它不需要任何数据。您可以使用Z_FULL_FLUSH 提供最后一个数据包中的所有数据，然后在没有输入数据和Z_FINISH 的情况下执行最后一个数据包。这将允许你在你喜欢的空包之前重新排序包。总是把最后一个放在最后。

原因是 deflate 格式是自终止的，所以最后一段标志着流的结束。如果你将它重新排序到某个地方的中间，那么当它碰到那个数据包时，膨胀就会停止。

gzip的头和尾都需要维护，同时更新trailer中的CRC。最后的CRC校验取决于数据的顺序。

为什么要做你想做的事？你在优化什么？

【讨论】：

谢谢，实际上我并没有重新排序最后一个数据包（忘记写了）。我还尝试使用Z_FULL_FLUSH 发送所有数据包，然后发送最后一个数据（0 个输入数据，10 个 gzip 数据的输出开销） - 但它也不起作用：\ ...
我正在进行数据包重新排序以进行优化。
所以理论上我似乎没有做错什么，不是吗？我没有重新排序第一个/最后一个数据包。我之前提供的信息是否可以帮助我理解 CRC/last gzip 标头中的某些内容不好？（输入文件和膨胀的输出文件是相同的，除了后者末尾的一些字节。这个字节数由我尝试膨胀的块的大小决定）。对不起，它没有完全优化。我从另一个组件获取每个数据包的顺序与我想要发送的顺序不同，所以我按照我的意愿重新排序。
首先让它使用原始放气，使用-15 代替windowBits。那么你不必担心CRC。然后，如果您在Z_FULL_FLUSH 之后正确地从deflate() 中提取所有字节（您需要继续调用deflate() 直到它返回stream_avail != 0），那么重新排序除最后一个数据包之外的数据包应该是可膨胀的，再次在inflateInit2() 中使用-15。
谢谢！当我能够判断它是否有效时，我会尝试。

【解决方案2】：

GZip 是一种流式传输协议。压缩取决于流的先前历史。您无法重新排序。

【讨论】：

在这种情况下，您可以重新排序。 Z_FULL_FLUSH 的目的是在流中提供断点。