HULFTで大容量ファイルを送信する際、
「単独転送と間欠転送では速度がどれくらい違うのか？」
と気になる場面は多いはずです。

特に、S3送信やネットワーク負荷対策で間欠転送を設定した場合、
「どれだけ転送時間が増えるのか？」を事前に把握しておきたいところです。

本記事では、HULFTの転送処理を理論値（数式）で算出する方法をわかりやすく解説します。

---

1. HULFT転送の基本：ブロック単位で送られる

HULFTはファイルをそのまま送るのではなく、
一定サイズ（ブロック長）に分割してブロック単位で送信します。

例えばブロック長を 16KB に設定している場合：

• 1ブロック = 16KB

• 1MBのファイルなら 1,048,576 ÷ 16,384 ≒ 64ブロック

という計算になります。

この「ブロック数 × ブロックあたりの処理時間」が転送時間に大きく影響します。

---

2. 単独転送の理論値：最速で送るシンプルな動作

単独転送（=間欠転送なし）は、
ブロックを休まず連続で送っていく動作です。

■ 単独転送の理論値計算式

※実効転送速度（Throughput）はネットワーク・HULFTヘッダなどのオーバーヘッドを含む実測値。

■ 例：500MBのファイルを100Mbpsで送信する場合

理論上は40秒となります。

実際にはHULFTヘッダ分のオーバーヘッドで数秒増える程度。

---

3. 間欠転送の理論値：休止時間の積み重ねで大幅に遅くなる

間欠転送は、各ブロック送信後に**休止時間（インターバル）**が入ります。

HULFTの設定例：

• ブロック長：16KB

• ブロック回数：100回

• 休止時間：30ms

■ 間欠転送の理論計算式

ここが最も重要なポイント。

ブロックが多い場合、休止時間が膨れ上がります。

---

4. 実例：500MBファイルを間欠転送で送るとどうなる？

★ 前提

• ブロック長：16KB

• 500MB = 32,768ブロック

• 単独転送時間：40秒（前述）

• 休止時間：20ms

■ 間欠転送の追加時間

■ 合計転送時間

---

→ 実際の現場でも「間欠転送は数倍遅くなる」理由はここにある

ブロック数 × 休止時間 → これが爆発的に効いてくるためです。

---

5. 実効転送速度（Throughput）の簡易算出方法

実測値を1回取るだけで、理論値がもっと正確になります。

■ 実測からの計算式

例えば

• 100MBのファイル

• 送信実測15秒
  → 実効速度 = 100MB ÷ 15 = 6.6MB/s（53Mbps）

これを単独転送の基準値にすることで、
間欠転送の予測精度が向上します。

---

6. 間欠転送の「適切な使いどころ」

間欠転送は遅くなるため万能ではありませんが、
以下の目的では効果的です。

• S3/クラウド側で転送速度制限がある場合

• 受信側の負荷分散が必要な場合

• 夜間バッチでNW帯域を食いすぎるのを避けたい時

• 他システムの処理性能に合わせたいケース

速度ではなく安定性や負荷分散を目的に使うのが本来の用途。

---

7. 間欠転送設定によるエラー（S3Timeout など）について

休止時間を入れると、
1ブロックあたりの処理が遅くなる → 全体が長くなる → タイムアウトに近づく
という問題があります。

特にS3送信では

• S3Timeout（約60秒）

• NW機器の制限

• プロキシのタイムアウト

などに引っかかるケースが多い。

✔ 大容量ファイルほど間欠転送はリスクが高い

500MB・1GB級のファイルではブロック数が膨大になるため、
一気にタイムアウト領域に入ります。

---

まとめ

企業システム間のデータ連携で定番の HULFT（ハルフト）。
日次バッチや帳票ファイルの受け渡しで使っていると、「転送が遅いのでは？」と感じることもあるでしょう。

この記事では、HULFTの転送速度の目安と、大容量ファイルを高速・安定的に送信するためのチューニング術をまとめます。
さらに、WinSCP や AWS CLI との比較も紹介します。

---

1. HULFTの転送速度の目安

HULFT自体は内部的に64bit整数でファイルを扱えるため、理論的な制限はほぼありません。
実際の速度は ネットワーク帯域 × HULFTの処理オーバーヘッド に左右されます。

📊 ファイルサイズ別の目安（1Gbps環境・実効70〜80%の場合）

ファイルサイズ	転送時間の目安	備考
100MB	1〜2秒	LAN環境なら一瞬
1GB	10〜15秒	WAN越しだと数分に延びることも
5GB	1〜2分	S3の1オブジェクト上限(5TB)には余裕あり

💡 100Mbpsの回線では、1GB送信に2分前後かかります。
つまり「回線帯域の影響が支配的」と言えます。

---

2. 回線速度ごとの目安

HULFTのオーバーヘッド込みで実効値を 70〜80% と仮定した場合の目安です。

回線速度	理論値	実効値(目安)	1GB転送時間
1Gbps回線（LAN内）	125MB/s	90〜100MB/s	約10〜12秒
100Mbps回線（VPN/クラウド接続）	12.5MB/s	8〜10MB/s	約100〜120秒（2分程度）
50Mbps回線（遅めのVPN）	6.25MB/s	約5MB/s	約200秒（3〜4分）
10Mbps回線（制限回線など）	1.25MB/s	約1MB/s	約15〜20分

チューニングで改善できるのは「オーバーヘッド部分」ですが、根本は回線速度に依存します。

---

3. HULFTと他の手段の速度比較

同じ回線での「体感スピード」の比較イメージです。

手段	転送速度の傾向	特徴
HULFT	実効70〜80%（安定）	商用の運用性・再送制御が強い。監査/ジョブ連携向き
WinSCP (SFTP/FTP)	実効50〜70%	GUIで扱いやすいが大容量の再送制御は弱め
AWS CLI (S3 cp/sync)	実効80〜90%（並列化可）	高速だがジョブ管理や監査は限定的

特に基幹システム間の「失敗できない転送」ではHULFTが選ばれる理由があります。

---

4. 転送速度に影響する要因

HULFTの転送性能は、次の要素で大きく変わります。

• ネットワーク帯域：1Gbpsか100Mbpsかで10倍以上の差

• HULFTのバッファサイズ：デフォルト64KB → 1MBに拡張すると効率UP

• 再送制御：エラー時の挙動設定によって安定性と速度が変わる

• ファイルシステムのI/O性能：HDDよりSSDの方が有利

• 暗号化や圧縮の有無：CPU負荷が上がると転送速度が落ちる

---

5. 高速化のためのチューニング術

大容量ファイルを送る際に有効なチューニング方法を整理します。

(1) バッファサイズ調整

• パラメータ SEND_BUFFER_SIZE を 1024KB（1MB）程度 に拡張

• WAN越しでもスループットが改善

(2) マルチパートアップロード（S3利用時）

• HULFT Storage Option では 並列転送 に対応

• 1GBクラスなら1パートで十分だが、数GB以上なら 4〜8並列 に設定すると効果大

(3) 部分再送を有効化

• 転送途中で中断しても 途中から再開 できる

• WAN経由や夜間バッチでの安定性向上に必須

(4) 圧縮の利用

• CSVやテキストは圧縮転送で大幅短縮

• バイナリ（PDFやZIP）は圧縮効果が薄い

(5) ネットワーク調整

• TCPウィンドウサイズやNIC送信バッファを拡張

• Linux例：

  net.core.wmem_max=16777216
  net.ipv4.tcp_wmem=4096 87380 16777216

---

6. 運用上の工夫

速度チューニングだけでなく、運用面でも工夫が必要です。

• ピーク時間を避けてスケジューリング（夜間バッチに実行）

• 再送回数を3回程度に設定し、エラー時のリカバリを自動化

• ログ監視（HULFTの送受信ログ＋S3側のCloudWatch）で転送成功を二重確認

• 日付付きファイル名で履歴管理を容易に

---

まとめ

• HULFT自体は大容量に強く、理論上は数TB〜EBまで対応可能

• 実効速度は 回線帯域 × バッファ調整 × 再送設定 がカギ

• 100MBなら数秒、1GBなら十数秒〜数分 が目安

• HULFTは最高速よりも「確実性・運用性」を重視する製品

• バッファ拡張・並列化・部分再送 で安定高速な運用が可能