広告:本記事にはアフィリエイト広告が含まれます。
実測日時:2026年10月31日11:22:10〜11:23:08(日本時間)/楽天最強プラン/Rakuten WiFi Pocket 5G/Windows PC・2.4GHz接続
楽天のポケットWi-Fiで、途中まで保存したファイルからダウンロードを再開できるのか。今回は約12.5MBの同じ配信ファイルを使い、先頭1MiBだけ取得したあと、curlの再開機能で残りを取得した。3回ともHTTP 206で再開が完了し、完成ファイルのSHA-256は通常取得したファイルと一致した。
確認できたのは、1つの配信元とcurlの組み合わせで、保存済み部分を使ったHTTPダウンロード再開が成立したことだ。Wi-Fiや携帯回線を突然切る操作は行っていない。4GBを超えるファイル、iTunesの復元、VPNの効果を検証した結果でもない。
実測結果:先頭1MiBからの再開は3/3回、内容も一致
対象はPython.orgが配信するpython-3.13.0-embed-amd64.zip。ファイル全体は12,499,601byte、約12.50MBだった。過去の固定リリースのファイルを転送試験のデータとして利用し、インストールや実行はしていない。新規導入用のバージョンとして勧めるものではない。試験ファイルの公式リリース資料
| 試行 | 先頭1MiBの取得 | 残りの再開取得 | 完成サイズ | 通常取得とのSHA-256比較 |
|---|---|---|---|---|
| 1回目 | 206/0.989秒 | 206/9.507秒 | 12,499,601byte | 一致 |
| 2回目 | 206/1.088秒 | 206/10.927秒 | 12,499,601byte | 一致 |
| 3回目 | 206/1.831秒 | 206/9.330秒 | 12,499,601byte | 一致 |
先に行った通常取得はHTTP 200、12,499,601byteを10.455秒で完了した。続く各試行では先頭の1,048,576byteを新しいファイルへ保存し、そのファイルに残りの11,451,025byteを追記した。先頭部分そのものも、通常取得ファイルの先頭とバイト単位で一致することを確認してから再開した。
表の時間は各curl要求の開始から完了までで、名前解決や接続確立を含む。先頭取得と再開取得の間には約1秒、試行の間には経路確認等があるため、2列を足して利用者の総所要時間とする表ではない。また、通常取得と再開取得の速度の優劣を比較する試験ではない。
「ダウンロードが止まる」という実在の相談が題材
楽天モバイルコミュニティには、2024年5月28日、iPhoneの復元に必要なファイルが約4GBで止まる、という相談がある。投稿者はPocket 2CとiPhoneのテザリングで同様の症状があったとしている。相談の原文:一度のファイルのダウンロード量について
これは投稿者の環境での報告で、現在のPocket 5Gや楽天回線全体の公式仕様として確認したものではない。今回の約12.5MBの試験から、4GBでの制限の有無は判断できない。相談の中に出てくる「途中から再開する」という仕組みに着目し、その部分だけを実機で確かめた。
HTTP 206とContent-Rangeで、どこから取得したか確認
先頭取得ではRange: bytes=0-1048575を要求し、再開時にはcurlの--continue-at -を使用した。curl公式文書によると、この指定は保存先ファイル等から再開位置を自動判断する。今回、再開前のファイルサイズは3回とも1,048,576byteだった。curl公式:–continue-at
| 処理 | 受信したContent-Range(各3回共通) | 取得本文 |
|---|---|---|
| 先頭部分 | bytes 0-1048575/12499601 |
1,048,576byte |
| 保存済み部分の続き | bytes 1048576-12499600/12499601 |
11,451,025byte |
先頭・再開の6要求はすべてHTTP 206だった。今回の応答には、取得した範囲と全体サイズを示すContent-Rangeがあり、再開時に最初から全体を取り直した結果とは区別できる。通常取得を含む7要求でETagとLast-Modifiedも同じだった。
HTTP仕様のRFC 9110ではRangeによる部分取得と206応答が定義される一方、サーバーがRangeを無視する場合も認められている。再開は回線だけで決まる機能ではなく、配信元とクライアントの対応にも依存する。Accept-Rangesの表示だけで将来の再開まで保証されるわけではない。RFC 9110:Rangeと部分取得
サイズだけでなく、完成ファイルの内容も照合した
通常取得したファイルと、再開で完成した3ファイルのSHA-256をローカルで計算した。4ファイルはすべて次の同じ値になった。
01c32d0737432240adcf0bbc1d32327f0976d3a1e1427774bc8febc8f1c03111
これにより、今回のファイルでは同じサイズの別内容や、追記位置のずれがある結果ではなかったことを照合できた。通常取得のMD5も公式リリース資料の掲載値と一致した。MD5はここでは配信ファイルの照合情報として参照し、ソフトウェアの安全性や署名検証の代わりにはしていない。
今回は短時間の固定ファイルで、条件付き再開のIf-Rangeは使っていない。同じURLの内容が変わる配信や、認証・有効期限付きURL、別のダウンロードアプリで同じように再開できるかは試していない。
測定条件・通信量・成功と失敗
Windows 11 Pro、Intel Dual Band Wireless-AC 8265、2.4GHz・802.11n・チャネル6で実施。開始時の送受信リンク速度は144.4Mbps、信号表示は98%、RSSIは−32dBmだった。開始前、各再開試行後、終了時の計5回、同じ楽天ルーターへの接続とIPv4・IPv6の既定経路がWi-Fiであることを確認した。携帯回線側の4G・5Gは未確認だ。
curl 8.21.0、IPv4・HTTPS・HTTP/1.1を使用し、証明書検証は有効。接続待機上限10秒、要求全体上限120秒、取得サイズ上限16,000,000byte、速度制限なしで実施した。この要求に限りプロキシを通さず、自動再試行や転送先への自動追従は行っていない。各要求は別のcurlプロセスで順番に送った。
通常取得1回と、先頭・再開を3組行った計7要求は、すべてcurl終了コード0。時間切れ、HTTPエラー、完成ファイルの不一致は0件だった。これは今回の試行数での結果で、今後の再開成功率を保証するものではない。
取得本文の合計は49,998,404byte(約50.00MB)。通常取得1ファイル分と、先頭・残りを合わせた3ファイル分の合計だ。さらにcurlが記録した応答ヘッダーは4,514byte、要求は1,016byteだった。DNS・TLS、IP・Wi-Fi等の付加情報、PCの他の通信は含めていないため、契約上の総データ使用量ではない。
このPCの背景通信、他の接続機器、基地局や配信CDNの状態は統制していない。ルーターの電源操作や設定変更も行っていない。意図的に範囲を分けた試験であり、突然の切断からの復旧、4GB超、長時間の連続ダウンロード、ブラウザーの再開、iPhone復元は未検証だ。
よくある質問
Pocket 5G経由でダウンロードを途中から再開できた?
今回のPython.org配信ファイルとcurlでは、先頭1MiBからの再開が3/3回成功し、通常取得したファイルとSHA-256が一致した。
4GBで止まる問題がないと分かった?
分かっていない。今回の1ファイルは約12.5MBで、4GB以上の転送やiTunesは試していない。相談の症状を解決した結果ではない。
通信が突然切れても自動で再開できる?
今回は回線を切断せず、先頭範囲の取得後に別のcurl要求で再開した。アプリの自動再試行や、突然の切断後の復旧は未検証だ。
すべてのサイトで再開できる?
保証できない。配信元のRange対応やファイルの同一性、利用するクライアント等に依存する。今回は1つの静的ファイルだけを確認した。
関連する実測レビュー
回線の送受信速度はPocket 5G総合レビュー、接続の途切れを調べた別の試験はPingとHTTPSの約5分観測、通信方式の比較はIPv4・IPv6実測にまとめた。以前の値を今回の新規実測として使っていない。

コメント