Architettura di upload a blocchi: guida alla progettazione
Progetta un robusto sistema di upload a blocchi. Scopri strategie di chunking, upload ripristinabili e ottimizzazione del trasferimento parallelo.
Un'architettura di upload a blocchi divide un file in pezzi di dimensione fissa o variabile e li invia indipendentemente, così un'interruzione di rete non forza un riavvio da zero di un file da 10 GB. I due standard aperti dominanti sono AWS S3 Multipart Upload (parti minime da 5 MB, massimo 10.000 parti) e il protocollo tus.io ripristinabile (bozza RFC, ampiamente implementata). Eseguita correttamente, la upload a blocchi offre throughput da 5 a 10 volte superiore su link ad alta latenza, tollera le brevi disconnessioni e abilita la decifratura parallela sul lato ricevente. L'ACN (Agenzia per la Cybersicurezza Nazionale), nelle linee guida per la resilienza dei sistemi informativi, cita esplicitamente le architetture di upload ripristinabili come pratica consigliata per i sistemi che trattano dati soggetti al GDPR. Ecco come progettarne uno che regga in produzione.
Perché gli upload monolitici falliscono su larga scala
Un singolo HTTP PUT di un file da 5 GB incappa in mezza dozzina di modi per fallire. Le finestre di congestione TCP impiegano molto tempo a salire, limitando il throughput ben al di sotto della capacità del link su percorsi ad alta latenza. I browser limitano le connessioni concorrenti per origine a 6, lasciando la maggior parte della banda inutilizzata. I timeout di richiesta lato server (nginx predefinito 60 secondi, CloudFront 30 secondi per i non-streaming) uccidono gli upload lunghi. Le reti mobili che cambiano tra celle cadono la connessione ogni pochi minuti. E un singolo flip di bit forza il trasferimento completo a ripartire. Gli upload a blocchi risolvono tutti questi problemi rendendo l'unità di lavoro piccola, ripristinabile indipendentemente e adatta alla parallelizzazione.
Scelta della dimensione del blocco
La dimensione del blocco è un compromesso. Blocchi più piccoli si ripristinano più velocemente dai fallimenti e forniscono granularità di progresso più fine, ma aggiungono più overhead HTTP. Blocchi più grandi ammortizzano i costi di handshake e TLS ma sprecano banda quando un blocco fallisce e deve essere ritrasmesso. Intervalli tipici: da 1 MB a 5 MB per upload mobile su reti con perdita di pacchetti, da 5 MB a 16 MB per upload web desktop, da 16 MB a 64 MB per trasferimenti server-to-server su link affidabili, e 100 MB o più per S3 Multipart dove il limite di 10.000 parti forza blocchi più grandi su file da 1 TB. Alcuni sistemi si adattano dinamicamente, partendo piccoli e scalando man mano che la connessione si dimostra affidabile.
Chunking a dimensione fissa vs. basato sul contenuto
Il chunking a dimensione fissa (ogni 8 MB, per esempio) è banale da implementare, adatto alla parallelizzazione e supporta offset di ripristino esatti. Il chunking basato sul contenuto, usato in rsync e restic, sceglie i confini in base a un hash a finestra mobile come il fingerprinting di Rabin, così gli inserimenti nel mezzo di un file non spostano tutti i confini dei blocchi successivi. Il CDC è eccellente per la deduplicazione negli strumenti di backup, ma aggiunge complessità e costo CPU non ricompensati per il puro trasferimento di file. Per le architetture di upload, il chunking a dimensione fissa vince in semplicità e si mappa pulitamente alle parti multipart di S3 o agli offset di tus.io.
Protocolli di upload ripristinabili
Il protocollo tus.io, implementato in tusd (Go), tus-js-client, Uppy e molti framework server, usa HTTP PATCH con un header Upload-Offset per appendere i blocchi. Una richiesta HEAD restituisce l'offset corrente sul server, così il client sa da dove ripristinare dopo un'interruzione di rete. L'upload multipart di S3 usa un modello diverso: iniziare l'upload per ottenere un UploadId, caricare ogni parte (indicizzata da 1), poi inviare una richiesta CompleteMultipartUpload con la lista degli ETag. I client possono interrogare ListParts per vedere cosa è stato caricato. Entrambi i protocolli preservano lo stato tra i riavvii del client e gestiscono elegantemente le cadute di connessione.
Concorrenza degli upload paralleli
Il caricamento di blocchi in parallelo aumenta drasticamente il throughput su link ad alta latenza. HTTP/1.1 limita le connessioni concorrenti per origine a 6 nei browser; HTTP/2 multiplexa molti stream su una singola connessione ma sempre soggetto alle finestre di flow control. Un tipico scheduler di upload mette in coda i blocchi e ne spedisce da 4 a 8 in parallelo, con backpressure quando il server segnala 429 o 503. Troppa parallelizzazione attiva il throttling degli ISP e i limiti di connessione dei middlebox; troppo poca lascia la banda inutilizzata. Empiricamente, 4 stream paralleli sulla banda larga domestica e da 8 a 16 su fibra gigabit rappresentano il punto ottimale per la maggior parte dei carichi di lavoro.
Stato lato client e metadati di ripristino
Gli upload ripristinabili richiedono che il client ricordi abbastanza stato per ripristinare dopo un crash del browser o uno spegnimento del laptop. IndexedDB, parte dello standard Web Storage, conserva i manifesti di upload con l'hash del file, il conteggio dei blocchi e quali blocchi sono andati a buon fine. Indicizzare il manifesto per l'hash SHA-256 del file così il riaggiungimento dello stesso file riprende da dove si era interrotto. Pulire i manifesti obsoleti più vecchi di 7 giorni per evitare il gonfiamento. Su mobile, WKWebView (iOS) e Chrome Custom Tabs (Android) possono sfrattare IndexedDB sotto pressione di memoria, quindi persistere lo stato critico nello storage nativo quando possibile.
Gestione dei blocchi lato server
Il server deve riassemblare i blocchi in un file completo o, con S3 Multipart, delegare il riassemblaggio a S3. Un'architettura minimale: accettare ogni blocco PATCH, scrivere su un blob temporaneo indicizzato per ID di upload e indice del blocco, registrare l'offset in un datastore di metadati come Redis o PostgreSQL, e al CompletePart assemblare o marcare come completo. Usare object storage (S3, Cloudflare R2, Backblaze B2) per i blob dei blocchi piuttosto che il disco locale, poiché i backend bilanciati del carico non possono condividere facilmente lo stato locale. Fare garbage collection degli upload abbandonati dopo 24-72 ore per recuperare lo storage.
Verifica dell'integrità per blocco e end-to-end
Verificare ogni blocco con un hash all'upload. L'ETag di S3 Multipart è un hash MD5 per parte (o un hash composito per l'oggetto completo). Per un'integrità più forte, calcolare SHA-256 per blocco lato client e inviarlo in un header; il server lo conserva accanto al blocco e può verificare alla rilettura. Dopo che tutti i blocchi sono caricati, calcolare una radice dell'albero di Merkle o un hash streaming del file riassemblato e restituirlo al client. Il client confronta con il proprio hash del file originale. Qualsiasi mismatch innesca un re-upload dei blocchi con problemi.
Interazione della crittografia con il chunking
La crittografia end-to-end complica leggermente il chunking. Ogni blocco ha bisogno del proprio nonce per evitare il riutilizzo dell'IV in AES-GCM, e i confini dei blocchi devono far parte dello schema di autenticazione. Un approccio tipico: derivare una chiave per blocco tramite HKDF-SHA256 da una chiave di cifratura del file radice, usando l'indice del blocco come informazione di contesto, poi cifrare ogni blocco con AES-256-GCM e un nonce zero o incrementale. Includere l'indice del blocco e il conteggio totale dei blocchi nell'AAD così gli attaccanti non possono unire o riordinare i blocchi. Alla decifratura, verificare che tutti i blocchi siano presenti e in ordine prima di rilasciare il testo in chiaro.
Osservabilità per i sistemi a blocchi
Instrumentare ogni blocco. Metriche da tracciare: blocchi caricati al secondo, latenza di upload dei blocchi p50/p95/p99, tasso di retry per blocco, e tasso di upload abbandonati. I dashboard in Grafana o Datadog rivelano rapidamente le regressioni. Le trace distribuite tramite OpenTelemetry collegano una sessione client alla gestione dei blocchi lato server. Registrare eventi strutturati in JSON così sono ricercabili in Loki, Elasticsearch o Splunk. Quando un utente segnala un upload lento, la trace mostra esattamente quali blocchi si sono bloccati e perché.
Mettere tutto insieme
Un sistema di upload a blocchi pronto per la produzione combina blocchi da 5-16 MB, tus.io o S3 Multipart per il protocollo, 4-8 stream paralleli, stato di ripristino supportato da IndexedDB, controlli di integrità SHA-256 per blocco, e crittografia E2EE opzionale per blocco con chiave derivata. HexaTransfer usa la crittografia a blocchi lato client con AES-256-GCM e upload ripristinabili per gestire file da 10 GB in modo affidabile su connessioni instabili.
Provalo su hexatransfer.com — gratuito, senza account, massimo 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