Arquitectura de subida por fragmentos: guía de diseño
Diseña un sistema robusto de subida por fragmentos: estrategias de fragmentación, subidas reanudables y optimización de transferencia paralela.
Un sistema de subida por fragmentos divide el archivo en piezas de tamaño fijo o variable y las envía de forma independiente: así, un corte de red no obliga a reiniciar desde cero una transferencia de 10 GB. Los dos estándares abiertos dominantes son el protocolo tus.io (ampliamente implementado, con clientes en Go, JavaScript y Python) y la subida multiparte de AWS S3 (mínimo 5 MB por parte, límite de 10.000 partes). Implementado correctamente, un sistema de fragmentos puede ofrecer entre 5 y 10 veces más rendimiento en enlaces de alta latencia, tolerar desconexiones breves y permitir el descifrado paralelo en el lado receptor.
Por qué las subidas monolíticas fallan a escala
Un único PUT HTTP de 5 GB puede fallar de media docena de formas distintas. Las ventanas de congestión TCP tardan en ampliarse, limitando el caudal muy por debajo de la capacidad del enlace en rutas de alta latencia. Los navegadores restringen las conexiones concurrentes por origen a 6, dejando la mayor parte del ancho de banda sin usar. Los timeouts del servidor (nginx por defecto 60 s, CloudFront 30 s para no-streaming) matan las subidas largas. Las redes móviles al cambiar de celda rompen la conexión cada pocos minutos. Y un solo bit erróneo obliga a reiniciar la transferencia completa. Las subidas por fragmentos resuelven todo esto haciendo que la unidad de trabajo sea pequeña, reintentable de forma independiente y apta para la paralelización.
Cómo elegir el tamaño del fragmento
El tamaño del fragmento es un equilibrio. Los fragmentos pequeños se recuperan más rápido de los fallos y ofrecen granularidad de progreso más fina, pero añaden sobrecarga HTTP. Los fragmentos grandes amortizan los costes de handshake y TLS, pero desperdician ancho de banda cuando fallan y deben retransmitirse. Rangos habituales: 1–5 MB para subidas móviles con redes inestables, 5–16 MB para subidas desde escritorio web, 16–64 MB para transferencias servidor a servidor en enlaces fiables, y 100 MB o más para S3 Multipart en archivos de más de 1 TB donde el límite de 10.000 partes obliga a fragmentos mayores. Algunos sistemas se adaptan dinámicamente, empezando pequeño y escalando según la conexión demuestre ser fiable.
Fragmentación de tamaño fijo frente a fragmentación definida por contenido
La fragmentación de tamaño fijo (por ejemplo, cada 8 MB) es trivial de implementar, compatible con la paralelización y soporta offsets exactos de reanudación. La fragmentación definida por contenido, usada en rsync y restic, elige límites basándose en un hash rodante (huella digital de Rabin) para que las inserciones en mitad de un archivo no desplacen todos los límites posteriores. La CDC es excelente para la deduplicación en herramientas de backup, pero añade complejidad y coste de CPU sin ventaja para la transferencia pura de archivos. Para arquitecturas de subida, el tamaño fijo gana en simplicidad y se mapea limpiamente a las partes de S3 Multipart o a los offsets de tus.io.
Protocolos de subida reanudable
El protocolo tus.io usa HTTP PATCH con la cabecera Upload-Offset para añadir fragmentos. Una petición HEAD devuelve el offset actual en el servidor, de modo que el cliente sabe desde dónde reanudar tras una interrupción. S3 Multipart usa un modelo diferente: inicia la subida para obtener un UploadId, sube cada parte (indexada desde 1) y envía una solicitud CompleteMultipartUpload con la lista de ETags. Los clientes pueden consultar ListParts para ver qué se ha subido. Ambos protocolos preservan el estado entre reinicios del cliente y sobreviven a caídas de conexión sin problemas.
Concurrencia de subida en paralelo
Subir fragmentos en paralelo mejora drásticamente el rendimiento en enlaces de alta latencia. HTTP/1.1 limita a 6 conexiones concurrentes por origen en los navegadores; HTTP/2 multiplexa muchos flujos sobre una sola conexión, aunque sigue sujeto a ventanas de control de flujo. Un planificador de subidas típico pone en cola los fragmentos y lanza 4 a 8 en paralelo, con contrapresión cuando el servidor señala 429 o 503. Demasiado paralelismo activa el moldeado del ISP y los límites de los middleboxes; demasiado poco deja ancho de banda sin usar. Empíricamente, 4 flujos en banda ancha doméstica y 8–16 en fibra gigabit dan el mejor resultado para la mayoría de cargas de trabajo.
Estado del cliente y metadatos de reanudación
Las subidas reanudables requieren que el cliente recuerde suficiente estado para reanudar tras un crash del navegador o el apagado del portátil. IndexedDB almacena manifiestos de subida con el hash del archivo, el recuento de fragmentos y qué fragmentos tuvieron éxito. Indexa el manifiesto por el hash SHA-256 del archivo para que al añadir el mismo archivo de nuevo continúe donde se quedó. Limpia los manifiestos obsoletos de más de 7 días. En móvil, WKWebView (iOS) y Chrome Custom Tabs (Android) pueden desalojar IndexedDB bajo presión de memoria, por lo que conviene persistir el estado crítico en almacenamiento nativo cuando sea posible.
Gestión de fragmentos en el servidor
El servidor necesita remontar los fragmentos en un archivo completo o, con S3 Multipart, delegar el montaje en S3. Una arquitectura mínima: aceptar cada PATCH de fragmento, escribir en un blob temporal identificado por ID de subida e índice de fragmento, registrar el offset en Redis o PostgreSQL, y en el CompleteMultipart marcar como completo. Usa almacenamiento de objetos (S3, Cloudflare R2, Backblaze B2) para los blobs de fragmentos en lugar del disco local, ya que los backends con balanceo de carga no pueden compartir estado local fácilmente. Recolecta las subidas abandonadas después de 24–72 horas para recuperar almacenamiento.
Verificación de integridad por fragmento y de extremo a extremo
Verifica cada fragmento con un hash en la subida. El ETag de S3 Multipart es un hash MD5 por parte. Para mayor integridad, calcula SHA-256 por fragmento en el lado del cliente y envíalo en una cabecera; el servidor lo almacena junto al fragmento y puede verificarlo en la relectura. Tras subir todos los fragmentos, calcula la raíz de un árbol Merkle o un hash en flujo del archivo remontado y devuélvelo al cliente. Cualquier discrepancia dispara la re-subida de los fragmentos erróneos.
Cifrado de extremo a extremo e interacción con la fragmentación
El cifrado de extremo a extremo complica ligeramente la fragmentación. Cada fragmento necesita su propio nonce para evitar la reutilización de IV en AES-256-GCM, y los límites de fragmento deben formar parte del esquema de autenticación. Una práctica habitual: derivar una clave por fragmento mediante HKDF-SHA256 a partir de una clave raíz de cifrado de archivo, usando el índice del fragmento como información de contexto, luego cifrar cada fragmento con AES-256-GCM y un nonce incremental. Incluir el índice y el total de fragmentos en los datos adicionales (AAD) evita que atacantes empalmenen o reordenen fragmentos. Al descifrar, verificar que todos los fragmentos están presentes y en orden antes de liberar el texto plano.
Observabilidad en sistemas basados en fragmentos
Instrumenta cada fragmento. Métricas a rastrear: fragmentos subidos por segundo, latencia p50/p95/p99 por fragmento, tasa de reintentos y tasa de subidas abandonadas. Los paneles en Grafana o Datadog revelan regresiones rápidamente. Las trazas distribuidas con OpenTelemetry vinculan cada sesión de cliente con su gestión de fragmentos en el servidor. Registra eventos en JSON estructurado para que sean consultables en Loki, Elasticsearch o Splunk. Cuando un cliente reporta una subida lenta, la traza muestra exactamente qué fragmentos se bloquearon y por qué.
Conclusión
Un sistema de subida por fragmentos listo para producción combina fragmentos de 5–16 MB, tus.io o S3 Multipart como protocolo, 4–8 flujos paralelos, estado de reanudación respaldado por IndexedDB, verificaciones de integridad SHA-256 por fragmento y cifrado de extremo a extremo opcional con clave derivada. HexaTransfer usa cifrado fragmentado del lado del cliente con AES-256-GCM y subidas reanudables para gestionar archivos de 10 GB de forma fiable incluso en conexiones inestables.
Pruébalo en https://hexatransfer.com — gratuito, sin cuenta, hasta 10 GB.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo