增量压缩如何减少通过网络发送的数据量？

许多游戏使用增量压缩技术来降低发送的数据负载。我不明白这种技术实际上如何降低数据负载？

例如，假设我要发送职位。如果不进行增量压缩，则发送vector3带有实体确切位置的，例如(30, 2, 19)。使用增量压缩时，我发送的vector3数字较小(0.2, 0.1, 0.04)。

我不明白如果两条消息都是vector3-每个浮点数为32位-32 * 3 = 96位，它将如何降低数据负载！

我知道您可以将每个浮点数转换为一个字节，然后将其从字节转换回浮点数，但这会导致可见的精度错误。

有时候，您无法避免发送完整的游戏状态-例如在加载已保存的多人游戏时，或者需要重新同步时。但是发送完整状态通常是可以避免的，这就是增量编码的目的。通常，这就是增量压缩的全部内容。您的示例并没有真正描述这种情况。甚至提到增量压缩的原因是因为幼稚的实现通常会发送状态而不是增量，因为状态通常是任何幼稚游戏实现都会存储的内容。因此，Deltas是一种优化。

有了增量，您将永远不会发送不动的单位的位置。这就是它的精神。

想象我们是笔友多年，而我失去了记忆（在阅读完您的所有信件后就把它们丢弃了）。与其像平常一样简单地继续写一系列书信，还不如用一封大写信给我写一生的全部历史，以便我追上。

在给定的情况下，与发送完整状态所需的较大位范围相比，有可能（取决于您的代码库）使用较少数量的位对增量进行编码。假设世界跨过许多公里，您可能需要一个32位浮点数才能准确编码位置（例如，给定轴上的厘米）。但是，给定适用于实体的最大速度（每个滴答可能只有几米），它可能仅用8位（2 ^ 8 = 256，足以存储最大200cm）是可行的。当然，这是假设使用定点数而不是浮点数……或者如果您不希望使用定点数麻烦，则使用某种类似于OpenGL的半/四分之一浮点数。

您的三角洲错误。您正在查看各个元素的差异。您需要考虑整个场景的增量。

假设场景中有100个元素，但其中只有1个被移动。如果您发送100个元素向量，则会浪费其中的99个。您实际上只需要发送1。

现在，假设您有一个JSON对象，用于存储所有元素向量。此对象在服务器和客户端之间同步。而不是决定“某某动作了吗？” 您只需在JSON对象中生成您的下一个游戏滴答声，制作一个diff tick100.json tick101.json并发送差异即可。在客户端，将diff应用于当前刻度的矢量，一切就绪。

这样一来，您就可以利用数十年的专业知识来检测文本（或二进制！）之间的差异，而不必担心自己遗漏任何东西。现在，理想情况下，您还可以使用一个在后台执行此操作的库，以使您作为开发人员更加轻松。

通常，另一种压缩机制将与增量编码相结合，例如算术压缩。

当将可能的值可预测地分组在一起时，这些压缩方案会更好地工作。增量编码会将值分组为0左右。

您大体上是正确的，但缺少一个要点。

游戏中的实体由许多属性来描述，其中位置仅是一个。

什么样的属性？在网络游戏中，不必太费力地思考，它们可以包括：

• 位置。
• 取向。
• 当前帧号。
• 颜色/照明信息。
• 透明度。
• 使用的模型。
• 使用的纹理。
• 特殊效果。
• 等等。

如果您单独选择其中的每一个，那么您肯定可以确定，如果在任何给定的帧中需要更改它，那么必须将其完全重传。

但是，并非所有这些属性都以相同的速率改变。

型号不变吗？如果没有增量压缩，则无论如何都必须重新传输它。有了delta压缩，就不必如此。

位置和方向是两种更有趣的情况，通常分别由3个浮点组成。在任何给定的两个帧之间，每3个浮点组中只有1个或2个可能发生变化。直线运动？不旋转？不跳？这些都是在没有增量压缩的情况下您必须完全重新传输的情况，而在具有增量压缩的情况下，您仅需要重新传输发生变化的内容。

没错，仅凭单纯的增量计算，将结果存储在与操作数相同的大小数据结构中，并且不进行任何进一步处理就可以传输数据，这不会节省任何流量。

但是，基于增量的精心设计的系统可以通过两种方式节省流量。

首先，在许多情况下，增量将为零。您可以设计协议，以使如果增量为零，则根本不会发送该协议。显然，这样做有一定的开销，因为您必须指出您正在发送或未发送的内容，但总的来说这可能是一个巨大的胜利。

其次，增量通常将具有比原始数字小得多的值范围。并且该范围将以零为中心。通过对大多数增量使用较小的数据类型，或通过将通用数据流传递给通用压缩算法，可以利用这一点。

