Glossaire

Fichiers, téléchargements et transferts

La plupart de ce qui semble arbitraire dans les fichiers sur iPhone découle d’une seule règle d’isolation, et la plupart de ce qui rend les téléchargements fiables découle d’une seule fonction de HTTP. Voici les deux, plus les façons dont les fichiers passent d’un appareil à un autre.

Bac à sable

La règle qui veut que chaque app ne voie que son propre stockage. C’est pour ça qu’une app ne peut pas ouvrir les téléchargements d’une autre, et que « le fichier est à côté de la vidéo » n’existe pas sur iOS.

Chaque app reçoit un dossier privé — son bac à sable, ou sandbox — et aucune vue sur celui des autres. Les fichiers ne circulent entre apps que par des gestes délibérés — une feuille de partage, un sélecteur de documents, un glisser-déposer — dont chacun est une décision de la personne, pas un service qu’une app s’est rendu toute seule.

Le coût se paie dans les petits détails. Sur ordinateur, les lecteurs trouvent film.srt à côté de film.mkv automatiquement ; sur iOS il n’y a pas d’« à côté », donc un fichier de sous-titres doit être transmis exprès, et c’est à l’app de se souvenir de l’association.

Voir aussi : Groupe d’appsSignet à portée de sécurité

Groupe d’apps

Un conteneur partagé — un app group — que deux apps du même développeur peuvent ouvrir toutes les deux, et la seule brèche autorisée dans le bac à sable. C’est ainsi qu’une extension de partage remet un fichier à l’app à laquelle il est destiné.

Une extension de partage est un programme distinct de l’app dont elle a l’air de faire partie, avec son propre bac à sable et une vie très courte. Elle ne peut pas écrire dans le stockage de l’app principale.

Elle écrit donc dans un conteneur que les deux ont le droit de voir, et l’app vide ce conteneur à sa prochaine ouverture. Rien ne franchit la frontière d’un développeur, et rien ne passe sans un appui explicite.

Voir aussi : Bac à sable

Signet à portée de sécurité

Un security-scoped bookmark : un jeton qui mémorise l’autorisation d’accès à un dossier hors du bac à sable — un disque externe, un dossier dans iCloud — pour que l’app puisse le rouvrir plus tard sans redemander.

Quand tu choisis un emplacement dans le sélecteur de fichiers du système, l’autorisation accordée vaut pour ce moment-là. Un signet la conserve d’un lancement à l’autre, et l’app doit explicitement commencer puis arrêter d’utiliser l’accès qu’il représente.

C’est ce qui rend possible de parcourir un SSD externe sans rien copier, et sa portée est exactement ce que tu as choisi — un signet vers un dossier n’accorde rien sur son voisin.

Voir aussi : Bac à sable

Requête de plage

Demander à un serveur une tranche précise d’un fichier — les octets 5 000 000 à 5 999 999 — au lieu du fichier entier. C’est ce qui rend un téléchargement reprenable et ce qui permet à plusieurs connexions de récupérer un même fichier.

Un serveur qui gère les plages répond 206 Partial Content et envoie la tranche demandée. Un serveur qui ne les gère pas répond 200 et renvoie tout depuis le début, et c’est toute la différence entre reprendre un téléchargement et le recommencer.

Tout ce qui est intéressant dans un moteur de téléchargement repose sur cette unique fonction de HTTP. Sans elle, pas de reprise après une coupure, pas de reprise après un redémarrage, et aucun moyen d’utiliser plus d’une connexion.

Voir aussi : Téléchargement reprenableConnexions parallèles

Téléchargement reprenable

Un transfert qui repart exactement d’où il s’est arrêté plutôt que de recommencer, en notant combien d’octets sont bien écrits et en demandant le reste.

L’exigence, c’est que le nombre noté ne soit jamais optimiste. Un octet compté comme écrit mais encore posé dans un tampon devient un trou dans le fichier quand l’app est tuée — et un trou au milieu d’une vidéo est une corruption qui n’apparaît qu’une heure après le début du visionnage.

C’est pour ça que le compteur doit suivre l’écriture sur le disque plutôt que la lecture depuis le réseau, et pourquoi chaque passage de relais entre transfert au premier plan et transfert en arrière-plan doit s’accorder sur un seul nombre.

Voir aussi : Requête de plageTransfert en arrière-plan

Connexions parallèles

multi-connexion, téléchargement par morceaux

