Français

Vidéo et sous-titres · Téléchargeur multimédia direct

Taille des téléchargements multimédias volumineux dans la mémoire du navigateur : flux, blobs et limites

· Comment ça marche

téléchargements performances de Navigateur navigateur

Morceaux de médias accumulés dans un blob de navigateur limité à côté d'une jauge de mémoire
Illustration vectorielle originale de ToolAcre

ToolAcre indique que la limite de taille correspond à la mémoire de votre appareil plutôt qu'à une limite de téléchargement. Cet article explique ce que cela signifie pour un téléchargement direct : comment les corps de réponse sont lus, où se trouvent les octets et quand un onglet du navigateur manque de place.

Le fichier fait plusieurs gigaoctets et le téléchargement s'arrête à mi-chemin – le problème que les limites de mémoire provoquent pour les téléchargements côté navigateur

Un long enregistrement peut avancer régulièrement, puis s'arrêter, car la sauvegarde côté navigateur nécessite de l'espace pour les morceaux reçus et le Blob terminé. Un pourcentage de blocage à lui seul ne peut pas diagnostiquer la cause : le réseau peut s'arrêter, l'hôte peut fermer la connexion, l'annulation peut se déclencher ou le processus peut approcher la pression de la mémoire.

ToolAcre rend une frontière déterministe. `downloadMedia` par défaut est un maximum de 2 GiB et refuse une longueur de contenu déclarée plus grande avant de lire le corps. Si l'hôte omet ou sous-estime cet en-tête, la même limite est à nouveau appliquée à mesure que les fragments arrivent, empêchant ainsi un accumulateur illimité. Une valeur déclarée proche de la limite mérite prudence, car l’assemblage de Blob, l’état de la page et la surcharge de mise en œuvre peuvent nécessiter plus de ressources que ne le suggère la charge utile de la réponse.

Comment un corps de réponse est lu : morceaux ReadableStream par rapport à un gros tampon – ce que fait le navigateur pendant que la progression s'accélère

Fetch expose le corps de la réponse en tant que ReadableStream lorsque le navigateur en fournit un. L’implémentation obtient un lecteur, attend les morceaux, compte chaque `Uint8Array`, met à jour la progression et stocke les morceaux pour la construction finale du Blob. Le streaming rend les progrès et les annulations réels ; cela ne rend pas le stockage constant.

Lorsque Content-Length est une valeur finie positive, l'interface peut afficher les octets reçus par rapport à un total. Sans cela, l'affichage rapporte les octets reçus mais refuse d'inventer un pourcentage. Si aucun corps lisible n'existe, le code revient à `response.blob()` et indique uniquement la taille finale. Chaque morceau conservé rend possible un assemblage ultérieur, alors qu'une véritable conception de streaming sur disque nécessiterait une API de navigateur, un modèle d'autorisation et une stratégie de défaillance différents, non présentés ici.

Où se trouve le Blob terminé et pourquoi aucune promesse de stockage du navigateur n'est sûre

Le Blob collecté est un objet de navigateur représentant des octets immuables avec une étiquette MIME. La spécification ne garantit pas si un navigateur particulier conserve chaque octet de sauvegarde dans la RAM, diffuse certaines données ou duplique les tampons lors de l'assemblage. Les orientations relatives aux articles devraient donc éviter une revendication universelle d’emplacement de stockage.

Ce que l'application prouve, c'est qu'elle conserve les références de fragments jusqu'à la fin du flux, puis construit un Blob et le garde disponible pour l'action Enregistrer sur votre appareil. Cet ensemble de travail est en concurrence avec la page et les autres onglets, de sorte que les conditions de l'appareil et du navigateur restent des contraintes pratiques inférieures au plafond explicite. Cette distinction est la raison pour laquelle la documentation mentionne la pression des ressources plutôt que de promettre un multiplicateur de RAM spécifique, un seuil de débordement de disque ou une technique d'allocation dépendant du navigateur.

Pourquoi il n'y a pas de limite de téléchargement, mais il existe une protection de téléchargement de 2 Gio

Aucun fichier n'est téléchargé sur ToolAcre et aucun relais ne reçoit le média. Le GET se déplace du navigateur du visiteur vers l’hôte fourni. Cela supprime un quota de téléchargement sur le serveur, mais cela ne signifie pas « illimité » : la source impose un maximum de deux gibioctets et indique aux tâches plus volumineuses d'utiliser le lien de sauvegarde natif à la place.

