帯域幅最適化のコツ：ファイル転送を高速化

アップロード帯域幅を最大限に活用するには 4 つのことを行いましょう。 Wi-Fi ではなくギガビットイーサネットで有線化する、ルーターで QoS または SQM をオンにしてバッファブロートを抑え込む、 ISP がサポートする場合は IPv6 に切り替える、転送中は Dropbox 、 iCloud 、 Google Drive のようなバックグラウンド同期を一時停止する。実際の転送中に 180 Mbps しか出ていない 500 Mbps アップロードでは、これら 4 つの変更を組み合わせることで通常 200〜280 Mbps の使用可能なスループットを取り戻し、 10 GB 転送を 45 分から 15 分未満に短縮できます。

大容量ファイルには Wi-Fi を忘れて有線接続にする

Wi-Fi 6（802.11ax）はアクセスポイントから 1.5 メートルの良好な 2x2 クライアントで、実世界スループットの上限は約 600 Mbps です。 Wi-Fi 5（802.11ac）は約 300 Mbps 前後に位置します。壁を挟んだ隣の部屋ではこれらの数値が 40〜60% 低下します。ギガビットイーサネットは 940 Mbps を一貫して、 1 ms 未満のジッターで提供します。

2,000 円程度の USB-C to ギガビットイーサネットアダプターは、 2 GB を超えるアップロードでほとんどのノートパソコンの内蔵 Wi-Fi を上回ります。ケーブルを通せない場合は、少なくとも 5 GHz 帯に切り替え、ルーターから見通しの良い場所に移動しましょう。 2.4 GHz は実条件で 60〜80 Mbps で頭打ちになり、ファイル転送には不向きです。

QoS と SQM ：バッファブロートの治療

バッファブロートは、家の誰かがアップロードを開始した瞬間に Zoom 通話が遅延する原因です。従来のルーターバッファは、飽和したリンクで数秒間パケットをキューに入れてレイテンシーを破壊します。 CAKE や fq_codel のようなスマートキュー管理（ SQM ）アルゴリズムは負荷下でもキューを短く保つため、 500 Mbps アップロードが他のすべてに 300 ms のレイテンシーを追加することはありません。

OpenWrt 、 pfSense 、ほとんどの最新ルーター（ Merlin ファームウェア付き Asus 、 Ubiquiti UniFi 、 eero Pro 6E ）は SQM をサポートします。有効化し、上りをプロビジョニングされた速度の約 95% に設定し、 DSLReports または Waveform のバッファブロートテストが F 評価から A+ に改善するのを確認しましょう。

これは帯域幅を追加しませんが、バッファブロートが TCP 送信者に繰り返し後退させるときに生じる 40〜60% のスループット損失を取り除きます。

IPv6 は通常より速い

デュアルスタックをサポートする ISP では、 IPv6 が主要なクラウド宛先へよりダイレクトにルーティングされることがよくあります。 AWS 、 Google Cloud 、 Cloudflare 、 Azure はすべてネイティブ IPv6 を実行しており、 IPv6 上のパケットはモバイルや一部の家庭用ネットワークで一般的な IPv4 CGNAT パスと比べて 1〜2 の NAT ホップをバイパスします。

ipv6-test.com または test-ipv6.com で確認しましょう。 10/10 をスコアするなら、利用可能な場所で既に IPv6 を使用しています。そうでない場合はルーターで有効にしましょう（ほとんどの ISP は DHCPv6 または PPPoE を通じて設定を自動的にプッシュします）。大陸間アップロードでの差は 20〜40% にもなり得ます。

バックグラウンドで同期するものをすべてオフにする

Dropbox 、 Google Drive 、 OneDrive 、 iCloud Photos 、ネットワーク経由の Time Machine 、 Backblaze のようなバックアップツールはすべて、アップロード帯域幅を静かに消費します。 macOS のアクティビティモニタ（ネットワークタブ、「送信バイト」でソート）と Windows のリソースモニターが犯人を明らかにします。

