Logo

Capitolo 1 Perché è più veloce: quattro meccanismi chiave

Il vantaggio di velocità di FileBolt nasce dalla combinazione di trasporto, suddivisione parallela in chunk, topologia globale e pianificazione multi-sorgente. Questo capitolo spiega, in modo verificabile, quali meccanismi aumentano il throughput di picco e quali migliorano stabilità e recuperabilità in caso di perdita di pacchetti o cambio di rete.

1.1 Obiettivi di progettazione (dal punto di vista della velocità)

  • Obiettivo A: avvicinarsi al massimo della banda. In condizioni tipiche, cercare di saturare la banda disponibile.
  • Obiettivo B: throughput stabile. Mantenere un throughput utilizzabile in presenza di perdite, jitter, cambi di rete e RTT elevato tra regioni, invece di crollare all'improvviso.
  • Obiettivo C: errori recuperabili. Quando si verificano errori, limitare il costo alla ritrasmissione di una piccola quantità di dati, evitando di ripartire da 0%.

1.2 Ottimizzazione a livello di trasporto: HTTP/3 (QUIC)

  • Il client e il punto d'ingresso edge DOVREBBERO preferire HTTP/3 (QUIC). Quando il browser, la rete o i middlebox non lo supportano, il sistema DEVE tornare automaticamente a HTTP/2 o HTTP/1.1 per preservare la disponibilità.
  • In caso di perdita di pacchetti, il trasporto e il controllo della congestione di QUIC possono spesso ridurre l'impatto del blocco head-of-line sul throughput end-to-end, migliorando la stabilità (i risultati dipendono dalle condizioni di rete).
  • 0-RTT e i percorsi di handshake più rapidi sono funzionalità di ripresa della sessione in condizioni specifiche: il sistema PUÒ trarne vantaggio quando le condizioni sono soddisfatte, ma NON DEVE contare su di esse come unica leva per le prestazioni.

Come verificare

  • Negli strumenti per sviluppatori del browser (ad es. Rete / Protocollo; l'interfaccia varia a seconda del browser) puoi vedere se le richieste usano h3 (HTTP/3) o passano a h2/h1.
  • A parità di condizioni di rete, confrontando apertura della connessione e stabilità del throughput tra h3 e non h3 (soprattutto con RTT elevato o perdite) le differenze possono essere evidenti.

1.3 Concorrenza estrema: streaming a chunk (Chunked Streaming)

  • Il sistema DEVE dividere logicamente i file di grandi dimensioni in più chunk; ogni chunk è l'unità minima per caricamento, nuovo tentativo e recupero (vedi capitolo 2).
  • Il client DOVREBBE trasferire più chunk con concorrenza limitata (ad es. diverse pipeline parallele) per avvicinarsi al massimo della banda e ridurre la sensibilità al jitter della singola connessione.
  • Il client DEVE supportare il trasferimento riprendibile: al recupero, salta i chunk già completati e scarica solo quelli mancanti, evitando di ritrasmettere l'intero file (vedi capitolo 2).
  • Concorrenza e suddivisione in chunk riducono in modo significativo le attese causate dal blocco di una singola richiesta (comprese le attese head-of-line e di ritrasmissione), ma NON DOVRESTI dichiarare di «eliminare completamente» un fenomeno di rete specifico; l'obiettivo è ridurne l'impatto e migliorare la stabilità del throughput.

Come verificare

  • Nel pannello Rete puoi vedere più richieste di upload/download in parallelo nello stesso momento (concorrenza dei chunk).
  • Dopo aver scollegato la rete o aggiornato la pagina, la ripresa di un trasferimento non dovrebbe ripartire da 0% (vengono completati solo i chunk mancanti).

1.4 Vantaggio di topologia: accesso Anycast all'edge più vicino (rete edge)

  • Il sistema DOVREBBE instradare le richieste degli utenti al nodo più vicino tramite Anycast / punto d'ingresso edge, per ridurre l'RTT e la latenza/il jitter causati dai salti tra regioni.
  • L'accesso all'edge più vicino migliora l'efficienza complessiva della suddivisione parallela in chunk: un RTT più basso di solito alza il tetto di throughput effettivo di ogni flusso concorrente, rendendo più facile saturare il collegamento.
  • La copertura edge e il numero di sedi possono cambiare con l'evoluzione dell'infrastruttura; all'esterno, descrivila come «copertura edge / ingresso più vicino» e considera i numeri come indicativi e non come garanzie.

Come verificare

  • Con traceroute o le informazioni di connessione del browser spesso si vede che le connessioni terminano su un punto d'ingresso più vicino (i metodi variano a seconda dell'ambiente).
  • Nei confronti tra regioni (ad es. US↔EU / JP↔US), la riduzione dell'RTT è di solito quella più visibile.

1.5 Concorrenza multi-sorgente: pianificazione intelligente (Multi-Source)

  • Il sistema DOVREBBE fare scelte dinamiche in base ai segnali di qualità del collegamento (throughput, latenza, tasso di errore e così via), così che chunk diversi possano essere assegnati a più nodi o posizioni migliori, riducendo l'impatto della congestione di un singolo punto sul throughput complessivo.
  • Nel download, il client PUÒ recuperare chunk diversi in parallelo da più sorgenti per ottenere un effetto di accelerazione da «pull multi-sorgente»; quando il multi-sorgente non è disponibile DEVE passare automaticamente al download da sorgente singola per preservare la disponibilità (vedi capitolo 3).
  • Se lo presenti come «IA», conviene descriverlo come un sistema algoritmico di pianificazione e decisione e definire con chiarezza input, output e comportamento di degrado, per evitare affermazioni vaghe.

Come verificare

  • Durante il download puoi vedere richieste concorrenti da sorgenti o connessioni diverse (a seconda dell'implementazione e di ciò che il browser mostra).
  • In caso di congestione o perdite, la concorrenza multi-sorgente spesso offre un throughput più stabile; quando le condizioni non sono soddisfatte degrada automaticamente ma resta utilizzabile.

1.6 Collegamento con i capitoli successivi

  • Il capitolo 2 sviluppa «chunk, concorrenza, idempotenza e caricamento riprendibile» in flussi e vincoli implementabili (MUST/SHOULD/MAY) e spiega perché determinano direttamente velocità e stabilità del caricamento.
  • Il capitolo 3 spiega «download parallelo, recupero e riassemblaggio» e come evitare la perdita di velocità dovuta ai download ridondanti su reti deboli.
  • Il capitolo 4 conserva solo il modello di archiviazione minimo rilevante per prestazioni e recuperabilità (livelli oggetto e stato, semantica di TTL ed eliminazione).