L'hébergeur peut annoncer une taille excessive via Content-Length, permettant un refus anticipé. Il peut également diffuser sans longueur, auquel cas ToolAcre compte les morceaux réels et s'arrête une fois la limite franchie. Les octets partiels ne sont pas proposés sous forme de téléchargement tronqué après cet échec. Les contrôles précoces et continus couvrent les en-têtes de longueur véridiques et absents, tandis qu'un petit en-tête inexact n'est détecté que lorsque le corps mesuré dépasse le même plafond.

Exemple concret : un long enregistrement de cours sur un ordinateur portable avec une RAM limitée : à quoi s'attendre et comment détecter la pression de la mémoire en cas de blocage du réseau

Imaginez un fichier de cours sur un ordinateur portable exécutant déjà un éditeur et de nombreux onglets. Appuyez d'abord sur Vérifier le lien et comparez la taille indiquée avec la protection. Pendant le téléchargement, des mises à jour régulières d'octets sans total signifient que l'hôte a omis une longueur utilisable ; une ligne de demande gelée peut à la place afficher une pause de transport.

La pression de la mémoire peut affecter l'onglet même lorsque la requête reste active, mais ToolAcre ne peut pas inspecter le système d'exploitation et déclarer une cause. Les outils de tâches du navigateur, les vues de la mémoire système et la chronologie des requêtes fournissent des preuves complémentaires. Réessayer aveuglément peut répéter la même demande d’allocation. Si la requête se termine par un statut HTTP, étudiez d'abord cette réponse ; la pression de la mémoire n'est pas une explication par défaut utile pour chaque transfert important interrompu.

Habitudes pratiques : fermer les autres onglets et télécharger un fichier à la fois – comment donner à l'onglet l'espace dont il a besoin

Fermez les onglets lourds sans rapport avant de démarrer un transfert proche de la limite, gardez un travail volumineux actif à la fois et évitez d'effacer le résultat jusqu'à ce que l'action de sauvegarde ait commencé. Ces habitudes réduisent la concurrence mais n'augmentent pas le maximum codé ni ne garantissent le succès sur un appareil contraint.

Vérifier en premier est utile lorsque l'hôte fournit Content-Length, mais une valeur manquante signifie « inconnu » et non « petit ». Surveillez le compteur d'octets bruts et annulez si le transfert n'est pas l'actif attendu. L'annulation supprime le fichier partiel et libère le verrou du lecteur plutôt que de présenter les octets incomplets comme un succès. L'enregistrement rapide réduit également la durée pendant laquelle le Blob prêt reste accessible dans l'état de la page, bien que JavaScript ne puisse pas promettre le moment exact où un navigateur récupère le stockage de sauvegarde.

Ce que cela ne couvre pas : reprise d'un téléchargement interrompu, division d'un fichier en plusieurs parties ou téléchargements dépassant ce que l'appareil peut contenir

Ce chemin n'émet pas de requêtes de plage, ne reprend pas un transfert interrompu, ne divise pas la sortie en parties, ne diffuse pas directement vers un descripteur de fichier sélectionné par l'utilisateur ou ne planifie pas de file d'attente. Bien qu'une réponse HEAD indique si les plages d'octets semblent prises en charge, le téléchargeur ne transforme pas ce résultat d'avertissement en comportement de reprise.

Les fichiers au-delà de la protection appartiennent à un téléchargement dans un navigateur natif, à un client de ligne de commande autorisé ou à un autre flux de travail autorisé qui écrit progressivement sans conserver l'intégralité du résultat pour l'enregistrement Blob. Ce choix concerne l'architecture de la mémoire et non une solution de contournement pour la connexion, CORS, DRM ou les restrictions de droits. Un client pouvant être repris peut être plus approprié pour les connexions peu fiables, mais uniquement lorsque la source du fichier et l'autorisation permettent à ce client d'accéder à la même ressource.

À retenir : la protection explicite et la mémoire disponible de l'appareil sont importantes

La déclaration de limite précise comporte deux couches : ToolAcre refuse plus de 2 Gio par défaut, et les transferts plus petits peuvent toujours être limités par les ressources disponibles du navigateur. « Pas de plafond de téléchargement » décrit le relais absent ; ce n'est pas synonyme de taille téléchargeable infinie.

Pour les fichiers appropriés, le lecteur de blocs fournit une progression véridique, un AbortController fournit une annulation et la création de Blob fournit un résultat enregistrable. Direct Media Downloader conserve les octets sur la route directe hôte-navigateur tout en reconnaissant qu'un onglet de navigateur est un espace de travail délimité. Les deux limites doivent être planifiées ensemble avant le début du transfert, en particulier sur les ordinateurs portables ou les appareils mobiles gérés où les ressources disponibles peuvent évoluer rapidement.