Reanudar transferencias interrumpidas: nunca reiniciar

Las transferencias reanudables dividen un archivo en fragmentos y rastrean cuáles se han recibido correctamente; cuando la conexión cae, el cliente reanuda desde el siguiente fragmento no enviado en lugar de reiniciar desde el byte cero. El estándar web para esto es tus.io (un protocolo abierto de subida reanudable), implementado por SwissTransfer, HexaTransfer, Vimeo, Cloudinary y muchos servicios de transferencia modernos. Para descargas, las solicitudes de rango HTTP (RFC 7233) permiten a los navegadores y herramientas como curl o aria2 reanudar descargas interrumpidas. Sin reanudabilidad, una subida de 9,8 GB que falla al 95% te cuesta el trabajo entero; con reanudabilidad, pierdes como mucho 50 MB.

El problema de las subidas no reanudables

Una subida de archivo sin reanudabilidad envía el archivo completo como una sola solicitud HTTP POST. Si algo interrumpe la conexión —caída del Wi-Fi, timeout de VPN, modo reposo del portátil, un corte del operador— la conexión TCP se cierra y el servidor descarta los datos parciales que tenía. El cliente empieza desde el byte cero.

Para una subida de 5 GB en una conexión de 50 Mbps, eso son 13 minutos de trabajo perdidos. Para una subida de 50 GB, son más de dos horas. La tasa de fallos de las subidas no reanudables en conexiones móviles es brutal: una subida de 30 minutos en una conexión 4G raramente tiene éxito al primer intento.

Cómo funcionan los protocolos reanudables

Las subidas reanudables modernas funcionan aproximadamente así:

1. Crear: el cliente envía un POST al servidor con el tamaño total y los metadatos del archivo. El servidor devuelve una URL única para esta subida específica y reserva almacenamiento.
2. Fragmentar: el cliente divide el archivo en fragmentos (habitualmente de 5-64 MB cada uno).
3. Subir: el cliente envía cada fragmento como una solicitud PATCH con una cabecera Content-Range o Upload-Offset que indica la posición del fragmento.
4. Confirmar: el servidor escribe el fragmento en el almacenamiento y confirma el nuevo offset.
5. Reanudar: si la conexión cae, el cliente envía una solicitud HEAD a la URL de subida. El servidor responde con el offset actual (cuántos bytes tiene). El cliente reanuda desde ese offset.
6. Completar: cuando se confirma el último fragmento, la subida ha terminado.

Este modelo lo define la especificación tus.io (versión 1.0.0 está ampliamente desplegada). Otras variantes incluyen la subida multiparte de S3 y las subidas reanudables de Google Cloud Storage.

Tus.io: el estándar abierto

Tus ("transloadit upload server") es un protocolo libre y abierto mantenido por Transloadit. La especificación está en tus.io y lo implementan:

