ファイル・ダウンロード・転送
iPhone上のファイルにまつわる、一見理不尽に思えることのほとんどは、隔離に関するたった一つの規則から生まれています。そしてダウンロードを信頼できるものにしている要素のほとんどは、HTTPのたった一つの機能から生まれています。ここではその両方に加え、ファイルがあるデバイスから別のデバイスへ渡る方法を扱います。
-
サンドボックス
-
各アプリは自分のストレージしか見られないというルール。あるアプリが別のアプリのダウンロードを開けない理由であり、「ファイルが動画の横にある」という状態がiOSに存在しない理由でもあります。
どのアプリにも専用のディレクトリが割り当てられ、他の誰のものも見えません。ファイルがアプリ間を移動するのは、共有シート・書類選択・ドラッグといった意図的な操作を通じてだけであり、それぞれがアプリが勝手に取り込んだのではなく、人が下した判断です。
その代償は細部に表れます。デスクトップのプレーヤーは同じフォルダーにある
film.srtをfilm.mkvの横にあるものとして自動的に見つけますが、iOSには「横にある」という概念自体が存在しません。そのため字幕ファイルは意図的に渡す必要があり、その組み合わせを覚えておくのもアプリ自身の役目になります。以下も参照してください。 アプリグループセキュリティスコープ付きブックマーク
-
アプリグループ
-
同じ開発者による2つのアプリが両方とも開ける共有コンテナ——サンドボックスに許された唯一の抜け道です。共有エクステンションがファイルを、それが本来属するアプリへ渡す仕組みがこれです。
共有エクステンションは、一見あるアプリの一部のように見えても実際には別のプログラムで、独自のサンドボックスを持ち、動作時間も非常に短いものです。メインアプリのストレージへ直接書き込むことはできません。
そこで、両者が見ることを許されたコンテナへ書き込み、アプリは次に開いたときにそのコンテナから受け取ります。開発者の境界を越えるものは何もなく、明示的なタップなしに越えるものも何もありません。
以下も参照してください。 サンドボックス
-
セキュリティスコープ付きブックマーク
-
サンドボックスの外にあるフォルダー——外部ドライブやiCloud内のフォルダーなど——へのアクセス許可を記憶しておくトークン。これにより、アプリは後で改めて許可を求めずにそのフォルダーを再び開けます。
システムのファイル選択画面である場所を選んだとき、与えられる許可はその瞬間限りのものです。ブックマークはそれをアプリの再起動をまたいで保持し、アプリはそれが表す権限の使用を明示的に開始・終了する必要があります。
これがあるおかげで、外部SSDを何もコピーせずに参照できます。そしてその範囲はあなたが選んだものにきっちり限定されます——あるフォルダーへのブックマークは、その隣のフォルダーについて何も許可しません。
以下も参照してください。 サンドボックス
-
範囲リクエスト
-
ファイル全体ではなく、その一部——たとえば5,000,000〜5,999,999バイト目——だけをサーバーに要求すること。これがダウンロードを再開可能にし、複数の接続で1つのファイルを同時に取得できるようにしています。
範囲リクエストに対応しているサーバーは206 Partial Contentで応答し、要求された部分だけを返します。対応していないサーバーは200で応答し、最初からすべてを送ってきます。これがダウンロードを再開することと、最初からやり直すことの違いです。
ダウンロードエンジンにまつわる面白い話は、すべてこのHTTPのたった一つの機能の上に成り立っています。これがなければ、接続が切れた後の再開も、再起動後の再開も、複数の接続を使う方法もありません。
以下も参照してください。 再開可能なダウンロード並列接続
-
再開可能なダウンロード
-
確定したバイト数を記録し、残りを要求することで、最初からやり直すのではなく止まった場所から正確に続きを行う転送。
ここで求められるのは、記録される数字が決して楽観的であってはならないということです。書き込み済みとしてカウントされていながらまだバッファーに留まっているバイトは、アプリが強制終了された瞬間にファイルの穴になります——動画の途中にある穴は、1時間ほど視聴が進んでからようやく発覚する破損です。
だからこそ、そのカウントはネットワークからの読み取りではなくディスクへの書き込みに追従する必要があり、フォアグラウンドとバックグラウンドの転送が引き継ぐたびに、両者が同じ一つの数字で合意しなければなりません。
以下も参照してください。 範囲リクエストバックグラウンド転送
-
並列接続
マルチコネクション、分割ダウンロード -
1つのファイルを範囲に分割し、複数を同時に取得すること。単一の接続が制限を受けている場合には効果がありますが、ボトルネックが自分の回線そのものである場合にはまったく意味がありません。
各接続の速度に上限を設けているサーバーは、複数の接続に分けることで合計としてより多くを送り出させられることがよくあります。マルチコネクションのダウンロードが評判を得ているのはこの点です。
これは魔法ではなく、しばしば誤解されています。回線がすでに飽和している場合、接続を増やすことは同じ容量をより小さく分割してオーバーヘッドを増やすだけです。一部のサーバーは、同一アドレスからの複数リクエストを拒否したり制限したりもします。
以下も参照してください。 範囲リクエスト再開可能なダウンロード
-
バックグラウンド転送
-
アプリを閉じた後も継続するよう、オペレーティングシステムに引き継がれたダウンロード。タイミングを決めるのはシステム側で、それが継続してもらうための代償です。
iOSアプリは、その場を離れるとまもなく動作を停止します。システムのバックグラウンドサービスに引き継がれた転送はそれを生き延び、アプリが強制終了されても生き延び、再起動後も再開します。
その代わりに手放すのは制御権です。システムは電力やネットワークの状況について自分自身の判断でこれらの転送をまとめて処理するため、バックグラウンドのダウンロードはアプリ内のものとは違う形で一時停止・再開することがあります——ただし必ず完了します。
以下も参照してください。 再開可能なダウンロードサンドボックス
-
WebDAV
-
Webサーバーをファイルサーバーに変えるHTTPの拡張——一覧表示、読み取り、書き込み、移動、削除ができます。NextcloudやownCloudが話す言語であり、たいていのNASボックスが提供しているものです。
内部的にはHTTPそのものであるため、WebDAVはWeb上の他の何もかもと同じインフラの上で動作します——特別なポートも、特別なクライアントプロトコルも不要です。より凝ったファイルプロトコルが淘汰される中で生き残った理由もここにあります。
ファイルを企業のクラウドに置きたくない人にとって、これは現実的な代替手段です——自分自身のサーバー、自分自身の認証情報、ごく普通の標準規格。
以下も参照してください。 クラウドストレージ
-
クラウドストレージ
-
他人のサーバーに保管され、その企業のAPI(Dropbox、OneDrive、Box、pCloudなど)を通じてアクセスされるファイル。それぞれが独自のインターフェースを持つため、アプリは一つずつ個別に対応することになります。
統一されたクラウドプロトコルというものは存在しません。どのプロバイダーも独自のAPIと独自のサインインの流れを設計しているため、あるプロバイダーへの対応を追加することは、単なる設定項目の追加ではなく、実質的な開発作業です。
サインインは通常OAuthで行われます。つまりアプリはパスワードを一切見ません——プロバイダー側が本人確認を行い、いつでもプロバイダー自身の設定から取り消せるトークンを渡してくるだけです。
以下も参照してください。 WebDAV
-
WebRTC
-
接続さえ確立してしまえば、間にサーバーを挟まず2台のデバイスを直接つなぐための標準規格。デバイス間転送が部屋の中でファイルを動かすのに使っているのがこれです。
小さなシグナリングサーバーが2台のデバイスを互いに紹介し合い——6桁のコードはこのためにあります——その後は身を引きます。ファイルはデバイス間を直接移動し、途中のどこにも保存されません。
同じネットワーク内であれば、そのネットワークが許す限りの速さで動きます。インターネット越しでは、両者が互いに直接到達できるかどうかに左右され、どちらのデバイスにも見えない理由で接続がときどき失敗するのもこの部分です。
以下も参照してください。 ローカルHTTPサーバー
-
ローカルHTTPサーバー
-
自分のネットワーク上でWebリクエストに応答するアプリのことで、パソコンのWebブラウザがスマホから配信されたページを開けるようにします。ケーブルもアカウントも不要なWi-Fi転送の仕組みがこれです。
スマホがアドレスを表示し、パソコンがそれを開くと、そこに現れるページはスマホ自身が配信しているものです。ファイルはローカルネットワーク上を直接移動し、その外へ出ることはありません。
同じネットワーク上にいる誰もがそのアドレスへたどり着けるため、何らかの鍵が必要です——入力するコード、操作ごとに与えられる権限、そして意図的に有効にしない限りオフになっている破壊的な操作。
以下も参照してください。 WebRTC