Cargas reanudables

Ir a ejemplos

En esta página, se analizan las cargas reanudables en Cloud Storage. Las cargas reanudables son el método recomendado para subir archivos grandes, ya que no tienes que reiniciarlas desde el principio si hay una falla de red mientras se realiza la carga.

Introducción

Una carga reanudable te permite reanudar las operaciones de transferencia de datos a Cloud Storage después de que una falla de comunicación haya interrumpido el flujo de datos. Las cargas reanudables funcionan mediante el envío de varias solicitudes, cada una de ellas con una parte del objeto que estás subiendo. Esto es diferente a una carga simple, que contiene todos los datos del objeto en una sola solicitud y se debe reiniciar desde el principio si se genera una falla durante el proceso.

  • Usa una carga reanudable si subes archivos grandes o si subes archivos con una conexión lenta. Por ejemplo, si deseas ver los límites de tamaño que deben tener los archivos para usar cargas reanudables, consulta las consideraciones sobre el tamaño de carga.

  • Una carga reanudable completa se considera una operación de clase A.

Cómo las herramientas y las API usan las cargas reanudables

Según cómo interactúes con Cloud Storage, las cargas reanudables se pueden administrar de forma automática en tu nombre. Haz clic en una pestaña de la tabla incluida a continuación para obtener más información:

Console

Cloud Console administra las cargas reanudables de forma automática en tu nombre. Sin embargo, si actualizas o sales de Cloud Console mientras se realiza una carga, esta se cancela.

gsutil

La herramienta de línea de comandos de gsutil te permite establecer un tamaño mínimo para realizar cargas reanudables con el parámetro resumable_threshold en el archivo de configuración boto. El valor predeterminado para resumable_threshold es 8 MiB.

Bibliotecas cliente

C++

Puedes activar o desactivar el uso de las cargas reanudables como parte del método WriteObject.

C#

Puedes iniciar una carga reanudable con CreateObjectUploader.

Go

Puedes controlar el tamaño mínimo para realizar cargas reanudables con Writer.ChunkSize. Go siempre realiza cargas reanudables fragmentadas.

Java

Las cargas reanudables se controlan a través del método writer.

Node.js

Las cargas reanudables se administran de forma automática cuando se usa el método createWriteStream.

PHP

Las cargas reanudables se administran de forma automática por ti, pero se pueden controlar directamente mediante la opción resumable.

Python

Las cargas reanudables se producen de forma automática cuando el archivo supera los 8 MiB. De manera alternativa, puedes usar Resumable Media para administrar las cargas reanudables por tu cuenta.

Ruby

Todas las cargas se tratan como cargas reanudables.

API de REST

API de JSON

La API de JSON de Cloud Storage usa una solicitud POST Object que incluye el parámetro de consulta uploadType=resumable para iniciar la carga reanudable y, luego, una o más solicitudes PUT Object a fin de subir los datos del objeto. Si deseas obtener una guía paso a paso a fin de compilar tu propia lógica para la carga reanudable, consulta Realiza cargas reanudables.

API de XML

La API de XML de Cloud Storage usa una solicitud POST Object que incluye el encabezado x-goog-resumable: start para iniciar la carga reanudable y, luego, una o más solicitudes PUT Object a fin de subir los datos del objeto. Si deseas obtener una guía paso a paso a fin de compilar tu propia lógica para la carga reanudable, consulta Realiza cargas reanudables.

Cargas reanudables de tamaño desconocido

El mecanismo de carga reanudable admite transferencias en las que el tamaño del archivo no se conoce de antemano. Esto puede ser útil para casos como la compresión de un objeto sobre la marcha durante la carga, ya que es difícil predecir el tamaño exacto del archivo comprimido al inicio de una transferencia. El mecanismo es útil si deseas transmitir una transferencia que se pueda reanudar después de su interrupción o si la codificación de transferencia fragmentada no funciona para tu aplicación.

Para obtener más información, consulta Transferencias de transmisión.

Prácticas recomendadas

  • Cuando inicias una sesión de carga reanudable, se muestra un URI de sesión que debes usar cuando subes los datos del objeto. Este URI de sesión actúa como un token de autenticación, por lo que no es necesario firmar las solicitudes PUT de carga. Sé prudente cuando compartas el URI de sesión y solo transmítelo a través de HTTPS, ya que cualquier persona puede usarlo para subir datos al depósito de destino sin ninguna autenticación adicional.

  • Los URI de sesión vencen después de una semana. Te recomendamos que inicies una carga reanudable en cuanto obtengas el URI de sesión y que reanudes una carga interrumpida poco después de que se produzca la interrupción.

  • Si usas un URI de sesión vencido en una solicitud, recibirás un código de estado 400 Bad Request. En este caso, debes iniciar una nueva carga reanudable, obtener un nuevo URI de sesión y comenzar la carga desde el principio con el nuevo URI de sesión.

  • Debes reintentar las solicitudes que muestran los siguientes códigos de estado:

    • 408 Request Timeout
    • 500 Internal Server Error
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout
  • Cuando realizas una carga reanudable, controla los errores 404 Not Found. Para esto, inicia toda la carga desde el principio.

Cuando realices solicitudes de reintento, usa la retirada exponencial truncada.

  • Además, recomendamos que solicites una verificación de integridad del objeto final subido para asegurarte de que coincida con el archivo de origen. Para ello, calcula el resumen MD5 del archivo de origen y agrégalo al encabezado de la solicitud Content-MD5. Verificar la integridad del archivo subido es importante, en especial, si subes un archivo grande durante un período prolongado, ya que hay una mayor probabilidad de que el archivo de origen se modifique en el transcurso de la operación de carga.

  • Las cargas reanudables se fijan en la región en la que comienzan. Por ejemplo, si creas una URL de carga reanudable en EE.UU. y se la entregas a un cliente en Asia, la carga se transferirá a EE.UU. Si se mantiene una carga reanudable en una región en la que no se inició, es posible que la carga se ralentice.

  • Si usas instancias de Compute Engine con procesos que envían solicitudes POST a Cloud Storage para iniciar una carga reanudable, entonces debes usar las instancias de Compute Engine en las mismas ubicaciones que tus depósitos de Cloud Storage. Luego, puedes usar un servicio de IP de ubicación geográfica para seleccionar la región de Compute Engine a la que enrutas las solicitudes de los clientes, lo que ayudará a mantener el tráfico ubicado en una región geográfica.

Optimización opcional

Si recibes una respuesta 308 Resume Incomplete sin encabezado Range, es posible que Cloud Storage haya recibido algunos bytes, pero aún no se conservaron en el momento en que Cloud Storage recibió la consulta. En este caso, retransmitir desde el principio del archivo es un desperdicio. Para reducir la probabilidad de este caso, puedes esperar unos segundos después de la primera respuesta 308 y, luego, realizar una segunda consulta. En ese momento, es posible que recibas un encabezado Range, lo que te permitirá evitar tener que retransmitir el inicio del archivo. Si no recibes un encabezado Range en este segundo intento, no deberías seguir esperando y probar por tercera vez, ya que volver a realizar la consulta podría generar una carga “suspendida”, en el caso de que Cloud Storage no haya recibido ningún dato para la carga.

Próximos pasos