Logo

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

L’avantage de FileBolt en matière de vitesse provient d’une combinaison de transport, de découpage parallèle en blocs, de topologie mondiale et de planification multi-source. Ce chapitre explique, de façon auditable, quels mécanismes améliorent le débit de pointe et lesquels améliorent la stabilité et la capacité de reprise en cas de perte de paquets ou de changement de réseau.

1.1 Objectifs de conception (angle vitesse)

  • Objectif A : approcher le plafond de bande passante. Dans des conditions typiques, chercher à saturer la bande passante disponible.
  • Objectif B : débit stable. Conserver un débit exploitable en cas de perte, de gigue, de changement de réseau et de RTT interrégional élevé, plutôt que de s’effondrer brutalement.
  • Objectif C : pannes récupérables. Lorsque des erreurs se produisent, limiter le coût à la retransmission d’une petite quantité de données seulement, en évitant de repartir de 0 %.

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

  • Le client et le point d’entrée en périphérie DEVRAIENT privilégier HTTP/3 (QUIC). Lorsque le navigateur, le réseau ou les équipements intermédiaires (middleboxes) ne le prennent pas en charge, le système DOIT basculer automatiquement vers HTTP/2 ou HTTP/1.1 pour préserver la disponibilité.
  • En cas de perte de paquets, le transport et le contrôle de congestion de QUIC peuvent souvent réduire l’impact du blocage en tête de file sur le débit de bout en bout et améliorer la stabilité (les résultats dépendent des conditions réseau).
  • Le 0-RTT et les chemins de négociation plus rapides sont des capacités de reprise de session, disponibles dans des conditions précises : le système PEUT en bénéficier lorsque ces conditions sont réunies, mais NE DOIT PAS s’y fier comme unique levier de performance.

Comment vérifier

  • Dans les DevTools de votre navigateur (par exemple Réseau / Protocole ; l’interface varie selon le navigateur), vous pouvez observer si les requêtes utilisent h3 (HTTP/3) ou basculent sur h2/h1.
  • Dans les mêmes conditions réseau, l’établissement de connexion et la stabilité du débit en h3 et hors h3 (en particulier en cas de RTT élevé ou de perte) peuvent différer nettement.

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

  • Le système DOIT découper logiquement les gros fichiers en plusieurs blocs ; chaque bloc est l’unité minimale d’envoi, de nouvelle tentative et de reprise (voir le chapitre 2).
  • Le client DEVRAIT transférer plusieurs blocs avec une concurrence limitée (par exemple plusieurs pipelines parallèles) afin de se rapprocher du plafond de bande passante et de réduire la sensibilité à la gigue d’une connexion unique.
  • Le client DOIT prendre en charge la reprise des transferts : lors de la reprise, il ignore les blocs terminés et ne récupère que les blocs manquants, ce qui évite de retransmettre le fichier entier (voir le chapitre 2).
  • La concurrence et le découpage en blocs réduisent nettement l’attente causée par le blocage d’une requête unique (y compris les attentes en tête de file et de retransmission), mais vous NE DEVEZ PAS prétendre « éliminer complètement » un phénomène réseau précis ; l’objectif est d’en réduire l’impact et d’améliorer la stabilité du débit.

Comment vérifier

  • Dans le panneau Réseau, vous pouvez observer plusieurs requêtes d’envoi/de téléchargement simultanées en parallèle (concurrence des blocs).
  • Après une déconnexion réseau ou un rechargement de la page, la reprise d’un transfert ne doit pas repartir de 0 % (seuls les blocs manquants sont complétés).

1.4 Avantage de topologie : accès Anycast au point de présence le plus proche (réseau de périphérie)

  • Le système DEVRAIT acheminer les requêtes des utilisateurs vers le nœud le plus proche via Anycast et un point d’entrée en périphérie, afin de réduire le RTT ainsi que la latence et la gigue causées par les sauts entre régions.
  • L’accès au point de présence le plus proche améliore l’efficacité globale du découpage parallèle en blocs : un RTT plus faible relève généralement le plafond de débit effectif de chaque flux concurrent, ce qui facilite la saturation du lien.
  • La couverture en périphérie et le nombre d’emplacements peuvent évoluer avec l’infrastructure ; en externe, présentez cela comme une « couverture en périphérie / entrée la plus proche » et traitez les chiffres comme des repères plutôt que comme des garanties fermes.

Comment vérifier

  • Avec traceroute ou les informations de connexion du navigateur, vous pouvez souvent constater que les connexions aboutissent à un point d’entrée plus proche (les méthodes varient selon l’environnement).
  • Dans les comparaisons entre régions (par exemple US↔UE / JP↔US), la réduction du RTT est généralement la plus visible.

1.5 Concurrence multi-source : ordonnancement intelligent (Multi-Source)

  • Le système DEVRAIT effectuer des choix dynamiques fondés sur des signaux de qualité de liaison (débit, latence, taux d’erreur, etc.), afin que différents blocs puissent être attribués à plusieurs nœuds ou emplacements de meilleure qualité, ce qui réduit l’impact de la congestion d’un point unique sur le débit global.
  • Lors du téléchargement, le client PEUT récupérer simultanément différents blocs auprès de plusieurs sources pour obtenir un effet d’accélération de type « récupération multi-source » ; lorsque le multi-source n’est pas disponible, il DOIT automatiquement se dégrader en téléchargement à source unique pour préserver la disponibilité (voir le chapitre 3).
  • Si vous présentez cela comme de l’« IA », mieux vaut le décrire comme un système algorithmique d’ordonnancement et de décision, et définir clairement les entrées/sorties et le comportement de dégradation pour éviter les affirmations vagues.

Comment vérifier

  • Pendant le téléchargement, vous pouvez observer des requêtes simultanées vers différentes sources/connexions (selon l’implémentation et ce que le navigateur rend visible).
  • En cas de congestion ou de perte, la concurrence multi-source offre souvent un débit plus stable ; lorsque les conditions ne sont pas réunies, elle se dégrade automatiquement mais reste utilisable.

1.6 Lien avec les chapitres suivants

  • Le chapitre 2 développe « le découpage en blocs, la concurrence, l’idempotence et l’envoi avec reprise » sous forme de flux et de contraintes implémentables (DOIT/DEVRAIT/PEUT) et explique pourquoi ils déterminent directement la vitesse et la stabilité de l’envoi.
  • Le chapitre 3 explique « le téléchargement parallèle, la reprise et le réassemblage » 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 minimal utile aux performances et à la capacité de reprise (couches objet et état, sémantique de TTL et de suppression).