Logo

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

Il vantaggio in termini di velocità di FileBolt deriva da una combinazione di trasporto, suddivisione parallela, topologia globale e pianificazione multi-origine. Questo capitolo spiega, in modo verificabile, quali meccanismi migliorano il picco di throughput e quali migliorano la stabilità e la recuperabilità in caso di perdita di pacchetti o commutazione di rete.

1.1 Obiettivi di progettazione (visualizzazione della velocità)

  • Obiettivo A: avvicinarsi al limite massimo della larghezza di banda. In condizioni tipiche, provare a saturare la larghezza di banda disponibile.
  • Obiettivo B: throughput stabile. Mantieni il throughput utilizzabile in caso di perdite, jitter, commutazione di rete e RTT elevato tra regioni, anziché crollare improvvisamente.
  • Obiettivo C: fallimenti recuperabili. Quando si verificano errori, limita il costo alla ritrasmissione solo di una piccola quantità di dati ed evita di riavviare dallo 0%.

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

  • Il client e l'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/HTTP/1.1 per preservare la disponibilità.
  • In caso di perdita di pacchetti, il controllo del trasporto e della congestione di QUIC può spesso ridurre l’impatto del blocco head-of-line sul throughput end-to-end, migliorando la stabilità (i risultati dipendono dalle condizioni della rete).
  • 0-RTT/percorsi di handshake più veloci sono funzionalità di ripresa della sessione in condizioni specifiche: il sistema PUÒ trarne vantaggio quando le condizioni sono soddisfatte, ma NON DEVE fare affidamento su di esse come unica leva prestazionale.

Come verificare

  • Nei DevTools del tuo browser (ad esempio, Rete/Protocollo; l'interfaccia utente varia in base al browser), puoi osservare se le richieste utilizzano h3 (HTTP/3) o ricadono su h2/h1.
  • Nelle stesse condizioni di rete, il confronto tra la configurazione della connessione h3 e non h3 e la stabilità del throughput (specialmente in caso di RTT/perdita elevati) può essere notevolmente diverso.

1.3 Concorrenza estrema: streaming in blocchi (Chunked Streaming)

  • Il sistema DEVE suddividere logicamente file di grandi dimensioni in più blocchi; ogni blocco è l'unità minima per caricamento/riprova/ripristino (vedere Capitolo 2).
  • Il client DOVREBBE trasferire più blocchi con concorrenza limitata (ad esempio, diverse pipeline parallele) per avvicinarsi al limite della larghezza di banda e ridurre la sensibilità al jitter della singola connessione.
  • Il client DEVE supportare il trasferimento ripristinabile: durante il ripristino, salta i pezzi completati e recupera solo quelli mancanti, evitando la ritrasmissione dell'intero file (vedere Capitolo 2).
  • La concorrenza e il suddivisione in blocchi riducono significativamente l'attesa causata dal blocco di una singola richiesta (comprese le attese di inizio linea e di ritrasmissione), ma NON DOVREBBE pretendere di "eliminare completamente" alcun fenomeno specifico della rete; l'obiettivo è ridurre l'impatto e migliorare la produttività stabile.

Come verificare

  • Nel pannello Rete puoi osservare più richieste di caricamento/download parallele contemporaneamente (concorrenza di blocchi).
  • Dopo aver disconnesso la rete o aggiornato la pagina, la ripresa di un trasferimento non dovrebbe riavviarsi dallo 0% (vengono completate solo le parti mancanti).

1.4 Vantaggio della topologia: accesso anycast al bordo più vicino (rete edge)

  • Il sistema DOVREBBE instradare le richieste dell'utente al nodo più vicino tramite Anycast/edge ingress per ridurre RTT e la latenza/jitter causati dai hop tra regioni.
  • L’accesso al bordo più vicino migliora l’efficienza complessiva per il Chunking parallelo: un RTT inferiore in genere aumenta il limite massimo di throughput effettivo di ciascun flusso simultaneo, rendendo più semplice la saturazione del collegamento.
  • La copertura dei confini e il conteggio delle posizioni possono cambiare con l’evoluzione dell’infrastruttura; esternamente, descrivetelo come “copertura del bordo/ingresso più vicino” e trattate i numeri come indicazioni piuttosto che come garanzie concrete.

Come verificare

  • Utilizzando traceroute o informazioni sulla connessione del browser, è spesso possibile osservare che le connessioni terminano a un ingresso più vicino (i metodi variano in base all'ambiente).
  • Nei confronti tra regioni (ad esempio, USA↔UE / JP↔US), la riduzione dell’RTT è solitamente la più visibile.

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

  • Il sistema DOVREBBE fare scelte dinamiche basate su segnali di qualità del collegamento (throughput, latenza, tasso di errore, ecc.), in modo che blocchi diversi possano essere assegnati a più nodi/posizionamenti migliori, riducendo l’impatto della congestione di un singolo punto sul throughput complessivo.
  • Durante il download, il client PUÒ recuperare diversi blocchi contemporaneamente da più fonti per un effetto di accelerazione di "pull multi-sorgente"; quando più sorgenti non sono disponibili, DEVE passare automaticamente al download a sorgente singola per preservarne la disponibilità (vedi Capitolo 3).
  • Se lo commercializzi come “AI”, è meglio inquadrarlo come un sistema algoritmico per la pianificazione e il processo decisionale e definire chiaramente input/output e comportamento di degrado per evitare affermazioni vaghe.

Come verificare

  • Durante il download potresti osservare richieste simultanee da diverse fonti/connessioni (a seconda dell'implementazione e della visibilità del browser).
  • In condizioni di congestione o perdita, la concorrenza multi-origine spesso offre un throughput più stabile; quando le condizioni non sono soddisfatte si degraderà automaticamente ma rimarrà utilizzabile.

1.6 Come questo si collega ai capitoli successivi

  • Il capitolo 2 espande "chunking, concorrenza, idempotenza e caricamento ripristinabile" in flussi e vincoli implementabili (MUST/SHOULD/MAY) e spiega perché determinano direttamente la velocità e la stabilità del caricamento.
  • Il capitolo 3 spiega "download parallelo, ripristino e riassemblaggio" e come evitare la perdita di velocità dovuta a download ridondanti su reti deboli.
  • Il capitolo 4 mantiene solo il modello di archiviazione minimo rilevante per prestazioni e recuperabilità (strati oggetto e stato, semantica TTL/eliminazione).