• Bibliotecas de cliente: tus-js-client (navegador + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
• Implementaciones de servidor: tusd (servidor de referencia en Go), tus-node-server y muchas integraciones de frameworks
• Servicios comerciales: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, servidores companion de Uppy

El protocolo es deliberadamente mínimo: cuatro verbos HTTP (POST, HEAD, PATCH, OPTIONS), un puñado de cabeceras (Upload-Offset, Upload-Length, Tus-Resumable). Esto mantiene las implementaciones simples e interoperables.

Decisiones sobre el tamaño de fragmento

El tamaño de fragmento equilibra la granularidad de reanudación con la sobrecarga HTTP.

| Tamaño de fragmento | Coste de recuperación en fallo | Sobrecarga | |---|---|---| | 1 MB | Perder ≤ 1 MB | Alta (muchas solicitudes) | | 5 MB | Perder ≤ 5 MB | Moderada | | 16 MB | Perder ≤ 16 MB | Baja | | 64 MB | Perder ≤ 64 MB | Mínima | | 256 MB | Perder ≤ 256 MB | Sobrecarga insignificante, doloroso si falla |

Para conexiones estables, los fragmentos de 32-64 MB maximizan el rendimiento. Para móvil o Wi-Fi inestable, los fragmentos de 2-5 MB se recuperan más rápido de cada fallo. Los servicios suelen elegir un valor por defecto de 5-10 MB como compromiso.

Qué interrumpe realmente las transferencias

Entender los modos de fallo ayuda a evaluar si la implementación de reanudación de un servicio es robusta:

• Caídas del Wi-Fi: cambio de red, pérdida de señal, reinicio del router. Muy habitual.
• Modo reposo del portátil: cerrar la tapa en macOS/Windows. El sistema operativo pausa la red; al despertar, las conexiones a menudo necesitan restablecerse.
• Suspensión de pestañas: los navegadores modernos suspenden las pestañas en segundo plano para ahorrar memoria. Las subidas en una pestaña suspendida pueden detenerse.
• Problemas de ISP/backhaul: cambios momentáneos de enrutamiento, re-handshake TLS necesario.
• Reconexión de VPN: los clientes VPN renegocian periódicamente; la conexión TCP muere.
• Reinicios del servidor: el servicio de transferencia despliega una nueva versión; las solicitudes en vuelo fallan.
• Cambios de política de cross-origin: los cortafuegos corporativos que inspeccionan el tráfico a veces matan las conexiones de larga duración.

Una implementación reanudable robusta gestiona todos estos con el mismo mecanismo: reconectar, HEAD para comprobar el offset, reanudar desde ahí.

Reanudación para descargas

Las solicitudes de rango HTTP (RFC 7233) impulsan las descargas reanudables. Un servidor que anuncia Accept-Ranges: bytes en las cabeceras de respuesta admite solicitudes de rango. Los clientes pueden entonces emitir Range: bytes=1000000- para obtener solo los bytes desde el offset 1.000.000 en adelante.

Los navegadores usan esto automáticamente cuando pulsas "Reanudar" en el gestor de descargas. Chrome, Firefox y Safari admiten la reanudación de descargas en servidores compatibles. La mayoría de las CDNs (Cloudflare, Fastly, CloudFront) admiten rangos.

Las herramientas de línea de comandos ofrecen más control:

• curl -C - -O url reanuda una descarga desde donde se detuvo.
• wget -c url hace lo mismo.
• aria2c -c -s 16 url descarga con 16 flujos paralelos de solicitud de rango para mayor velocidad.

Servicios que admiten reanudación

Los servicios de transferencia modernos mayoritariamente gestionan la reanudación de subidas:

| Servicio | Reanudación de subida | Reanudación de descarga | |---|---|---| | SwissTransfer | Sí (basado en tus) | Sí (rangos HTTP) | | HexaTransfer | Sí (fragmentado + compatible con tus) | Sí | | WeTransfer | Sí (subidas fragmentadas) | Sí | | Dropbox Transfer | Sí | Sí | | Google Drive | Sí (API de subida reanudable) | Sí | | OneDrive | Sí | Sí | | Box | Sí | Sí |

Los niveles gratuitos a veces desactivan la reanudación para incentivar las mejoras de pago, pero esto es raro en 2026. Los servicios más antiguos sin soporte de reanudación están desapareciendo de las listas de recomendaciones porque los usuarios se cansan de los fallos.

Lo que no se reanuda automáticamente

Las subidas HTTP POST simples en aplicaciones básicas no se reanudan. Las transferencias FTP varían históricamente: algunos clientes y servidores admiten comandos REST (reinicio), otros no. Los adjuntos de correo electrónico no pueden reanudarse: si un envío de Gmail falla al 90%, hay que reiniciar.

Las transferencias por torrent se reanudan inherentemente porque el protocolo de torrent rastrea qué piezas se han verificado. Esto es parte de por qué BitTorrent siguió siendo útil para distribuciones muy grandes incluso cuando la web alcanzó a los demás en otras métricas.

Reanudación con encriptación de extremo a extremo

Las subidas reanudables combinadas con encriptación en el cliente requieren una fragmentación cuidadosa. El archivo se divide en fragmentos, cada fragmento se encripta con AES-256-GCM usando un IV único (vector de inicialización), y luego se sube. Al reanudar, el cliente debe saber qué fragmentos completaron y continuar desde el siguiente.

Porque cada fragmento está encriptado y autenticado de forma independiente (el modo AEAD de GCM), las subidas parciales no pueden manipularse. Un servidor malicioso que insertara basura en el offset 5 GB fallaría en la autenticación cuando el receptor desencriptara: el mismatch de la etiqueta GCM sería detectado.

Las implementaciones como HexaTransfer usan IVs por fragmento derivados de forma determinista de una clave maestra y el índice del fragmento, por lo que la reanudación no requiere almacenar los IVs por separado. El lado de la desencriptación los reconstruye a partir de la misma derivación.

Buenas prácticas en el lado del cliente

Para maximizar el éxito de la reanudación:

• Mantén la pestaña activa durante la subida. La suspensión de pestañas del navegador mata las subidas en vuelo. El aviso "no cierres esta pestaña" es estándar en las interfaces de usuario de los servicios de transferencia.
• Conéctate a una red con cable cuando sea posible. Las caídas del Wi-Fi causan la mayoría de los fallos.
• Desactiva el modo ahorro de energía durante subidas largas. macOS: caffeinate -i. Windows: la utilidad Awake de Powertoys o cambios en el plan de energía.
• No cambies de red Wi-Fi a mitad de la subida. La conexión TCP cambia de IP y muere.
• Deja que la subida termine antes de cerrar la tapa del portátil. El macOS moderno a veces preserva las subidas durante un reposo breve, pero no es fiable.

Verifica en el lado del servidor

Algunos servicios muestran barras de progreso incompletas que no reflejan realmente el estado del servidor. Después de una subida que sobrevivió una o dos interrupciones, recarga la página y verifica que el enlace funciona: ábrelo en modo incógnito y descarga una pequeña parte. Si la reanudación funcionó, el archivo completo se descargará correctamente.

Para escenarios que requieren paranoia, calcula un hash SHA-256 en el cliente, sube y verifica que el hash del archivo descargado coincide. La verificación criptográfica de integridad de archivos tarda 10 segundos de CPU por gigabyte y da certeza absoluta.

Conclusión

La transferencia reanudable es una característica básica en 2026: cualquier servicio sin ella es un descarte inmediato para archivos de más de unos pocos cientos de megabytes. Busca conformidad con tus.io o comportamiento equivalente de subida fragmentada. Asegúrate de que el servicio que eliges gestiona las interrupciones con elegancia; prueba con una caída de red deliberada en un archivo pequeño antes de comprometerte con una transferencia grande.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.