Tecniche di upload parallelo: massimizza la larghezza di banda
Scopri come gli upload paralleli velocizzano i trasferimenti. Comprendi upload a pezzi e trasferimenti multi-connessione.
Gli upload paralleli dividono un file in chunk (tipicamente da 5 MB a 100 MB ciascuno) e li spingono su più connessioni TCP concorrenti, aggirando il tetto di throughput che un singolo stream incontra su link ad alta latenza. S3 Multipart Upload di Amazon, i Resumable Upload di Google Cloud Storage e tus.io li implementano tutti. Su una linea da 1 Gbps con 80 ms di latenza verso il server di destinazione, un singolo HTTP PUT tipicamente satura a 150 Mbps, mentre 8 stream paralleli superano i 900 Mbps. Il guadagno è reale e prevedibile una volta che capisci il perché.
Perché uno stream non basta
Il controllo della congestione di TCP usa una finestra scorrevole per decidere quanti dati non confermati tenere in volo. Su un pipe grasso ad alta latenza, la dimensione predefinita della finestra (circa 16 MB su Linux 5.x, meno su kernel più vecchi) si riempie prima che tornino gli ACK, e il mittente rimane inattivo ad aspettare. Questo è il problema del "bandwidth-delay product", ed è il motivo per cui un singolo trasferimento FTP verso un server a Singapore da Parigi si ferma intorno ai 30 Mbps anche su una linea gigabit.
Eseguire più connessioni parallele aggira il problema perché ogni connessione ottiene la propria finestra. Otto stream da 30 Mbps sommano a 240 Mbps, e questo è prima di tenere conto della selezione dell'edge CDN, che spesso instrada connessioni diverse attraverso punti di ingresso diversi.
Chunking: quale dimensione, quanti stream
Il punto ottimale dipende dalla latenza e dalla perdita di pacchetti. Per trasferimenti nello stesso continente sotto i 50 ms RTT, chunk da 10 MB con 4 worker paralleli saturano la maggior parte delle linee consumer. Per link transcontinentali o mobili con perdite (oltre 100 ms RTT, oltre 0,5% di perdita di pacchetti), scendi a chunk da 5 MB con 8-16 worker.
L'API multipart di S3 richiede un minimo di 5 MB per parte (tranne l'ultima), un massimo di 5 GB per parte, e fino a 10.000 parti per upload. Questo porta il tetto teorico a circa 48,8 TB per oggetto. Google Cloud Storage consente 32 parti per composito e supporta URI di sessione riprendibili che persistono fino a una settimana. I block blob di Azure accettano fino a 50.000 blocchi da 4000 MiB ciascuno.
Per i trasferimenti basati su browser, chunk sopra i 100 MB iniziano a stressare la RAM nei tab già carichi, quindi la maggior parte delle UI web rimane tra 5 MB e 20 MB.
Come i servizi di trasferimento moderni lo implementano davvero
L'uploader web di WeTransfer divide i file in chunk da 6 MB e gestisce 3-5 richieste XHR parallele. Smash frammenta più aggressivamente, con chunk da 4 MB su fino a 8 worker. SwissTransfer usa chunk da 50 MB con 4 stream paralleli, il che favorisce il throughput sulle linee in fibra svizzere ma funziona peggio su connessioni instabili perché un singolo chunk fallito significa ritrasmettere 50 MB. Dropbox Transfer si basa sulla sua API di upload a chunk con chunk da 8 MB.
Le differenze emergono nei test reali: un file da 5 GB su un upload a 500 Mbps verso WeTransfer finisce in circa 95 secondi; SwissTransfer a throughput simile impiega circa 105 secondi a causa dell'overhead di retry dei chunk occasionale.
Upload riprendibili: il superpotere silenzioso
Gli upload a chunk sbloccano la ripresa. Se il tuo Wi-Fi cade al chunk 47 di 120, non riparti da zero — riprendi dal chunk 48. Il protocollo tus.io (uno standard aperto ora alla versione 2.0) formalizza questo con richieste HEAD per interrogare l'offset di upload e richieste PATCH per aggiungere, usando gli header Upload-Offset e Upload-Length.
L'API di upload riprendibile di Google Drive usa URI di sessione che persistono per 7 giorni. Puoi far crashare un laptop, riavviarlo, riaprire il tab, e riprendere esattamente da dove ti eri fermato. Questa è la differenza tra un trasferimento da 10 GB funzionante e una moneta da lanciare.
La cifratura lato client cambia i calcoli
I servizi di trasferimento end-to-end cifrati devono cifrare ogni chunk sul client prima di inviarlo. AES-256-GCM a 500 MB/s su una CPU moderna non è il collo di bottiglia, ma l'ordine conta: cifra il chunk, caricalo, cifra il chunk successivo. Il pipelining con un pool di worker conta qui. Le implementazioni naive serializzano cifratura e upload, dimezzando il throughput effettivo. Le implementazioni corrette mantengono 2-4 worker di cifratura che alimentano 4-8 worker di upload attraverso una coda limitata.
Per questo HexaTransfer esegue la cifratura AES-256-GCM in Web Worker accanto a un pool XHR parallelo, così il tetto di 10 GB è effettivamente raggiungibile nel browser senza bloccarsi sulla crittografia.
Backpressure e limiti lato server
Più parallelismo non è sempre più veloce. Se il servizio ricevente limita per IP (comune con CloudFront a 25.000 richieste al secondo per distribuzione), spingere 32 chunk concorrenti può scatenare risposte 503 Slow Down. HTTP/2 aiuta perché multiplexa su una singola connessione TCP, ma molti CDN terminano ancora HTTP/2 all'edge e si espandono in HTTP/1.1 verso l'origine, quindi il parallelismo effettivo dipende dalla configurazione dell'edge.
Testa prima di esagerare col parallelismo. 8 worker sono quasi sempre sicuri; 16 è il limite superiore di ciò che i cloud object store accettano pulitamente; 32 inizia a produrre retry che costano più di quanto risparmiano.
Limiti del browser da conoscere
Chrome e Firefox limitano le connessioni concorrenti per origine a 6 su HTTP/1.1 e praticamente illimitate su HTTP/2. Se il servizio di trasferimento è ancora su HTTP/1.1 (raro, ma alcuni gateway FTP-over-HTTP legacy lo sono), il tuo tetto di parallelismo è 6 indipendentemente da quanti worker avvii. Controlla con DevTools: la colonna "Waterfall" nel pannello Network mostra le richieste in coda che si accumulano.
Safari su iOS 17 e successivi gestisce 6 XHR paralleli in modo pulito ma inizia a espellere i tab in background a circa 1,5 GB di pressione RAM, il che conta per i buffer di upload a chunk.
Quando gli upload paralleli non aiutano
Su connessioni residenziali asimmetriche (tipico: 1 Gbps in download, 40 Mbps in upload), il tuo upload è il collo di bottiglia, non l'ingestione del server. Spingere 8 stream paralleli da 5 MB ciascuno attraverso un pipe da 40 Mbps non va più veloce di 1 stream a 40 Mbps. Il parallelismo aiuta quando il tetto del singolo stream è al di sotto della capacità del pipe, non quando stai già saturando il link.
Lo stesso vale su cellular: con un solo bar di LTE, i worker extra producono per lo più ritrasmissioni.
Cosa cercare in un servizio
Se stai scegliendo uno strumento di trasferimento per file grandi frequenti, controlla tre cose: supporta upload a chunk riprendibili, quanti worker paralleli esegue la UI web, e usa HTTP/2 o HTTP/3 verso l'edge. I servizi che soddisfano tutti e tre sposteranno un file da 10 GB in pochi minuti su una connessione decente.
Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.
Invia file di grandi dimensioni in modo sicuro con crittografia end-to-end
Trasferisci file fino a 10 GB gratuitamente con crittografia end-to-end. Nessun account necessario. I tuoi file vengono crittografati nel browser prima del caricamento — nessun altro può leggerli.
Invia un file