Découper un fichier en plages et en récupérer plusieurs à la fois. Ça aide quand une seule connexion est bridée, et ça ne sert strictement à rien quand le goulot d’étranglement est ta propre ligne.

Un serveur qui plafonne la vitesse de chaque connexion peut souvent être amené à livrer davantage au total sur plusieurs. C’est là que le téléchargement multi-connexion gagne sa réputation.

Ce n’est pas magique et c’est souvent mal compris. Si ta connexion est déjà saturée, plus de connexions ne font que découper la même capacité en parts plus petites et ajouter de la surcharge. Certains serveurs refusent aussi ou brident plusieurs requêtes venant d’une même adresse.

Voir aussi : Requête de plageTéléchargement reprenable

Transfert en arrière-plan

Un téléchargement confié au système d’exploitation pour qu’il continue après la fermeture de l’app. C’est le système qui décide du rythme : c’est le prix à payer pour qu’il continue tout court.

Une app iOS cesse de tourner peu après que tu l’as quittée. Un transfert confié au service d’arrière-plan du système survit à ça, survit à l’app tuée, et reprend après un redémarrage.

Ce qu’il abandonne, c’est le contrôle. Le système regroupe ces transferts selon sa propre lecture de la batterie et du réseau, donc un téléchargement en arrière-plan peut se mettre en pause et repartir comme un téléchargement dans l’app ne le ferait pas — et il ira au bout.

Voir aussi : Téléchargement reprenableBac à sable

WebDAV

Une extension de HTTP qui transforme un serveur web en serveur de fichiers : lister, lire, écrire, déplacer, supprimer. C’est ce que parlent Nextcloud et ownCloud, et ce que proposent la plupart des NAS.

Comme c’est du HTTP en dessous, WebDAV passe par la même infrastructure que tout le reste du web — pas de port particulier, pas de protocole client spécial — et c’est pour ça qu’il a survécu là où des protocoles de fichiers plus élaborés ont disparu.

Pour qui préfère ne pas mettre ses fichiers dans le cloud d’une entreprise, c’est l’alternative pratique : ton propre serveur, tes propres identifiants, des standards ordinaires.

Voir aussi : Stockage cloud

Stockage cloud

Des fichiers gardés sur le serveur de quelqu’un d’autre, atteints via l’API de cette entreprise — Dropbox, OneDrive, Box, pCloud. Chacune a sa propre interface, et c’est pour ça que les apps les prennent en charge une par une.

Il n’existe pas de protocole cloud universel. Chaque fournisseur a conçu sa propre API et son propre parcours de connexion, donc ajouter un fournisseur à une app est un vrai travail, pas une ligne de configuration.

La connexion passe normalement par OAuth, ce qui veut dire que l’app ne voit jamais le mot de passe : le fournisseur authentifie la personne et renvoie un jeton révocable à tout moment depuis ses propres réglages.

Voir aussi : WebDAV

WebRTC

Un standard pour connecter deux appareils directement, sans serveur entre eux une fois la connexion établie. C’est ce qu’utilise le transfert d’appareil à appareil pour envoyer un fichier à l’autre bout de la pièce.

Un petit serveur de signalisation présente les deux appareils l’un à l’autre — c’est à ça que sert le code à six chiffres — puis se retire. Le fichier voyage directement entre les appareils et n’est stocké nulle part entre les deux.

Sur le même réseau, c’est aussi rapide que ce réseau le permet. À travers internet, ça dépend de la possibilité de joindre directement les deux côtés, et c’est là que des connexions échouent parfois pour des raisons qu’aucun des deux appareils ne voit.

Voir aussi : Serveur HTTP local

Serveur HTTP local

Une app qui répond à des requêtes web sur ton propre réseau, pour qu’un navigateur web sur ton ordinateur puisse ouvrir une page servie par ton téléphone. C’est le fonctionnement du Transfert Wi-Fi, sans câble et sans compte.

Le téléphone affiche une adresse ; l’ordinateur l’ouvre ; la page qu’il reçoit est servie par le téléphone lui-même. Les fichiers passent directement par le réseau local et ne le quittent jamais.

Comme n’importe qui sur le même réseau peut atteindre cette adresse, il lui faut un verrou : un code à saisir, des autorisations accordées opération par opération, et les actions destructrices désactivées sauf si tu les actives délibérément.

Voir aussi : WebRTC

Les autres sujets

Vidéo et codecs Streaming et IPTV Confidentialité et chiffrement Tous les termes