tsh*_*ang 6 performance history
zsync和jigdo 有什么区别？它们的核心功能似乎相同，所以我对性能、文件大小和易用性等方面感到好奇。知道为什么在一个已经存在的情况下创建一个也很有趣。
小智 3
IIRC，Jigdo 允许您分解 ISO 中的文件并从其他服务器提取各个文件。
例证：Jigdo 曾经是获取 Debian ISO 文件的首选方式。您下载的 Jigdo 配置文件将指示 Jigdo 客户端使用 FTP 或 HTTP 协议从常规分发服务器/镜像下载所有文件。然后，它将构建 ISO 客户端。它可以从现有的 ISO 开始并“更新”它或添加您之前没有时间下载和添加的内容。但是，如果 ISO 中的某个 .deb 文件（已压缩）发生更改，则必须下载整个 .deb 文件才能重建 ISO。
RSync 会查看您已下载的内容以及服务器上的“当前”内容，下载差异并修补文件。因此，如果您下载了 650 MB ISO 文件，则对其运行 RSync 以及该 ISO 文件的服务器端版本将仅下载更改的内容。这允许您相对于另一台服务器“维护”文件夹或文件。然而，该服务器需要支持 RSync 协议，并且每当有人想要与其同步时，它都会有相当高的 CPU 负载。最后，它对于压缩文件的效果不太好，因为对未压缩版本的微小更改可能会级联到对压缩版本的一些非常重大的更改。因此，更改 ISO 中 .deb 文件中的几个文件将导致下载整个新的 .deb 文件，这与 Jigdo 不同。
ZSync 通过 HTTP 工作，因此不需要特殊的协议支持。ZSync 将 CPU 负载下推到客户端，而不是服务器，因此当您有大量用户与集中式服务器同步时，它的效果会更好。最后，对未压缩版本的文件进行微小更改将导致 ZSync 上的下载量非常小，即使生成的压缩文件有重大更改也是如此。如果您有一个包含数千个 .deb 文件的 ISO，并且您更改了其中一个 .deb 文件中的几个文件，ZSync 将下载足够的信息来修补过时的 .deb 文件并根据需要重新压缩它，然后验证CRC或MD5签名，就可以了。使用的带宽更少，服务器端 CPU 使用更少，无需特殊协议。
当他们能够将所有这些与 BitTorrent 合并时，他们就获得了胜利。当这种情况发生时：
这将使用更少的服务器带宽并导致更新速度更快。有人知道这样的协议/系统吗？上次我检查过，BitTorrent 不允许您“更新”文件的现有副本。