尽管大多数答案都谈到增量编码是如何仅将状态更改整体发送出去的，但是还有另一种称为“增量编码”的东西可以用作过滤器，以减少在完整状态下需要压缩的数据量以及更新，这可能是所问问题中混乱的根源。

在对数字矢量进行编码时，可以在某些情况下（例如整数，枚举等）对各个元素使用可变字节编码，在某些情况下，您可以进一步减少每个元素所需的数据量如果将其存储为运行总和或最小值，以及每个值与最小值之间的差。

例如，如果您想对向量进行编码，{68923, 69012, 69013, 69015}则可以将其增量编码为{68923, 89, 1, 2}。使用平凡的可变字节编码，其中每个字节存储7位数据，并使用一位指示另一个字节要来，数组中的每个元素都需要3个字节来传输它，但采用增量编码的版本第一个元素只需要3个字节，其余元素只需要1个字节；根据您要序列化的数据种类，这可以节省一些可观的费用。

但是，这更多的是序列化优化，而不是通常所说的“增量编码”，指的是将任意数据作为游戏状态（或视频等）的一部分进行流式传输。其他答案已经足以说明这一点。

还值得注意的是，压缩算法在差异化方面做得更好。就像其他答案一样，您的大多数元素在2种状态之间保持不变，或者值变化很小。在这两种情况下，对数字向量的差应用压缩算法都可以节省大量资金。即使您不对向量应用任何额外的逻辑，例如删除0元素。

这是Python中的示例：

import numpy as np
import zlib
import json
import array


state1 = np.random.random(int(1e6))

diff12 = np.r_[np.random.random(int(0.1e6)), np.zeros(int(0.9e6))]
np.random.shuffle(diff12) # shuffle so we don't cheat by having all 0s one after another
state2 = state1 + diff12

state3 = state2 + np.random.random(int(1e6)) * 1e-6
diff23 = state3 - state2

def compressed_size(nrs):
    serialized = zlib.compress(array.array("d", nrs).tostring())
    return len(serialized)/(1024**2)


print("Only 10% of elements change for state2")
print("Compressed size of diff12: {:.2f}MB".format(compressed_size(diff12)))
print("Compressed size of state2: {:.2f}MB".format(compressed_size(state2)))

print("All elements change by a small value for state3")
print("Compressed size of diff23: {:.2f}MB".format(compressed_size(diff23)))
print("Compressed size of state3: {:.2f}MB".format(compressed_size(state3)))

这给了我：

Only 10% of elements change for state2
Compressed size of diff12: 0.90MB
Compressed size of state2: 7.20MB
All elements change by a small value for state3
Compressed size of diff23: 5.28MB
Compressed size of state3: 7.20MB

如果您的位置存储在vector3中，但实际实体一次只能移动几个整数。然后，以字节为单位发送它的增量要比以整数发送它更好。

当前位置：23009.0，1.0，2342.0（3浮点数）
新位置：23010.0，1.0，2341.0（3浮点数）
增量：1，0，-1（3字节）

我们不是每次发送精确位置，而是发送增量。

增量压缩是增量编码值的压缩。增量编码是一种转换，会产生不同的数字统计分布。如果分布有利于选择的压缩算法，则它将减少数据量。它在像游戏这样的系统中效果很好，在该系统中，实体在两次更新之间仅略微移动。

假设您有100个2D实体。在大型网格上，为512 x512。为示例起见，仅考虑整数。这是每个实体两个整数或200个数字。

在两次更新之间，我们的所有位置都会改变0、1，-1、2或-2。有100个实例为0，33个实例为1和-1，只有17个实例为2和-2。这很普遍。我们选择霍夫曼编码进行压缩。

为此的霍夫曼树将是：

 0  0
-1  100
 1  101
 2  110
-2  1110

您所有的0将被编码为单个位。只有100位。66个值将被编码为3位，而只有34个值将被编码为4位。那是434位或55个字节。再加上一些小的开销来保存我们的映射树，因为它很小。请注意，要编码5个数字，您需要3位。我们这里已经交换了使用1位表示“ 0”的能力，因为需要使用4位表示“ -2”。

现在比较一下，发送200个任意数字。如果您的实体不能在同一图块上，则几乎可以保证您得到的统计分布不正确。最好的情况是100个唯一数字（全部在同一X上，不同Y上）。每个数字至少7位（175字节），对于任何压缩算法来说都很难。

在特殊情况下，当您的实体变化很小时，增量压缩将起作用。如果您进行了许多独特的更改，则增量编码将无济于事。

请注意，增量编码和压缩还可以在其他情况下与其他转换一起使用。

MPEG将图片分割为小方块，如果图片的一部分移动，则仅保存移动和亮度变化。在25fps的电影中，帧之间的许多变化很小。同样，增量编码+压缩。最适合静态场景。