数据压缩在过去的二十年里有了复兴。新一代处理器的实际速度增长已经开始放缓，转而支持在芯片上安装更多的核心。因此，消除处理器/内存性能差距已经成为扩展的一个非常重要的策略。与此同时，诸如非对称数字系统[1]和缓存友好的比特流格式等创新也将压缩在给定时间预算内所能达到的极限推向了新的高度。当然，需求也在增长。例如，目前正在进行的使4K标准视频分辨率取代1080p视频的变化意味着屏幕上的像素增加了四倍。

但是网络游戏呢?屏幕上的像素和磁盘大小需求的增长速度与其他游戏一样快。此外，现在有在线功能的游戏数量也达到了前所未有的水平。然而，除了要获得屏幕上的像素和扬声器的高清声音外，在线游戏还需要从服务器和其他服务器获取越来越多的数据。随着技术和基础设施的不断发展，可用带宽不断增加。这种情况发生的速度总是不够快，而且因地而异。虽然数据中心每年可以轻松地将带宽增加一倍，但农村和城市居民区就没那么幸运了。考虑到新兴市场的互联网基础设施可能仍然很差，但对数字娱乐的需求却在迅速增长，这种情况就更加可怕了。一个人也许能买得起一部能运行最新款手机的体面手机，但他们将永远无法建立一个新的手机发射塔或铺设海底电缆以获得良好的连接。

所以，这取决于我们，游戏开发者，为了给我们的客户提供最好的体验而确保我们是狡猾的和充满技巧的。下面的测试向我们展示了如何在两个主要用例和一个额外用例中使用数据压缩来实现这一点。

下载

乍一看，提供文件下载似乎不是很特殊:将文件放在web服务器上，然后使用CDN或edge服务进行扩展，就这样完成了!所有这些都有成本，而且这些成本还会增加。这些开销通常与使用的带宽有关，有时与使用的存储空间有关，很少与使用的CPU周期有关。通过对文件应用更强的压缩算法，可以降低这三种速率。

由于文件在编写时只压缩一次，而下载和解压次数更多，因此压缩的速度通常可以忽略不计。相反，我们可以关注压缩比和解压速度。奇怪的是，这两个值往往在一定程度上直接相关，这意味着更强的压缩比也将有助于解压速度，因为总共需要处理的数据更少。这降低了更强大算法的复杂性的成本，但肯定不会消除它。然而，解压速度也不是主要问题，因为它通常比网络传输速度要高得多。这使得压缩比成为我们的主要关注点，因为文件大小的任何改进都将直接转化为客户机和服务器的成本节约，以及等待下载完成所花费的时间更少。

减少下载大小的第一步是清除所有不需要下载的内容，这是显而易见的，但常常被忽略。这需要仔细跟踪游戏的所有资产及其用法，这是一个好主意，原因有很多。在下载上下文中，它甚至允许在将未使用的数据上传到服务器之前进行筛选。这似乎是一种节省空间的简单方法，但是跟踪资产及其依赖项可能是一项艰巨的任务，应该从第一天就开始考虑。一旦一个项目拥有了成千上万的资产，那就太晚了。

其次，许多文件格式已经内置了压缩选项。最明显的候选是图像和视频文件。几十年来，有损压缩一直是标准，而有损压缩意味着经过压缩/解压周期后，文件内容将在一定程度上恶化。当正确实现时，这种数据丢失不会对原始的音乐和VHS磁带的模拟拷贝造成明显的差异，这只在第一次应用某种压缩时才会发生。后续的压缩传递将不会进一步降低数据的质量，除非选择了更具侵略性的设置，或者发生了基本的算法更改。然而，保留原始文件并总是对它们进行压缩是一种很好的做法。
随着图像文件格式的发展，最常用的格式，PNG和JPEG已经是不错的选择。有时有些要求这些格式不能满足，如特殊的GPU格式，但更多的是在后面。不幸的是，这两种文件格式也相当复杂，因此必须避免一些常见的陷阱。例如，用adobephotoshop创建的PNG文件有大量的元数据，这些元数据以未压缩的纯文本的形式存储在其中，这可能比图像数据本身占用更多的空间。为了消除编写程序可能导致的这个和其他效率低下的问题，强烈建议使用Pngcrush[2]、PNGOUT[3]、AdvanceCOMP[4]或其他PNG优化器。

