Técnicas de carga paralela: maximiza el ancho de banda
Aprende cómo las cargas paralelas aceleran las transferencias. Entiende uploads fragmentados y transferencias multi-conexión.
Las subidas paralelas dividen un archivo en fragmentos (típicamente de 5 MB a 100 MB cada uno) y los envían por múltiples conexiones TCP concurrentes, superando el techo de rendimiento que un solo flujo alcanza en enlaces de alta latencia. La subida multiparte de Amazon S3, las subidas reanudables de Google Cloud Storage y tus.io implementan todos esto. En una línea de 1 Gbps con 80 ms de latencia hasta el servidor de destino, un solo HTTP PUT suele saturarse a unos 150 Mbps, mientras que 8 flujos paralelos superan los 900 Mbps. La ganancia es real y predecible una vez que entiendes por qué.
Por qué un solo flujo no es suficiente
El control de congestión de TCP usa una ventana deslizante para decidir cuántos datos sin confirmar mantener en vuelo. En una tubería de alta capacidad y alta latencia, el tamaño de ventana por defecto (alrededor de 16 MB en Linux 5.x, menos en kernels más antiguos) se llena antes de que regresen los ACKs, y el emisor espera ocioso. Este es el problema del "producto de ancho de banda por retardo", y es la razón por la que una sola transferencia FTP a un servidor en Singapur desde París alcanza un máximo de unos 30 Mbps incluso en una línea gigabit.
Ejecutar múltiples conexiones paralelas sortea el problema porque cada conexión tiene su propia ventana. Ocho flujos de 30 Mbps suman 240 Mbps, y eso es antes de tener en cuenta la selección del edge CDN, que a menudo enruta conexiones distintas a través de diferentes puntos de ingesta.
Fragmentación: qué tamaño y cuántos
El punto óptimo depende de la latencia y la pérdida de paquetes. Para transferencias dentro del mismo continente con menos de 50 ms de RTT, 10 MB de fragmentos con 4 workers paralelos saturan la mayoría de las líneas de consumidor. Para enlaces transcontinentales o móviles con pérdidas (más de 100 ms de RTT, más de 0,5% de pérdida de paquetes), baja a fragmentos de 5 MB con 8 a 16 workers.
La API multiparte de S3 requiere un mínimo de 5 MB por parte (excepto la última), un máximo de 5 GB por parte y hasta 10.000 partes por subida. Eso sitúa el techo teórico en torno a 48,8 TB por objeto. Google Cloud Storage admite 32 partes por objeto compuesto y soporta URIs de sesión reanudables que persisten hasta una semana. Los blobs de bloques de Azure Blob aceptan hasta 50.000 bloques a 4.000 MiB cada uno.
Para transferencias basadas en navegador, los fragmentos de más de 100 MB empiezan a presionar la RAM en pestañas ya cargadas, por lo que la mayoría de las interfaces web se mantienen entre 5 MB y 20 MB.
Cómo lo hacen realmente los servicios de transferencia modernos
El subidor web de WeTransfer divide los archivos en fragmentos de 6 MB y ejecuta de 3 a 5 solicitudes XHR paralelas. Smash fragmenta más agresivamente, con fragmentos de 4 MB a través de hasta 8 workers. SwissTransfer usa fragmentos de 50 MB con 4 flujos paralelos, lo que favorece el rendimiento en líneas de fibra suizas pero funciona peor en conexiones inestables porque un solo fragmento fallido significa retransmitir 50 MB. Dropbox Transfer se apoya en su API de subida fragmentada con fragmentos de 8 MB.
Las diferencias se notan en pruebas del mundo real: un archivo de 5 GB en una subida de 500 Mbps a WeTransfer termina en unos 95 segundos; SwissTransfer a rendimiento similar tarda unos 105 segundos por la sobrecarga ocasional de reintento de fragmentos.
Subidas reanudables: el superpoder silencioso
Las subidas fragmentadas desbloquean la reanudación. Si tu Wi-Fi cae en el fragmento 47 de 120, no reinicias desde cero: reanudas desde el fragmento 48. El protocolo tus.io (un estándar abierto ahora en versión 2.0) formaliza esto con solicitudes HEAD para consultar el offset de subida y solicitudes PATCH para añadir, usando las cabeceras Upload-Offset y Upload-Length.
La API de subida reanudable de Google Drive usa URIs de sesión que persisten durante 7 días. Puedes colapsar un portátil, reiniciarlo, volver a abrir la pestaña y continuar exactamente donde lo dejaste. Esta es la diferencia entre una transferencia de 10 GB utilizable y una moneda al aire.
La encriptación en el cliente cambia el cálculo
Los servicios de transferencia encriptados de extremo a extremo tienen que encriptar cada fragmento en el cliente antes de enviarlo. AES-256-GCM a 500 MB/s en la CPU de un portátil moderno no es el cuello de botella, pero el orden importa: encriptar fragmento, subir fragmento, encriptar siguiente fragmento. El pipelining con un pool de workers importa aquí. Las implementaciones básicas serializan la encriptación y la subida, reduciendo el rendimiento efectivo a la mitad. Las implementaciones correctas mantienen 2 a 4 workers de encriptación alimentando a 4 a 8 workers de subida a través de una cola acotada.
Por eso HexaTransfer ejecuta la encriptación AES-256-GCM en Web Workers junto a un pool XHR paralelo: el techo de 10 GB es realmente alcanzable en el navegador sin bloquearse en la criptografía.
Contrapresión y límites del lado del servidor
Más paralelismo no siempre es más rápido. Si el servicio receptor limita la tasa por IP (habitual con CloudFront a 25.000 solicitudes por segundo por distribución), empujar 32 fragmentos concurrentes puede desencadenar respuestas 503 Slow Down. HTTP/2 ayuda porque multiplexa sobre una sola conexión TCP, pero muchas CDNs terminan HTTP/2 en el edge y distribuyen HTTP/1.1 al origen, por lo que el paralelismo efectivo depende de la configuración del edge.
Prueba antes de sobre-paralelizar. 8 workers es casi siempre seguro; 16 es el límite superior de lo que los almacenes de objetos en la nube aceptan limpiamente; 32 empieza a producir reintentos que cuestan más de lo que ahorran.
Límites del navegador que debes conocer
Chrome y Firefox limitan las conexiones concurrentes por origen a 6 sobre HTTP/1.1 y efectivamente ilimitadas sobre HTTP/2. Si el servicio de transferencia sigue en HTTP/1.1 (raro, pero algunos gateways FTP sobre HTTP heredados), tu techo de paralelismo es 6 independientemente de cuántos workers pongas en marcha. Comprueba con DevTools: la columna "Waterfall" en el panel Network muestra solicitudes en cola apilándose.
Safari en iOS 17 y posteriores gestiona 6 XHR paralelas limpiamente, pero empieza a expulsar pestañas en segundo plano con una presión de RAM de unos 1,5 GB, lo que importa para los búferes de subida fragmentada.
Cuándo las subidas paralelas no ayudan
En conexiones residenciales asimétricas (típicas: 1 Gbps de bajada, 40 Mbps de subida), tu subida es el cuello de botella, no la ingesta del servidor. Empujar 8 flujos paralelos de 5 MB cada uno por una tubería de 40 Mbps no va más rápido que 1 flujo a 40 Mbps. El paralelismo ayuda cuando el techo de un solo flujo está por debajo de la capacidad de la tubería, no cuando ya estás saturando el enlace.
Mismo resultado con datos móviles: si tienes una barra de LTE, los workers adicionales mayormente producen retransmisiones.
Qué buscar en un servicio
Si estás eligiendo una herramienta de transferencia para archivos grandes frecuentes, comprueba tres cosas: si admite subidas fragmentadas reanudables, cuántos workers paralelos ejecuta la interfaz web, y si usa HTTP/2 o HTTP/3 hasta el edge. Los servicios que cumplen los tres moverán un archivo de 10 GB en minutos en una conexión decente.
Pruébalo en hexatransfer.com — gratis, 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