Subir un video de dos gigabytes a través del WiFi de una cafetería es un ejercicio de optimismo. Observas cómo la barra de progreso avanza lentamente hacia el setenta por ciento y, de repente, la conexión parpadea. La subida falla. Cuando lo intentas de nuevo, el servidor espera un archivo completamente nuevo. Empiezas desde cero. Para cualquiera que esté construyendo una aplicación que gestione videos generados por el usuario, esto no es un caso excepcional. Es la norma. El protocolo tus fue creado específicamente para eliminar este problema. Es un estándar abierto que funciona sobre HTTP ordinario y le otorga memoria a las subidas. Cuando la red se recupera, la transferencia de archivos se reanuda exactamente donde se quedó.

Por qué fallan las subidas estándar

Las subidas de archivos multipart estándar tratan toda la carga útil como una única transacción. El navegador o la aplicación abre una conexión TCP, transmite los bytes y espera un 200 OK al final. Si la conexión se restablece porque el usuario cambió de LTE a WiFi, o porque la computadora entró en modo de suspensión, el servidor no tiene forma de saber qué bytes llegaron de forma segura. La mayoría de los frameworks simplemente descartan los datos parciales. El usuario se queda con un formulario fallido y un mal humor. Los archivos de video amplifican el problema porque son grandes, a menudo se suben desde dispositivos móviles en redes inestables y frecuentemente se codifican en formatos que no pueden procesarse hasta que el archivo esté completo.

Cómo tus cambia las reglas del juego

Tus replantea la subida como una conversación con estado en lugar de una entrega de un solo intento. En lugar de enviar un archivo en una ráfaga continua de bytes, el cliente divide la carga útil en fragmentos. Lo que es más importante, el servidor recuerda el offset, el recuento exacto de bytes que ha recibido hasta el momento. Esta persistencia de estado es lo que hace posible la reanudación. El protocolo es intencionalmente simple. No requiere WebSockets, gRPC ni SDK propietarios. Utiliza los métodos HTTP que ya conoces.

Las tres solicitudes que permiten la reanudación

Cada subida de tus sigue una danza predecible.

Primero, el cliente envía una solicitud POST a un endpoint de tus conocido. Los encabezados describen el archivo. El encabezado Upload-Length indica el tamaño final en bytes, y los metadatos opcionales, como el nombre del archivo o el tipo de contenido, viajan en el encabezado Upload-Metadata como una lista separada por comas de pares clave-valor codificados en base64. El servidor crea un recurso de subida vacío y responde con un estado 201 Created más un encabezado Location que apunta a una URL única. Esta URL es la dirección de la subida durante el resto de su vida.

Luego viene la solicitud PATCH. El cliente envía fragmentos de datos binarios sin procesar a esa URL única. Dos encabezados críticos acompañan a la carga útil. Content-Type debe ser application/offset+octet-stream, y Upload-Offset debe coincidir con la posición de bytes donde comienza este fragmento. El servidor verifica que el offset coincida con sus propios registros. Si no es así, el servidor devuelve un 409 Conflict, protegiéndose contra un estado corrupto. Si todo coincide, el servidor añade los bytes, actualiza su offset interno y devuelve una respuesta 204 No Content junto con el nuevo Upload-Offset. El tamaño del fragmento es configurable, pero la práctica común se sitúa entre unos pocos cientos de kilobytes y un par de megabytes. Los fragmentos más pequeños crean más sobrecarga HTTP pero se recuperan más rápido de los errores. Los fragmentos más grandes reducen los viajes de ida y vuelta pero desperdician más ancho de banda si fallan a mitad de camino.

Finalmente, la solicitud HEAD. Esta es la red de seguridad. Si un PATCH falla a mitad de un fragmento, por ejemplo, después de tres megabytes de una porción de cinco megabytes, la conexión se cae. Cuando el cliente recupera el acceso a la red, envía una solicitud HEAD a la URL de subida. El servidor responde con el Upload-Offset actual. El cliente compara