小さいファイルの転送が遅い理由と高速化する方法

同じ 100 GB でも、動画 1 本は短時間で送れるのに、画像やプロジェクト素材が詰まったフォルダーは何時間もかかることがあります。小ファイルでは、データ本体の送信に加えて、名前や権限の確認、ファイルの作成と終了、検証を何千回も繰り返すためです。

改善するには、時間がファイルの列挙、ディスク操作、ネットワーク上の待機のどこに使われているかを調べます。一度きりの納品ならアーカイブ化が役立つ場合があり、継続的な転送なら接続の再利用や適切な並列処理が候補になります。作成・展開・検証まで含めた総所要時間で比較してください。

ファイル数で転送時間が変わる理由

次の式で考えると分かりやすくなります。

総時間 ≈ データ転送時間 + ファイル一覧処理 + ファイルごとの追加処理 + ストレージ処理 + 検証

データ転送時間は一般的な帯域計算ツールが示す部分です。100 GB を実効 1 Gbps で送る時間には理論的な下限がありますが、フォルダーの転送には容量以外の処理も必要です。転送ツールは各ファイルについて次のような処理を行います。

1. パス、サイズ、権限、タイムスタンプを読む。
2. 送信元ファイルを開く。
3. 次の転送を通知または交渉する。
4. データ操作を開始・スケジュールする。
5. 受信先ファイルを作る。
6. データ本体を送る。
7. ディスクへの書き出し、終了、完了記録を行う。
8. 必要ならハッシュまたは検証する。

処理を重ねられる実装もあれば、大部分を直列で行う実装もあります。いずれにしても、ファイル数が増えると、表示される総容量に含まれない仕事が増えます。

MicrosoftもSMBについて同じ影響を説明しており、小ファイルコピーではデータ本体よりファイル作成、プロトコル、ファイルシステム処理の割合が大きくなります。Microsoft: Slow SMB file transfer

従来のFTPは制御接続とデータ接続を分けるため、ディレクトリを進むたびに準備と調整を繰り返すことがあります。RFC 959: File Transfer Protocol

rsyncは転送をパイプライン化し、新しい版はディレクトリ全体の走査前に再帰的な転送を始めますが、それでも項目列挙とメタデータ処理は必要です。rsync man pageとWANで遅いrsyncの診断を参照してください。

改善策を選ぶ前にボトルネックを診断する

遅延の簡単な例

RTT 100 msのエンドポイント間で100 GBを移動するとします。

• **構成 A：**100 GBの単一ファイル
• **構成 B：**平均1 MBのファイル100,000個

合計容量は同じですが、ファイル操作数は異なります。

1ファイルにつき追加の通信の往復が1回だけ直列化されると、単純化した待ち時間は：

100,000 files × 0.1 seconds = 10,000 seconds

データ本体、ディスク、暗号化、検証を含める前に2時間46分待つ計算です。実際のツールは要求のパイプライン化、セッション再利用、複数ストリームを行う場合があるため、すべてのプロトコルの予測ではありません。ファイルごとの遅延が重要な変数であることを示す例です。

LANの2 msなら同じ単純化した待ち時間は約3分ですが、大陸間の100 msでは時間単位になります。

実際の小ファイル転送で測った結果

2026年9月、ドイツと米国の VM 間（往復遅延約 141 ms）で、4,096 バイトのファイル 65,536 個（合計 268.4 MB）をコピーしました。OpenSSH の再帰的な SFTP クライアントはファイルを 1 つずつ処理するため、5 回とも 15 分の制限時間内に終わりませんでした。rsync と SSH 経由の tar ストリームは、前のファイルの完了を待たずにデータを送り続けられるため、どちらも約 10 MB/s で完了しました。全試行の結果、TCP と QUIC の別テスト、測定条件の限界は小さなファイル転送のベンチマークにまとめています。測定方法と記録した結果は、ベンチマークの調査ページ（英語）でも公開しています。

小ファイル転送を遅くする4つの原因

1. ファイルごとの通信の往復

会話的なプロトコルは、処理の間に遠隔側の確認応答や調整を待ちます。距離による小さな待ちが、ファイル数だけ繰り返されます。

2. ファイルシステムメタデータと開始・終了処理

送信元はディレクトリを列挙してメタデータを読み、受信先は項目を作成してメタデータを更新し、変更をディスクへ書き出します。高速ネットワークでもストレージ IOPS上限は消えません。

3. 直列化されたハッシュ、暗号化、処理の割り当て

ディレクトリ全体を走査し、全ファイルをハッシュし、暗号化してから送信を始めるツールでは、工程間でネットワークが空きます。最も遅い直列工程が総所要時間を決めます。

4. 経路を満たせない小さなデータ本体

小ファイルは、高帯域・高遅延経路を1 ストリームで使い切る量のデータが送信中になる前に終わる場合があります。アプリが繰り返し停止するなら、1 Gbpsという表示だけでは役に立ちません。

