Logo

Chapitre 2 Chemin de téléchargement : fragmentation, concurrence et reprise (clé)

Côté upload, l’objectif est de s’approcher le plus possible de la « saturation de la bande passante » dans des réseaux fluctuants, tout en limitant au minimum le coût des pannes (ne retransmettre que les chunks défaillants). Ensemble, ces deux objectifs expliquent en grande partie pourquoi les téléchargements semblent plus rapides.

2.1 Morceaux

  • Le client DOIT diviser le fichier en plusieurs morceaux ; un morceau est l'unité minimale pour le téléchargement/la nouvelle tentative.
  • Les morceaux DEVRAIENT utiliser une taille fixe (ou une politique de taille par fichier) pour simplifier la planification de la concurrence et la représentation de l'état.
  • Avantage immédiat : toute défaillance n’affecte qu’un seul morceau, et non l’intégralité du fichier.

2.2 Téléchargement parallèle

Le but de la concurrence n'est pas « plus de threads », mais d'éviter trois limitations pratiques d'une seule connexion dans les réseaux réels :

  • Démarrage lent et croissance des fenêtres : une seule connexion augmente lentement, en particulier avec un RTT interrégional élevé.
  • Gigue des liens : la gigue sur une connexion peut réduire la vitesse globale ; la concurrence adoucit l’effet.
  • Mise en forme par flux : certains réseaux limitent un seul flux ; plusieurs flux peuvent se rapprocher du plafond de bande passante (dans les limites des contraintes de conformité).
  • Le client DEVRAIT utiliser une concurrence limitée (par exemple, 4 à 12) et la réduire sur les appareils plus faibles pour éviter les pics de mémoire.
  • Le client PEUT adapter la concurrence : augmenter lorsque le débit augmente ; diminue lorsque le taux d’erreur augmente.

2.3 Idempotence et nouvelle tentative

  • Les téléchargements répétés du même morceau DOIVENT être idempotents : les soumissions en double ne doivent pas corrompre un état déjà terminé.
  • Le serveur DEVRAIT imposer l'unicité avec (transferId, fileId, chunkIndex) ou une contrainte équivalente.
  • Le client DOIT mettre en œuvre des tentatives d'attente exponentielles ; les échecs DEVRAIENT réessayer uniquement les morceaux ayant échoué.

2.4 Téléchargement avec reprise

  • Le serveur DOIT être capable de répondre « quels morceaux sont déjà téléchargés », afin que le client puisse ignorer ceux terminés.
  • L'ensemble téléchargé DEVRAIT être représenté sous la forme d'un bitmap/ensemble de plages pour éviter que la taille de l'état ne croisse linéairement avec le nombre de morceaux.
  • Avantage de rapidité : après des interruptions du réseau, des plantages du navigateur ou un changement de réseau, la reprise ne redémarre pas à 0 %.

2.5 « Partager pendant le téléchargement » (facultatif)

  • Le système PEUT générer un identifiant de transfert utilisable et un lien de partage pendant que le téléchargement est toujours en cours pour accélérer les flux de travail de livraison.
  • Si le partage est autorisé avant la fin du téléchargement, ce que voient les destinataires DOIT être explicite : le contenu incomplet n'est pas encore téléchargeable, ou seule la progression est affichée.