Riprendere trasferimenti interrotti: mai ripartire da zero

I trasferimenti riprendibili dividono un file in chunk e tengono traccia di quali chunk sono stati ricevuti correttamente; quando la connessione cade, il client riprende dal prossimo chunk non inviato invece di ripartire dal byte zero. Lo standard web per questo è tus.io (un protocollo di upload riprendibile aperto), implementato da SwissTransfer, HexaTransfer, Vimeo, Cloudinary e molti servizi di trasferimento moderni. Per i download, le richieste HTTP Range (RFC 7233) permettono a browser e strumenti come curl o aria2 di riprendere i download interrotti. Senza la riprendibilità, un upload da 9,8 GB che fallisce a 9,5 GB costa l'intero trasferimento — con la riprendibilità, si perdono forse 50 MB.

Il problema degli upload non riprendibili

Un upload di file classico invia l'intero file come un'unica richiesta HTTP POST. Se qualcosa interrompe la connessione — caduta del Wi-Fi, timeout VPN, sleep del laptop, problema ISP — la connessione TCP si chiude e il server scarta i dati parziali ricevuti. Il client riparte dal byte zero.

Per un upload da 5 GB su una connessione da 50 Mbps, si buttano via 13 minuti di lavoro. Per un upload da 50 GB, sono oltre due ore. Il tasso di fallimento degli upload non riprendibili su connessioni mobili è brutale: un upload da 30 minuti su una connessione 4G raramente riesce al primo tentativo.

Come funzionano i protocolli riprendibili

Gli upload riprendibili moderni funzionano più o meno così:

Creazione: il client invia una POST al server con la dimensione totale del file e i metadati. Il server restituisce un URL univoco per questo upload specifico e riserva lo spazio di archiviazione.
Chunking: il client divide il file in chunk (comunemente da 5 a 64 MB ciascuno).
Upload: il client invia ogni chunk come richiesta PATCH con un header Content-Range o Upload-Offset che indica la posizione del chunk.
Acknowledgment: il server scrive il chunk nell'archiviazione e conferma il nuovo offset.
Ripresa: se la connessione cade, il client invia una richiesta HEAD all'URL di upload. Il server risponde con l'offset attuale (quanti byte ha ricevuto). Il client riprende da quell'offset.
Completamento: quando l'ultimo chunk viene confermato, l'upload è completo.

Questo modello è definito dalla specifica tus.io (la versione 1.0.0 è ampiamente distribuita). Altre varianti includono S3 Multipart Upload (per upload diretti su S3) e Google Cloud Storage Resumable Uploads.

Tus.io: lo standard aperto

Tus ("transloadit upload server") è un protocollo libero e aperto mantenuto da Transloadit. La specifica si trova su tus.io ed è implementata da:

Librerie client: tus-js-client (browser + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
Implementazioni server: tusd (server di riferimento in Go), tus-node-server, e molte integrazioni di framework
Servizi commerciali: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, i server companion di Uppy

Il protocollo è deliberatamente minimale: quattro verbi HTTP (POST, HEAD, PATCH, OPTIONS), una manciata di header (Upload-Offset, Upload-Length, Tus-Resumable). Questo mantiene le implementazioni semplici e interoperabili.

Decisioni sulla dimensione dei chunk

La dimensione del chunk bilancia granularità della ripresa e overhead HTTP.

| Dimensione chunk | Costo di recupero in caso di fallimento | Overhead | |---|---|---| | 1 MB | Perdi ≤ 1 MB | Alto (molte richieste) | | 5 MB | Perdi ≤ 5 MB | Moderato | | 16 MB | Perdi ≤ 16 MB | Basso | | 64 MB | Perdi ≤ 64 MB | Minimo | | 256 MB | Perdi ≤ 256 MB | Overhead trascurabile, doloroso in caso di fallimento |

Per connessioni stabili, chunk da 32-64 MB massimizzano il throughput. Per mobile o Wi-Fi instabile, chunk da 2-5 MB si recuperano più velocemente da ogni fallimento. I servizi scelgono di solito un valore predefinito nell'intervallo 5-10 MB come compromesso.

Cosa interrompe davvero i trasferimenti

Capire le modalità di fallimento aiuta a valutare se l'implementazione di ripresa di un servizio è solida:

Cadute Wi-Fi: cambio di rete, perdita di segnale, riavvio del router. Molto comuni.
Sleep del laptop: chiudere il coperchio su macOS/Windows. Il sistema operativo mette in pausa la rete; al risveglio, le connessioni spesso devono essere ristabilite.
Sospensione dei tab: i browser moderni sospendono i tab in background per risparmiare memoria. Gli upload in un tab sospeso possono bloccarsi.
Problemi ISP/backhaul: cambi di routing momentanei, rihandshake TLS richiesto.
Riconnessione VPN: i client VPN rinegoziamo periodicamente; la connessione TCP muore.
Riavvii lato server: il servizio di trasferimento distribuisce una nuova versione; le richieste in volo falliscono.
Modifiche alle policy cross-origin: i firewall aziendali che ispezionano il traffico a volte uccidono le connessioni di lunga durata.

Un'implementazione riprendibile solida gestisce tutto questo con lo stesso meccanismo: riconnetti, HEAD per controllare l'offset, riprendi da lì.

Ripresa per i download

Le richieste HTTP Range (RFC 7233) alimentano i download riprendibili. Un server che pubblicizza Accept-Ranges: bytes negli header di risposta supporta le richieste range. I client possono quindi emettere Range: bytes=1000000- per recuperare solo i byte dall'offset 1.000.000 in poi.

I browser lo usano automaticamente quando clicchi "Riprendi" nel gestore download. Chrome, Firefox e Safari supportano tutti la ripresa per i download da server conformi. La maggior parte dei CDN (Cloudflare, Fastly, CloudFront) supporta i range.

Gli strumenti da riga di comando offrono più controllo:

curl -C - -O url riprende un download da dove si era fermato.
wget -c url fa lo stesso.
aria2c -c -s 16 url scarica con 16 stream paralleli di richieste range per la velocità.

Servizi che supportano la ripresa

I servizi di trasferimento moderni gestiscono per lo più la ripresa degli upload:

| Servizio | Ripresa upload | Ripresa download | |---|---|---| | SwissTransfer | Sì (basato su tus) | Sì (HTTP ranges) | | HexaTransfer | Sì (chunked + compatibile tus) | Sì | | WeTransfer | Sì (upload a chunk) | Sì | | Dropbox Transfer | Sì | Sì | | Google Drive | Sì (API di upload riprendibile) | Sì | | OneDrive | Sì | Sì | | Box | Sì | Sì |

I livelli gratuiti a volte disabilitano la ripresa per incoraggiare gli upgrade a pagamento, ma nel 2026 questo è raro. I servizi più vecchi senza supporto alla ripresa stanno scomparendo dalle liste di raccomandazione perché gli utenti si stancano dei fallimenti.

Cosa non riprende automaticamente

Gli upload HTTP POST semplici nelle applicazioni tradizionali non riprendono. I trasferimenti FTP variano storicamente — alcuni client e server supportano i comandi REST (restart), altri no. Gli allegati email non possono essere ripresi: se un invio Gmail fallisce al 90%, si riparte da zero.

I trasferimenti tramite torrent riprendono intrinsecamente perché il protocollo torrent tiene traccia di quali pezzi sono stati verificati. Questo è in parte il motivo per cui BitTorrent è rimasto utile per distribuzioni molto grandi anche quando il web ha recuperato terreno su altre metriche.

Ripresa con cifratura end-to-end

Gli upload riprendibili combinati con la cifratura lato client richiedono un chunking attento. Il file viene diviso in chunk, ogni chunk viene cifrato con AES-256-GCM usando un IV (vettore di inizializzazione) unico, e poi caricato. Alla ripresa, il client deve sapere quali chunk sono stati completati e continuare dal successivo.

Poiché ogni chunk è cifrato e autenticato in modo indipendente (la modalità AEAD di GCM), gli upload parziali non possono essere manomessi. Un server malevolo che inserisce dati corrotti all'offset 5 GB fallirebbe l'autenticazione quando il destinatario decifrasse — il mismatch del tag GCM verrebbe rilevato.

Implementazioni come HexaTransfer usano IV per chunk derivati deterministicamente da una chiave master e dall'indice del chunk, così la ripresa non richiede di memorizzare gli IV separatamente. Il lato di decifratura li ricostruisce dalla stessa derivazione.

Buone pratiche lato client

Per massimizzare il successo della ripresa:

Mantieni il tab attivo durante l'upload. La sospensione del tab del browser uccide gli upload in corso. Un avviso "non chiudere questo tab" è standard nelle UI dei servizi di trasferimento.
Collegati con cavo quando possibile. Le cadute Wi-Fi causano la maggior parte dei fallimenti.
Disabilita il risparmio energetico durante gli upload lunghi. macOS: caffeinate -i. Windows: l'utility Awake di Powertoys o le modifiche al piano di alimentazione.
Non cambiare rete Wi-Fi durante l'upload. La connessione TCP cambia IP e muore.
Lascia finire l'upload prima di chiudere il coperchio del laptop. Il macOS moderno a volte preserva gli upload attraverso brevi sleep, ma non è affidabile.

Verifica lato server

Alcuni servizi mostrano barre di avanzamento incomplete che non riflettono effettivamente lo stato del server. Dopo un upload sopravvissuto a una o due interruzioni, aggiorna la pagina e verifica che il link funzioni: aprilo in incognito e scarica una piccola porzione. Se la ripresa ha funzionato, il file completo si scaricherà correttamente.

Per scenari che richiedono la massima certezza, calcola un hash SHA-256 sul client, carica, e verifica che hashare il file scaricato corrisponda. Un controllo crittografico dell'integrità del file richiede 10 secondi di CPU per gigabyte e dà certezza assoluta.

In sintesi

Il trasferimento riprendibile è una funzione irrinunciabile nel 2026: qualsiasi servizio che non la supporta è fuori discussione per file oltre qualche centinaio di megabyte. Cerca la conformità tus.io o un comportamento equivalente di upload a chunk. Assicurati che il servizio che scegli gestisca le interruzioni con grazia; testa con una caduta deliberata della rete su un file piccolo prima di impegnarti in un trasferimento grande.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.