虽然PNG通常被称为无损格式，但它确实有一个使用颜色量化的有损模式。这里使用的颜色存储在调色板中，然后使用每个像素的索引进行引用。调色板条目的数量是有限的，通常为256个，因此减少了要存储的信息量，也减少了最终出现在图像中的独特颜色的数量。pngquant[5]工具(和库)利用这些模式生成更小的图像，但并不是所有的图像处理库都能处理调色的png。

对于JPEG，可用的选项较少，因为压缩到图像保真度的权衡已经可以通过其质量参数进行精细控制。然而，这并没有阻止人们对它进行修补。谷歌在瑞士的子公司Guetzli[6]最近进行了一次相当成功的尝试。只需将这些工具放到完全自动化的资产导出管道中，另一端生成的图像将会更小。

对于不属于这两种图像格式的图像文件，Microsoft的DDS[7]或Khronos Group的KTX[8]文件格式可能是一个不错的选择，因为这是一种自制的图像格式。在这些情况下，必须对像素数据应用通用压缩。这是不管选择的格式，甚至当像素是在GPU压缩格式。

游戏中图像压缩的顶峰是Crunch[9]，它的强大和灵活的继承者是Rich Geldreich[11]和Stephanie Hurlburt[12]。这些工具包结合了自定义压缩算法和通用GPU友好的栅格格式，可以达到JPEG一样的压缩级别，可以直接加载到纹理中，几乎不需要处理。几周以来，由于与谷歌的合作，现在每个人都可以使用“轻量级”版本的工具箱[13]。

其他媒体格式，如视频和音频文件也有有损压缩方案，应该在可用时使用。然而，与图像文件相反，它们的文件格式似乎已经自然地向最有效的存储发展，因此任何合理的现代格式都可以很好地工作。似乎只有很少的事情，一个人可以做这些媒体文件。通常这些格式也与所使用的创作和回放软件相关联。

这就是有损格式的可用性似乎正在枯竭的地方。除了一些例外，比如动画曲线，大多数其他类型的文件对信息丢失几乎没有容忍度，这使得有损压缩不可行的。幸运的是，存在大量的无损通用压缩格式。最常用的一种是Deflate[14]算法。它有许多名称，用于ZIP文件，也用于许多其他地方。Deflate算法已经很好地为我们服务了，但它也已经有30年的历史了，在这期间计算机科学和技术都取得了很大的进步。

Deflate最广为人知的竞争对手可能是LZMA[15]算法，它因7-zip归档软件而大受欢迎。该类中相关的压缩算法是LZHAM[16]和Bzip2[17]。所有这些仍被广泛用于提供下载，但像Deflate一样，不再是最佳选择。虽然LZMA仍然具有具有竞争力的压缩比，但其解压速度却相当缓慢。所以，让我们看看更现代的选择。

可以论证的是，最早使用ANS论文中提到的技术的算法之一是Yann Collet[19]的Zstd[18]。Yann Collet在一段时间之前就被Facebook雇佣了，但是这个算法仍然是免费的，并且是开源的，并且有一个相当标准的许可协议，奇怪的是，这个协议禁止使用Facebook的商标，但是除此之外并没有什么限制。作为一种压缩算法，它已经取得了巨大的成功，在压缩比、压缩速度和解压速度方面都超过了Deflate。没有理由不使用它。

最后，在通用压缩算法的顶峰是一个名为Oodle[20]的商业软件包。它的高压缩算法Kraken和Leviathan在一个或多个类别中击败了任何其他当前可用的压缩算法。生活沟通

与前面关于下载的用例不同，优化实时通信比较复杂。对于下载，我们可以很容易地测量每个客户机需要下载多少数据，估计下载的频率，这样就完成了基本的成本结构。通过减少数据量或减少使用本地缓存下载数据的频率来降低这些成本。这几乎是一个银弹。

对于实时通信，即客户机、服务器和彼此之间通过网络进行的各种双向交互，我们需要考虑更多的变量。用户会话有多长?需要多久进行一次数据传输?我需要多少CPU资源来准备和处理数据?我的用户愿意提供多少带宽?这些问题中的大多数应该在项目的不同设计阶段得到回答。其中至少有两个数据压缩可以产生有意义的影响:带宽和CPU资源的使用。

