ベストアンサー1
IIRC、Jigdoを使用すると、ISOのファイルを分割し、他のサーバーから個々のファイルを抽出できます。
適切な例：JigdoはDebian ISOファイルを取得するために使用された方法でした。ダウンロードしたJigdo構成ファイルは、JigdoクライアントにFTPまたはHTTPプロトコルを使用して通常の配布サーバー/ミラーからすべてのファイルをダウンロードするように指示します。次に、ISOクライアントをビルドします。既存のISOで始まり、それを「更新」するか、以前にダウンロードして追加する時間がなかったコンテンツを追加できます。ただし、ISOの.debファイル（圧縮）の1つが変更された場合は、.debファイル全体をダウンロードしてISOを再構築する必要があります。
RSyncは、ダウンロードしたものとサーバーの「現在」の項目を調べて、違いをダウンロードしてファイルをパッチします。したがって、650 MB ISOファイルをダウンロードする場合、RSyncを実行すると、ISOファイルのサーバーサイドバージョンは変更されたコンテンツのみをダウンロードします。これにより、他のサーバーに関連するフォルダまたはファイルを「維持」することができます。ただし、サーバーはRSyncプロトコルをサポートする必要があり、誰かがサーバーと同期しようとするたびにCPU負荷がかなり高くなります。最後に、圧縮されていないバージョンの小さな変更が圧縮されたバージョンの非常に重要な変更につながる可能性があるため、圧縮ファイルでは正しく機能しません。したがって、ISOの.debファイルで複数のファイルを変更すると、Jigdoとは異なり、新しい.debファイル全体がダウンロードされます。
ZSyncはHTTP経由で動作するため、特別なプロトコルサポートは必要ありません。 ZSync は CPU 負荷をサーバーではなくクライアントにプッシュするため、集中型サーバーと同期しているユーザーが多い場合にはうまく機能します。最後に、圧縮されていないバージョンのファイルを少し変更すると、結果として圧縮されたファイルに大幅な変更があってもZSyncからダウンロードされる量が非常に少なくなります。何千もの.debファイルを含むISOがあり、いずれかの.debファイルからいくつかのファイルを変更する場合、ZSyncは古い.debファイルにパッチを適用し、必要に応じて再圧縮するのに十分な情報をダウンロードし、CRCまたはMD5署名できます。より少ない帯域幅を使用し、サーバー側のCPUを少なく使用し、特別なプロトコルは必要ありません。
これらすべてをBitTorrentとマージすることができたとき、彼らは勝者を得ました。これが発生した場合：
- サーバーと同期すると、どのような変更が必要かを伝えます。
- すべてのデータはピアによって並列に提供されるため、総ダウンロード速度が最大化されます。
- サーバーのチェックサムとハッシュは、どのピアも間違ったデータを提供しないことを保証します。
これにより、サーバーの帯域幅が少なくなり、更新が高速になります。そのようなプロトコル/システムを知っている人はいますか？前回確認した場合、BitTorrentはファイルの既存のコピーを「更新」することを許可しません。