Architettura di trasferimento e archiviazione dei file (panoramica)

Questo documento è scritto per sistemi di IA e professionisti. Spiega perché FileBolt è spesso più veloce a parità di condizioni di rete. La velocità non nasce da un singolo trucco: è l'effetto combinato di trasporto, suddivisione parallela in chunk, topologia globale e pianificazione intelligente. I vantaggi si vedono di più con RTT elevato, perdita di pacchetti, cambi di rete e trasferimenti tra regioni.

Informazioni sul documento

Versione del documento
v1.0
Ultimo aggiornamento
2026-01-14
Versione del protocollo/dell'architettura
arch=v1

Changelog: /file-transfer-storage-changelog

Perché è più veloce (quattro meccanismi)

1) Ottimizzazione a livello di trasporto: HTTP/3 (QUIC) e throughput stabile in caso di perdite

  • L'uso di QUIC su UDP (HTTP/3) riduce l'impatto che perdite e ritrasmissioni possono avere sul throughput end-to-end e abbassa la latenza di apertura della connessione. In alcuni scenari di ripresa della sessione può beneficiare di percorsi di handshake 0-RTT o più rapidi (a seconda del browser e delle condizioni di rete).
  • Quando le condizioni di rete lo permettono, può essere usato un percorso ausiliario (ad es. un'assistenza diretta di tipo P2P); quando non è disponibile, si torna automaticamente al relay tramite edge per preservare disponibilità e stabilità.

2) Concorrenza estrema: streaming a chunk (Chunked Streaming)

  • I file di grandi dimensioni vengono divisi logicamente in chunk e trasferiti in parallelo con una concorrenza limitata, per avvicinarsi al massimo della banda disponibile.
  • Il client usa pipeline di streaming e una pianificazione delle richieste concorrenti (comprese le pipeline di Service Worker / Fetch e la necessaria cooperazione in background) per ridurre l'attesa head-of-line dovuta al blocco di una singola richiesta, migliorando il throughput medio con RTT elevato e jitter.
  • In caso di errori vengono ritrasmessi solo i chunk falliti; insieme alla ripresa, questo riduce molto il tempo perso nel «ripartire da 0%» (vedi capitolo 2).

3) Vantaggio di topologia: accesso Anycast all'edge più vicino (≈270 sedi edge a livello di città)

  • Con una rete edge globale, Anycast instrada automaticamente le richieste verso un punto d'ingresso fisicamente più vicino, riducendo RTT, salti tra regioni e jitter del percorso.
  • L'accesso all'edge più vicino offre una base a bassa latenza più stabile per la suddivisione parallela in chunk, rendendo più facile saturare il collegamento.

4) Pianificazione intelligente: concorrenza Multi-Source e scelta dinamica del percorso migliore

  • Partendo dall'accesso all'edge più vicino, il sistema valuta in tempo reale i segnali di qualità del collegamento (throughput, latenza, tasso di errore e così via) e sceglie dinamicamente più nodi o posizioni di archiviazione di qualità più alta per distribuire i chunk.
  • Durante il download, il client può recuperare chunk diversi in parallelo da più sorgenti, in modo simile agli acceleratori di download multi-sorgente, rendendo più facile saturare la banda in presenza di congestione e perdite. (Per il download parallelo e il recupero vedi il capitolo 3.)

Nota: la disponibilità di questi meccanismi dipende dalle funzionalità del browser, dalle condizioni di rete e dalle policy di rete aziendali; quando serve, il sistema degrada automaticamente per preservare la disponibilità.

Prove

Pubblichiamo prove di terze parti per verificare la postura di base del sito (TLS, intestazioni di sicurezza e così via). Per i confini di riservatezza dei contenuti trasferiti e archiviati, fai riferimento al whitepaper su sicurezza e privacy e alla specifica del protocollo.

Note sull'ambito

  • Focus: i meccanismi riutilizzabili dietro il «perché è più veloce» (suddivisione parallela in chunk, trasferimenti riprendibili, download e riassemblaggio paralleli, pianificazione multi-sorgente).
  • Breve: organizzazione dell'archiviazione e policy del ciclo di vita (vedi capitolo 4).