更复杂的是压缩比不再是我们唯一最重要的因素。压缩速度(在下载的情况下我们可以完全忽略)和解压速度也起到了很大的作用。因此，仔细考虑所有可用的选项并选择最合适的选项是非常重要的。

让我们从通过HTTP进行通信开始，我们的选择受到框架的限制。可用的压缩方法的范围不仅限于标准允许的范围(非常广泛)，而且还限于实际可用的和广泛支持的范围。在这里，很长一段时间，gzip[21]是唯一的游戏。Gzip只是前面提到的Deflate算法的另一个名称，因此显然不再是最佳选择。

幸运的是，谷歌带来了他们的瑞士Brotli[22]算法。虽然Brotli非常符合前面讨论的高级算法，但它确实有两个明显的优点。首先，由于谷歌对WWW基础设施的巨大影响，Brotli近年来成为一种得到广泛支持的算法。其次，Brotli不仅是一个前沿的算法，它还预装了一个共享的字典，这个字典是通过使用大量的WWW流量来训练的。这给了Brotli一个额外的优势，当应用于压缩的类型的文件，通常在网站上使用。

这意味着，当需要通过HTTP进行通信时，打开压缩并请求或提供Brotli压缩内容[23]。相反，在提供已经压缩的内容时，请关闭HTTP压缩，因为在这种情况下，这只是浪费资源。然而，从性能的角度来看，选择比HTTP更简单的协议总是更好，甚至可能通过WebSockets[24]。虽然，在我们开始之前，有一个短暂的间歇来讨论字典和压缩。

在讨论数据压缩时，一个不可避免的细节是所有的压缩算法都构建并使用字典。这可能以隐式、显式或混合的方式发生，但它始终存在。简单地说，这样的字典包含原始数据的片段，这些片段出现了不止一次，并在压缩数据中被字典引用替换。如果字典加上引用比原始数据小，就可以实现数据压缩。

现在，正如在Brotli的介绍中已经提到的，相关的数据集将具有相关的字典。因此,它可以创建一个共享的字典,将包含数据片段共同对整个数据集。Brotli已经用字典中定义的规范,当然这是一个固定的数据集定义为谷歌,这可能不匹配我们所需的数据集。

Brotli和Zstd[25]附带的工具可以为任何需要的数据集构建共享字典，这并不奇怪。在处理具有类似数据的包时，使用这些工具会非常有效。甚至有一个web标准[26]正在发展以支持这一点，但是还不清楚它是否会成为主流。然而，如果我们不受HTTP的限制并控制协议的表示层，我们可以做得更好。

在开始之前，考虑需要传输什么数据是很重要的。只要不发送数据，所有不需要的数据都可以被压缩为空，根本不需要任何复杂的算法。因此，首先要确保没有发送不需要的数据。其次，应该将数据组织成频繁变化的部分和不变的部分。例如，配置值只需要在会话开始时发送一次，而不是与每个包一起发送。正如下载一节中所讨论的，这看起来很明显，但是在实践中很难做到。例如，只要引入了任何类型的自动化序列化，冗余数据就会开始潜入。解决此问题的一种方法是自动跟踪已发送的状态，并只传输必要的更改以使接收方的状态保持最新。这样做需要一个持久的连接，这是HTTP的请求/响应模型可以快速达到极限的地方。

因此，我们继续讨论持久连接领域，即TCP/IP。确切的协议并不重要，只要我们在两个端点之间有一个持久的通信通道，该通道在会话期间可用，并且不会丢失或重新排序数据包。有了这个保证，我们可以想出另一个诡计。

当较大的数据块被压缩时，压缩效果会更好，因为找到重复数据片段的机会增加了。然而，对于实时通信，我们希望发送尽可能小的数据包，因此我们失去了很多压缩的机会。解决这个问题的方法是使用压缩的数据流进行通信，这是通过在每个包之后不重置压缩机/解压器对的状态来实现的。通过这种方式，该算法可以引用前一个数据包中发送的数据片段，从而达到压缩更大数据块的效果。

原则上，所有的压缩算法都可以做到这一点，但并不是所有的压缩api都支持这一点。如果可以使用流压缩，建议使用它。它比共享字典方法更有效、更方便，因为与会话中传输的实际数据相匹配的共享字典是随时间隐式构建的。

