Logo

Chapitre 1 Pourquoi c'est plus rapide : quatre mécanismes clés

L'avantage de FileBolt en termes de vitesse provient d'une combinaison de transport, de segmentation parallèle, de topologie globale et de planification multi-sources. Ce chapitre explique, de manière vérifiable, quels mécanismes améliorent le débit de pointe et lesquels améliorent la stabilité et la récupérabilité en cas de perte de paquets ou de commutation de réseau.

1.1 Objectifs de conception (vue rapide)

  • Objectif A : approcher le plafond de bande passante. Dans des conditions typiques, essayez de saturer la bande passante disponible.
  • Objectif B : Débit stable. Conservez un débit utilisable en cas de perte, d'instabilité, de commutation réseau et de RTT interrégional élevé, plutôt que de s'effondrer soudainement.
  • Objectif C : Pannes récupérables. Lorsque des erreurs se produisent, limitez le coût à la retransmission d'une petite quantité de données seulement : évitez de redémarrer à partir de 0 %.

1.2 Optimisation de la couche transport : HTTP/3 (QUIC)

  • Le client et l'entrée Edge DEVRAIENT préférer HTTP/3 (QUIC). Lorsque le navigateur, le réseau ou les middlebox ne le prennent pas en charge, le système DOIT automatiquement revenir à HTTP/2/HTTP/1.1. pour préserver la disponibilité.
  • En cas de perte de paquets, le contrôle du transport et de la congestion de QUIC peut souvent réduire l'impact du blocage en tête de ligne sur le débit de bout en bout, améliorant ainsi la stabilité (les résultats dépendent des conditions du réseau).
  • Les chemins 0-RTT/prise de contact plus rapides sont des capacités de reprise de session dans des conditions spécifiques : le système PEUT bénéficier lorsque les conditions sont remplies, mais NE DOIT PAS s'appuyer sur elles comme seul levier de performances.

Comment vérifier

  • Dans les DevTools de votre navigateur (par exemple, Réseau/Protocole ; l'interface utilisateur varie selon le navigateur), vous pouvez observer si les requêtes utilisent h3 (HTTP/3) ou reviennent à h2/h1.
  • Dans les mêmes conditions de réseau, la comparaison de la configuration des connexions h3 et non-h3 et de la stabilité du débit (en particulier dans des conditions de RTT/perte élevées) peut être sensiblement différente.

1.3 Concurrence extrême : streaming fragmenté (Chunked Streaming)

  • Le système DOIT logiquement diviser les gros fichiers en plusieurs morceaux ; chaque morceau est l'unité minimale pour le téléchargement/la nouvelle tentative/la récupération (voir le chapitre 2).
  • Le client DEVRAIT transférer plusieurs morceaux avec une concurrence limitée (par exemple, plusieurs pipelines parallèles) pour se rapprocher du plafond de bande passante et réduire la sensibilité à la gigue d'une connexion unique.
  • Le client DOIT prendre en charge le transfert pouvant être repris : lors de la récupération, ignorer les morceaux terminés et récupérer uniquement ceux manquants, en évitant la retransmission du fichier complet (voir Chapitre 2).
  • La concurrence et le chunking réduisent considérablement l'attente provoquée par le blocage d'une seule requête (y compris les attentes en tête de ligne et de retransmission), mais vous NE DEVEZ PAS prétendre « éliminer complètement » tout phénomène de réseau spécifique ; l’objectif est de réduire l’impact et d’améliorer un débit stable.

Comment vérifier

  • Dans le panneau Réseau, vous pouvez observer plusieurs demandes de téléchargement/téléchargement parallèles en même temps (concurrence de morceaux).
  • Après avoir déconnecté le réseau ou actualisé la page, la reprise d'un transfert ne doit pas redémarrer à 0 % (seuls les morceaux manquants sont terminés).

1.4 Avantage topologique : accès Anycast au bord le plus proche (réseau périphérique)

  • Le système DEVRAIT acheminer les requêtes des utilisateurs vers un nœud le plus proche via une entrée Anycast/edge pour réduire le RTT et la latence/gigue provoquée par les sauts entre régions.
  • L'accès au bord le plus proche améliore l'efficacité globale du regroupement parallèle : un RTT plus faible augmente généralement le plafond de débit effectif de chaque flux simultané, ce qui facilite la saturation de la liaison.
  • La couverture périphérique et le nombre d'emplacements peuvent changer à mesure que l'infrastructure évolue ; en externe, décrivez cela comme « couverture périphérique / entrée la plus proche » et traitez les chiffres comme des indications plutôt que comme des garanties concrètes.

Comment vérifier

  • En utilisant traceroute ou les informations de connexion du navigateur, vous pouvez souvent observer que les connexions se terminent à une entrée plus proche (les méthodes varient selon l'environnement).
  • Dans les comparaisons interrégionales (par exemple, États-Unis↔UE / Japon↔États-Unis), la réduction du RTT est généralement la plus visible.

1.5 Concurrence multi-source : planification intelligente (Multi-Source)

  • Le système DEVRAIT faire des choix dynamiques basés sur des signaux de qualité de liaison (débit, latence, taux d'erreur, etc.), afin que différents morceaux puissent être attribués à plusieurs meilleurs nœuds/emplacements, réduire l’impact de la congestion en un seul point sur le débit global.
  • Lors du téléchargement, le client PEUT récupérer différents morceaux simultanément à partir de plusieurs sources pour un effet d'accélération « d'extraction multi-sources » ; lorsque plusieurs sources ne sont pas disponibles, elles DOIVENT automatiquement se dégrader en téléchargement à source unique pour préserver la disponibilité (voir chapitre 3).
  • Si vous commercialisez cela sous le nom d’« IA », il est préférable de le présenter comme un système algorithmique de planification et de prise de décision, et de définir clairement les entrées/sorties et le comportement de dégradation pour éviter des affirmations vagues.

Comment vérifier

  • Pendant le téléchargement, vous pouvez observer des requêtes simultanées provenant de différentes sources/connexions (en fonction de l'implémentation et de la visibilité du navigateur).
  • En cas de congestion ou de perte, la concurrence multi-sources offre souvent un débit plus stable ; lorsque les conditions ne sont pas remplies, il se dégradera automatiquement mais restera utilisable.

1.6 Comment cela correspond aux chapitres suivants

  • Le chapitre 2 développe « le découpage, la concurrence, l'idempotence et le téléchargement avec reprise » en flux et contraintes implémentables (DOIT/DEVRAIT/PEUT) et explique pourquoi ils déterminent directement la vitesse et la stabilité du téléchargement.
  • Le chapitre 3 explique « le téléchargement, la récupération et le réassemblage parallèles » et comment éviter les pertes de vitesse dues aux téléchargements redondants sur des réseaux faibles.
  • Le chapitre 4 ne conserve que le modèle de stockage minimum pertinent pour les performances et la récupérabilité (couches objet/état, sémantique TTL/suppression).