並列アップロード技術：転送帯域幅を最大化

並列アップロードはファイルをチャンク（通常 5 MB から 100 MB ）に分割し、複数の同時 TCP 接続にプッシュすることで、単一ストリームが高遅延リンクで打ちあたるスループットの天井を回避します。 Amazon S3 マルチパートアップロード、 Google Cloud Storage 再開可能アップロード、 tus.io はすべてこれを実装しています。 1 Gbps 回線で宛先サーバーへの遅延が 80 ms ある場合、単一の HTTP PUT は通常 150 Mbps で飽和しますが、 8 並列ストリームは 900 Mbps を超えてプッシュできます。仕組みを理解すれば、この効果は現実的かつ予測可能です。

1 ストリームでは不十分な理由

TCP の輻輳制御は、未確認データをどれだけ飛行中に保持するかを決めるためにスライディングウィンドウを使用します。太く高遅延のパイプでは、デフォルトのウィンドウサイズ（ Linux 5.x では約 16 MB、古いカーネルでは少ない）が ACK の返送前に埋まり、送信者は待機するだけになります。これが「帯域幅遅延積」問題で、パリからシンガポールのサーバーへの単一 FTP 転送がギガビット回線でも 30 Mbps 前後で頭打ちになる理由です。

複数の並列接続を実行することで、各接続が独自のウィンドウを得るためこの問題を回避できます。 30 Mbps の 8 ストリームは 240 Mbps に加算され、さらに CDN エッジ選択が異なる入口を通じてルーティングすることでさらに効果が出ます。

チャンク化：サイズと数の決め方

最適点はレイテンシーとパケットロスに依存します。 RTT が 50 ms 未満の同一大陸転送には、 4 並列ワーカーで 10 MB チャンクがほとんどの一般向け回線を飽和させます。大陸間または損失の多いモバイルリンク（ RTT 100 ms 超、パケットロス 0.5% 超）には、 5 MB チャンクと 8〜16 ワーカーに落としましょう。

S3 のマルチパート API は、パートあたり最小 5 MB（最後のパートを除く）、パートあたり最大 5 GB 、アップロードあたり最大 10,000 パートを必要とします。これは理論上の上限をオブジェクトあたり約 48.8 TB に設定します。 Google Cloud Storage は複合あたり 32 パートを許可し、最大 1 週間持続する再開可能セッション URI をサポートします。 Azure Blob ブロック BLOB は 4,000 MiB で最大 50,000 ブロックを受け入れます。

ブラウザベースの転送では、 100 MB を超えるチャンクは既にロードされているタブの RAM にストレスを与え始めるため、ほとんどのウェブ UI は 5 MB から 20 MB の間に留まります。

再開可能アップロード：静かなスーパーパワー

チャンクアップロードは再開機能を解放します。 120 チャンク中 47 番で Wi-Fi が切れた場合、ゼロから再起動するのではなく、チャンク 48 から再開します。 tus.io プロトコル（現在バージョン 2.0 のオープン標準）は、 Upload-Offset と Upload-Length ヘッダーを使用し、 HEAD リクエストでアップロードオフセットを問い合わせ、 PATCH リクエストで追加することで、これを形式化しています。

Google Drive の再開可能アップロード API は 7 日間持続するセッション URI を使用します。ノートパソコンをクラッシュさせ、再起動し、タブを再び開いて、まさに止まったところから再開できます。これが使える 10 GB 転送とコイン投げの違いです。

クライアント側暗号化が計算を変える

エンドツーエンド暗号化転送サービスは、送信前に各チャンクをクライアント側で暗号化する必要があります。最新のノートパソコン CPU で 500 MB/s の AES-256-GCM はボトルネックではありませんが、順序が重要です。チャンクを暗号化し、チャンクをアップロードし、次のチャンクを暗号化します。ここではワーカープールでのパイプライン化が重要です。素朴な実装は暗号化とアップロードを直列化して実効スループットを半分にカットします。適切な実装では、 2〜4 の暗号化ワーカーが境界付きキューを通じて 4〜8 のアップロードワーカーに継続的に供給します。

これが HexaTransfer が並列 XHR プールと一緒に Web Workers で AES-256-GCM 暗号化を実行する理由です。これにより、暗号処理でストールすることなく、 10 GB 上限がブラウザ内で実際に到達可能になります。

バックプレッシャーとサーバー側の制限

並列処理が多いほど常に速いわけではありません。受信サービスが IP あたりレートリミットしている場合（ CloudFront ではディストリビューションあたり毎秒 25,000 リクエストが一般的）、 32 の同時チャンクをプッシュすると 503 Slow Down 応答がトリガーされます。 HTTP/2 は単一 TCP 接続で多重化するため助けになりますが、多くの CDN はまだエッジで HTTP/2 を終端してオリジンに HTTP/1.1 でファンアウトするため、実効並列処理はエッジ設定に依存します。

過剰並列化の前にテストしましょう。 8 ワーカーはほぼ常に安全です。 16 はクラウドオブジェクトストアがクリーンに受け入れる上限です。 32 は節約より多くのコストの再試行を生み始めます。

知っておくべきブラウザの制限

Chrome と Firefox は HTTP/1.1 ではオリジンあたり同時接続を 6 に制限し、 HTTP/2 では実質的に無制限です。転送サービスがまだ HTTP/1.1 の場合（稀ですが、一部のレガシーサービス）、並列処理の天井はワーカーをいくつ起動しても 6 です。 DevTools の Network パネルの「Waterfall」列でキューに入っているリクエストが積み重なるのを確認できます。

iOS 17 以降の Safari は 6 並列 XHR をクリーンに処理しますが、約 1.5 GB の RAM 圧力でバックグラウンドタブの追い出しを開始します。これはチャンクアップロードバッファに影響します。

並列アップロードが役に立たないとき

非対称家庭用接続（典型：1 Gbps ダウン、 40 Mbps アップ）では、サーバーの取り込みではなくアップロードがボトルネックです。 40 Mbps のパイプを通じて 5 MB の 8 並列ストリームをプッシュしても、 40 Mbps の 1 ストリームより速くなりません。並列処理が効果的なのは、単一ストリームの天井がパイプの容量より低い場合です。すでにリンクを飽和させているときには違います。

同じことはモバイル回線でも起きます。 LTE のバーが 1 本しかないなら、追加ワーカーはほとんど再送信を生み出すだけです。

サービスで確認すべき三点

頻繁に大きなファイルを扱う転送ツールを選ぶなら、三点を確認しましょう。再開可能なチャンクアップロードをサポートするか、ウェブ UI が何の並列ワーカーを実行するか、エッジに対して HTTP/2 または HTTP/3 を使うか。三点すべてに当てはまるサービスは、まずまずの接続で 10 GB ファイルを数分で転送できます。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。