现在，让我们看看一些具体的压缩算法。Brotli和Zstd支持流压缩，因此它们已经是很好的选择。但它们在压缩速度方面不是最好的，这在实时通信中经常是一个问题。数据总是动态生成的，每次发送方和接收方都需要对其进行压缩/解压缩。

近年来，人们开发了一套算法，提供了良好的压缩比，但压缩和解压缩快得多。在正确的设置下，它们中的一些可能会超过在内存中复制相同数量数据的速度，使得不使用压缩实际上更慢。

这个类中最古老的算法之一是LZO[27]，它以商业和免费许可证的形式提供。扬·科莱，Zstd的名人，创造了LZ4[28]，这是完全免费的，通常会比LZO做得更好。在Density[29]中还有另一套免费的算法，但“山之王”仍然是Oodle16包，其中包含Selkie和美人鱼算法。这些算法中的任何一种都可能加快你的生活通信速度，减少带宽的使用，并且，作为一个额外的好处，提供一些模糊。

虽然仅使用模糊处理显然不能保证安全性，但它有助于提高加密效率，因为简单地说，压缩数据在数学上更随机。在这一点上应该提到，加密数据，通过设计的加密算法，如果它是好的，不能再压缩。因此，加密必须总是在压缩之后进行。

关于流压缩的一个警告。如果单台主机上的连接数量非常高，则压缩状态跟踪所需的内存总量可能非常大。如果是这种情况，仔细研究使用的压缩算法文档或API通常会发现减少这种情况的方法，代价当然是压缩比。另外，将使用的算法切换到一个状态内存需求较小的算法也是必要的。

这把我们带到了另一个值得考虑的问题上。既然我们现在有这么多好的压缩选择，那么集成多个压缩选择并使它们的使用可配置是有意义的，甚至可以在每个会话级别上进行配置。在开发过程中，使用真实的数据来测量不同设置下的各种算法，以确定哪种算法是最有效的，这无疑是很有帮助的。其次，在操作过程中可能会出现算法切换有利的情况，例如在压缩算法中发现DOS或崩溃向量。有一些库，如西葫芦[30]，已经为各种压缩算法提供了一个公共接口。

这就引出了安全问题。这里提到的大多数现代算法都是由对其产品的安全性感兴趣并在这方面有良好记录的公司创建或支持的。一般来说，它们都是安全的。对于该领域的任何特定需求或问题，总是建议直接与这些算法的提供者联系。
好处:流

音频和视频流媒体是目前互动媒体和其他媒体中增长最快的部分，这是有原因的。如果不大量使用数据压缩，就不可能做到这些。不幸的是，目前流媒体领域的进入壁垒非常高，但我们可以从中学到一些东西。

流媒体是时间敏感的，有相当大的数据包传输。这种时间敏感性可以通过两种方式来处理，一种是暂停流，另一种是跳过流的一部分。只有在非交互式和非实时流媒体(如电影流)时才可以暂停。对于任何类型的交互媒体，没有及时到达的数据不再需要，可以丢弃。这同样适用于实时游戏，比如射击游戏或实时战略游戏。这意味着，具有讽刺意味的是，流压缩在整个持续时间内是不可能的，因为无法保证连续的数据流。

简单地说，为了获得一个合适的压缩比，这些媒体文件被分割成由几秒钟的内容组成的块，然后这些内容被单独压缩并提供给客户端。这样，如果需要，可以跳过整个块。此外，块可以在多个质量级别上准备，允许动态调整带宽。

结论

正如我们所看到的，有许多选项可以显著改善数据未压缩或使用Deflate。为给定的问题选择最佳选项并不总是很直接的，但是有一些成功的保证。例如，用Zstd或Brotli替换Deflate几乎总是净收益，而且除了实现更改之外不需要任何成本。其他的变化可能更复杂，需要大量的实验，但也允许更大的好处。

记住，每节省一点带宽就等于节省了带宽成本。这种成本很快就变成了非人为产品或服务的第一成本。事实上，某些用例，比如视频流，如果没有适当的数据处理，在技术上或财务上都是不可行的。

除了潜在的大量成本节约之外，巧妙地使用数据压缩还可以减少等待时间和内存使用，同时为使用相同的带宽交付更高质量的内容或使用更少的带宽交付相同质量的内容提供了机会。它使产品在竞争中脱颖而出。在娱乐行业，这比任何成本节省都要划算得多。