ZIP化で速くなることが多い理由

転送前にディレクトリをアーカイブ化すると、多数のファイル操作を1本の連続ストリームにできます。システム管理でtarやZIPがよく勧められる理由です。

ただし、負荷を別の場所へ移しているだけでもあります。

• 送信側にアーカイブ用一時保存領域が必要。
• 受信側にも展開用の空き容量が必要。
• アーカイブ作成と展開が総所要時間に加わる。
• 1ファイルの変更でも大きなアーカイブを作り直す場合がある。
• ツールに索引がなければ再開と検証はアーカイブ単位。

一度だけのフォルダーならアーカイブが最も簡単なことがあります。繰り返す制作ワークフローでは、転送システムが自動でファイルをまとめる方式と、毎回アーカイブを作る方式を比較するとよいでしょう。

WarpSendの並列パッキング

WarpSend はディレクトリ内の小ファイルをまとめ、接続を再利用して連続的に転送します。

次の処理を並行して進めます。

• ディレクトリ走査
• 内容のハッシュ計算
• パッキングと処理の割り当て
• 暗号化
• ネットワーク送信
• 宛先書き込み

上限を設定した並列処理によりディレクトリ全体をメモリへ読み込まず、有用な処理を継続します。永続的な暗号化パイプラインを使うため、各工程がファイルごとに終わるのを待って長距離経路が空く状況を減らします。

現行版を同じファイル、経路、ストレージ、保護設定で比較してください。転送区間の速度と、受信者が検証済みファイルを使えるまでの時間を分けて記録します。WarpSend と FTP の測定方法では比較の手順を説明しています。FTP の結果は SFTP や Aspera の性能を示すものではありません。

WarpSendとFTPのベンチマークと方法をご覧ください。

並列パッキングが有効な場合、そうでない場合

有効になりやすいのは：

• ディレクトリに数百〜数千ファイルがある。
• エンドポイント間のRTTが高い。
• メディア素材、プロジェクト、データセット、NAS フォルダーを繰り返し送る。
• 暗号化、再開、検証を維持する必要がある。
• 手動アーカイブと展開の運用負荷が大きい。

効果が小さいのは：

• すでに単一の大きな連続読み出しできるファイルである。
• 両システムが同じ低遅延LANにある。
• ストレージがネットワークより遅い。
• 調整済み転送が経路の実用上限に達している。

ロスの少ない経路で単一大容量ファイルを送るなら、調整済みFTPも非常に高速です。ファイル構成によって、有効な改善方法は変わります。

自分のフォルダーをベンチマークする方法

合計容量をほぼ揃えた3 種類のデータセットを使います。

1. 単一大容量ファイル。
2. 16ファイル程度の中規模ファイル一式。
3. 1,000または100,000ファイルの小ファイルのフォルダー。

各測定で次を記録します。

• ファイル数と平均サイズ
• 送信元と受信先ストレージ
• 帯域、RTT、パケットロス
• 暗号化と検証設定
• 総所要時間
• 転送中スループット
• 暗号学的検証結果

各構成の転送を複数回実行し、最速値ではなく中央値を報告します。実際に使う経路とハードウェアでテストしてください。

データ本体部分の計画はファイル転送時間計算ツール、距離の影響は長距離ネットワークでの高速ファイル転送を参照してください。

代表的なフォルダーでWarpSend転送を開始し、総所要時間、検証、復旧動作を現在の手順と比較してください。

よくある質問

多数の小ファイルは、同じ合計容量の単一大容量ファイルよりなぜ遅いのですか？

小ファイルごとにディレクトリの列挙、メタデータ読み出し、開始・終了処理、受信先での作成、処理の割り当て、ネットワーク上の調整が発生します。単一大容量ファイルは固定処理を連続データ本体全体に分散できますが、小ファイルは同じ処理を何千回も繰り返します。

数千個のファイルは転送前にアーカイブ化すべきですか？

アーカイブ化すれば多数のファイル操作を1本のストリームにでき、一度きりの作業には実用的です。ただしアーカイブ作成、一時保存領域、展開、再開単位、検証まで総所要時間に含めてください。繰り返す処理では、ファイル境界を保つ自動パッキングが適する場合があります。

並列転送を増やせば、小ファイルは必ず速くなりますか？

いいえ。制限した並列数はネットワークとストレージの処理を重ねられますが、多すぎるワーカーはディスク IOPS、CPU、メモリ、ファイルハンドル、ネットワークキューを奪い合います。段階的に増やし、完了時間の中央値が改善しなくなった時点で止めてください。

小ファイル転送をどうベンチマークすればよいですか？

合計容量を揃えた単一大容量ファイル、中規模ファイル一式、実際の小ファイルフォルダーを比較します。ファイル数、ストレージ、RTT、ロス、CPU、暗号化、検証、データ転送開始までの時間、総所要時間、複数測定の中央値を記録してください。