大容量転送の前に一時停止しましょう。 iCloud Photos は特に、撮影をインポートした後に静かにギガバイトをプッシュできます。 Backblaze のデフォルトスロットルは「自動」で、アイドル接続で「利用可能なすべてを消費する」を意味します。

1080p の Zoom 通話は約 3 Mbps の上りを使用します。 Google Meet の HD 通話は約 2.5 Mbps です。家の誰かがビデオ通話中なら、その前後に転送をスケジュールするか、 2〜3 Mbps の低下を受け入れましょう。

DNS と最初のバイト時間

設定ミスの DNS は、 TCP 接続が始まる前に 50〜200 ms のレイテンシーを追加できます。まだ ISP のデフォルトリゾルバーを使用しているなら、 Cloudflare の 1.1.1.1 または Google の 8.8.8.8 を試しましょう。 dig +stats transfer-service.com を使って応答時間を比較してください。多くの接続を開くチャンクアップロードでは、高速リゾルバーが全体のスループット向上に複利で効いてきます。

macOS では、システム設定 → ネットワーク → 詳細 → DNS で変更します。 Windows 11 では、設定 → ネットワークとインターネット →（アダプター）→ DNS サーバー割り当ての編集です。

特殊なネットワークでの MTU 調整

VPN 、 PPPoE DSL 接続、またはセルラー上り回線では、 MTU がデフォルトの 1,500 バイトより低い可能性があります。サイズ違いの MTU は TCP のフラグメンテーション、再送信、スループット崩壊を引き起こします。 macOS/Linux では ping -s 1472 -D google.com、 Windows では ping -f -l 1472 google.com でテストしましょう。パケットが返らない場合、返ってくるまで 10 バイトずつ MTU を下げ、その値（プラス ICMP オーバーヘッド 28 バイト）をインターフェース MTU として設定します。

一般的な動作値：ほとんどのブロードバンドで 1,500、 PPPoE DSL で 1,492、一部の WireGuard VPN で 1,428、ほとんどの 5G キャリアで 1,400。

輻輳制御：BBR 対 Cubic

クラウドにアップロードする Linux システムでは、 TCP 輻輳制御を Cubic から BBR（Bottleneck Bandwidth and RTT）に切り替えると、高遅延でわずかに損失のあるリンクでスループットを倍にできます。sysctl -w net.ipv4.tcp_congestion_control=bbr で有効化します。 macOS と Windows はデフォルトで Cubic ベースのアルゴリズムを使用しており、このパラメーターを簡単には公開していませんが、クラウドホスト型の転送エンドポイントが増加してサーバー側で BBR を実行しており、クライアント側でなくても効果があります。

これが Google Cloud で動くサービス（ Smash 、一部の SwissTransfer トラフィック）がレガシーホストの同一サービスよりしばしば速く感じる理由の一つです。

ブラウザの選択が重要な理由

Chromium ベースのブラウザ（ Chrome 、 Edge 、 Brave 、 Arc ）はデフォルトで HTTP/3 と QUIC をサポートし、損失の多いリンクで HTTP/2 over HTTPS を 15〜25% 上回ります。 Firefox も QUIC を搭載しています。 Safari 17+ は HTTP/3 をサポートしますが、一部のサービスではデフォルトで HTTP/2 になります。 DevTools の Network パネル「プロトコル」列で確認しましょう。

転送サービスのアップロードエンドポイントが HTTP/3 で配信される場合、ブラウザがそれを採用すれば、チャンクあたりのハンドシェイク往復が減少し、 4〜8 の同時ストリームを開く並列アップロードに効果的です。

パイプを活かせるサービスを選ぶ

一部の転送サービスは、どれだけ帯域幅があってもアップロードを制限します。 50 Gbps 対応の回線でも、転送あたりのスループットを 30 Mbps に制限するツールを通すと速度が落ちます。 HexaTransfer は Web Workers で AES-256-GCM 暗号化を使い、 HTTP/2 上で並列にチャンクをストリーミングするため、転送あたり 10 GB 上限まで、接続が実際に提供できる速度でアップロードが進みます。

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