Vídeo y subtítulos · Descargador directo de medios
Cómo caben las descargas multimedia de gran tamaño en la memoria del navegador: transmisiones, blobs y límites
· Cómo funciona
descargas rendimiento navegador
ToolAcre dice que el límite de tamaño es la memoria de su dispositivo en lugar de un límite de carga. Esta publicación explica lo que eso significa para una descarga directa: cómo se leen los cuerpos de respuesta, dónde se encuentran los bytes y cuándo una pestaña del navegador se queda sin espacio.
El archivo tiene varios gigabytes y la descarga se detiene a la mitad: el problema que causan los límites de memoria en las descargas del lado del navegador
Una grabación larga puede avanzar de manera constante y luego detenerse porque el guardado en el navegador necesita espacio para los fragmentos recibidos y el Blob completo. Un porcentaje estancado por sí solo no puede diagnosticar la causa: la red puede pausarse, el host puede cerrar la conexión, la cancelación puede activarse o el proceso puede acercarse a la presión de la memoria.
ToolAcre hace que un límite sea determinista. `downloadMedia` tiene por defecto un máximo de 2 GiB y rechaza una longitud de contenido declarada mayor antes de leer el cuerpo. Si el host omite o subestima ese encabezado, se aplica nuevamente el mismo límite a medida que llegan los fragmentos, lo que evita un acumulador ilimitado. Un valor declarado cerca del límite merece precaución porque el ensamblado de blobs, el estado de la página y la sobrecarga de implementación pueden requerir más recursos de los que sugiere la carga de respuesta por sí sola.
Cómo se lee el cuerpo de una respuesta: fragmentos de ReadableStream frente a un gran búfer: qué hace el navegador mientras el progreso avanza lentamente
Fetch expone el cuerpo de la respuesta como ReadableStream cuando el navegador proporciona uno. La implementación obtiene un lector, espera fragmentos, cuenta cada `Uint8Array`, actualiza el progreso y almacena los fragmentos para la construcción final del Blob. El streaming hace que el progreso y la cancelación sean genuinos; no hace que el almacenamiento sea constante.
Cuando Content-Length es un valor finito positivo, la interfaz puede mostrar los bytes recibidos frente a un total. Sin él, la pantalla informa los bytes recibidos pero se niega a inventar un porcentaje. Si no existe ningún cuerpo legible, el código vuelve a `response.blob()` e informa únicamente el tamaño final. Cada fragmento retenido hace posible el ensamblaje posterior, mientras que un verdadero diseño de transmisión de disco necesitaría una API de navegador, un modelo de permiso y una estrategia de falla diferentes que no están presentes aquí.
Dónde reside el Blob completado y por qué ninguna promesa de almacenamiento del navegador es segura
El Blob recopilado es un objeto de navegador que representa bytes inmutables con una etiqueta MIME. La especificación no promete si un navegador en particular conserva cada byte de respaldo en la RAM, derrama algunos datos o duplica los buffers durante el ensamblaje. Por lo tanto, la guía de artículos debería evitar una afirmación de ubicación de almacenamiento universal.
Lo que la aplicación demuestra es que retiene las referencias de fragmentos hasta que finaliza la transmisión, luego construye un Blob y lo mantiene disponible para la acción Guardar en su dispositivo. Ese conjunto de trabajo compite con la página y otras pestañas, por lo que las condiciones del dispositivo y del navegador siguen siendo limitaciones prácticas por debajo del límite explícito. Esa distinción es la razón por la que la documentación menciona la presión de los recursos en lugar de prometer un multiplicador de RAM específico, un umbral de derrame de disco o una técnica de asignación dependiente del navegador.
Por qué no hay límite de carga, pero hay una protección de descarga de 2 GiB
No se carga ningún archivo en ToolAcre y ningún relé recibe los medios. El GET viaja desde el navegador del visitante hasta el host proporcionado. Eso elimina una cuota de carga del servidor, pero no significa "ilimitado": la fuente impone un máximo de dos gibibytes y les dice a los trabajos más grandes que utilicen el enlace nativo Guardar como en su lugar.
El anfitrión puede anunciar un tamaño excesivo a través de Content-Length, permitiendo un rechazo anticipado. También puede transmitir sin longitud, en cuyo caso ToolAcre cuenta fragmentos reales y se detiene después de cruzar el límite. Los bytes parciales no se ofrecen como descarga truncada después de este error. Los controles tempranos y continuos cubren encabezados de longitud veraz y ausente, mientras que un encabezado pequeño inexacto se detecta solo cuando el cuerpo medido pasa el mismo techo.
Ejemplo resuelto: una larga conferencia grabada en una computadora portátil con RAM limitada: qué esperar y cómo distinguir la presión de la memoria de una falla en la red
Imagine un archivo de conferencia en una computadora portátil que ya ejecuta un editor y muchas pestañas. Primero presione Verificar enlace y compare el tamaño indicado con el protector. Durante la descarga, las actualizaciones constantes de bytes sin total significan que el host omitió una longitud utilizable; en cambio, una fila de solicitud congelada puede mostrar una pausa en el transporte.
La presión de la memoria puede afectar la pestaña incluso mientras la solicitud permanece activa, pero ToolAcre no puede inspeccionar el sistema operativo y declarar una causa. Las herramientas de tareas del navegador, las vistas de la memoria del sistema y el cronograma de solicitudes proporcionan evidencia complementaria. Volver a intentarlo a ciegas puede repetir la misma demanda de asignación. Si la solicitud termina con un estado HTTP, investigue esa respuesta primero; La presión de la memoria no es una explicación predeterminada útil para cada transferencia grande interrumpida.
Hábitos prácticos: cerrar otras pestañas y descargar un archivo a la vez: cómo darle a la pestaña el espacio que necesita
Cierre las pestañas pesadas no relacionadas antes de iniciar una transferencia cercana al límite, mantenga activo un trabajo grande a la vez y evite borrar el resultado hasta que haya comenzado la acción de guardar. Estos hábitos reducen la competencia pero no aumentan el máximo codificado ni garantizan el éxito en un dispositivo restringido.
Verificar primero es útil cuando el host proporciona Longitud del contenido, pero un valor faltante significa "desconocido", no "pequeño". Observe el contador de bytes sin procesar y cancele si la transferencia no es el activo esperado. La cancelación descarta el archivo parcial y libera el bloqueo del lector en lugar de presentar bytes incompletos como éxito. Guardar rápidamente también reduce el tiempo que el Blob listo permanece accesible en el estado de la página, aunque JavaScript no puede prometer el momento exacto en que un navegador reclama el almacenamiento de respaldo.
Lo que esto no cubre: reanudar una descarga interrumpida, dividir un archivo en partes o descargas que excedan lo que el dispositivo puede contener.
Esta ruta no emite solicitudes de rango, no reanuda una transferencia interrumpida, no divide la salida en partes, no transmite directamente a un identificador de archivo seleccionado por el usuario ni programa una cola. Aunque una respuesta HEAD informa si los rangos de bytes parecen ser compatibles, el programa de descarga no convierte ese resultado de aviso en un comportamiento de reanudación.
Los archivos más allá de la protección pertenecen a una descarga del navegador nativo, un cliente de línea de comandos permitido u otro flujo de trabajo autorizado que escribe progresivamente sin retener el resultado completo para guardar Blob. Esa elección tiene que ver con la arquitectura de la memoria, no con una solución alternativa para el inicio de sesión, CORS, DRM o restricciones de derechos. Un cliente reanudable puede ser más apropiado para conexiones no confiables, pero solo cuando el origen del archivo y la autorización le permiten a ese cliente acceder al mismo recurso.
Conclusión: tanto la protección explícita como la memoria disponible del dispositivo son importantes
La declaración de límite precisa tiene dos capas: ToolAcre rechaza más de 2 GiB de forma predeterminada, y las transferencias más pequeñas aún pueden estar limitadas por los recursos disponibles del navegador. “Sin límite de carga” describe el relevo ausente; no es sinónimo de tamaño descargable infinito.
Para archivos compatibles, el lector de fragmentos proporciona un progreso veraz, un AbortController proporciona cancelación y la creación de Blob proporciona un resultado que se puede guardar. Direct Media Downloader mantiene los bytes en la ruta directa del host al navegador y al mismo tiempo reconoce que una pestaña del navegador es un espacio de trabajo limitado. Los dos límites deben planificarse juntos antes de que comience la transferencia, especialmente en computadoras portátiles o dispositivos móviles administrados donde los recursos disponibles pueden cambiar rápidamente.