zsync 與 jigdo
zsync和jigdo和有什麼不一樣？它們的核心功能似乎相同，所以我對性能、文件大小和易用性等方面感到好奇。知道為什麼在一個已經存在的情況下創建一個也會很有趣。
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 不允許您“更新”文件的現有副本。