Techniques d'upload parallèle : maximiser la bande passante

Les uploads parallèles découpent un fichier en morceaux (typiquement 5 à 100 Mo chacun) et les poussent sur plusieurs connexions TCP simultanées, contournant le plafond de débit qu'un flux unique atteint sur les liens à forte latence. Le multipart upload d'Amazon S3, les resumable uploads de Google Cloud Storage et tus.io l'implémentent tous. Sur une ligne 1 Gbps avec 80 ms de latence vers le serveur de destination, un PUT HTTP unique sature typiquement à 150 Mbps, alors que 8 flux parallèles dépassent 900 Mbps. Le gain est réel et prévisible une fois qu'on comprend pourquoi.

Pourquoi un seul flux ne suffit pas

Le contrôle de congestion de TCP utilise une fenêtre glissante pour décider de la quantité de données non confirmées à garder en vol. Sur un gros tuyau à forte latence, la taille de fenêtre par défaut (autour de 16 Mo sur Linux 5.x, moins sur les noyaux plus anciens) se remplit avant le retour des ACK, et l'expéditeur reste inactif à attendre. C'est le problème du « produit bande-passante × délai », et c'est pour ça qu'un transfert FTP unique vers un serveur à Singapour depuis Paris plafonne autour de 30 Mbps même sur une ligne gigabit.

Faire tourner plusieurs connexions parallèles contourne le souci parce que chaque connexion a sa propre fenêtre. Huit flux à 30 Mbps font 240 Mbps, et c'est avant de compter la sélection d'edge CDN, qui route souvent différentes connexions par différents points d'entrée.

Découpage : quelle taille, combien

Le sweet spot dépend de la latence et de la perte de paquets. Pour les transferts intra-continentaux sous 50 ms de RTT, des morceaux de 10 Mo avec 4 workers parallèles saturent la plupart des lignes grand public. Pour les liens transcontinentaux ou mobiles capricieux (plus de 100 ms de RTT, plus de 0,5 % de perte), descendez à des morceaux de 5 Mo avec 8 à 16 workers.

L'API multipart de S3 exige un minimum de 5 Mo par part (sauf la dernière), un maximum de 5 Go par part, et jusqu'à 10 000 parts par upload. Ça met le plafond théorique autour de 48,8 To par objet. Google Cloud Storage permet 32 parts par composite et supporte des URI de session resumable qui persistent jusqu'à une semaine. Les block blobs Azure acceptent jusqu'à 50 000 blocs de 4000 MiB chacun.

Pour les transferts basés navigateur, les morceaux au-dessus de 100 Mo commencent à stresser la RAM des onglets déjà chargés, donc la plupart des UI web restent entre 5 et 20 Mo.

Comment les services de transfert modernes procèdent

L'uploader web de WeTransfer découpe les fichiers en morceaux de 6 Mo et lance 3 à 5 requêtes XHR en parallèle. Smash fragmente plus agressivement, avec des morceaux de 4 Mo répartis sur jusqu'à 8 workers. SwissTransfer utilise des morceaux de 50 Mo avec 4 flux parallèles, ce qui privilégie le débit sur les fibres suisses mais marche moins bien sur les connexions instables parce qu'un seul morceau échoué signifie retransmettre 50 Mo. Dropbox Transfer s'appuie sur son API d'upload chunked avec des morceaux de 8 Mo.

Les différences se voient en tests réels : un fichier de 5 Go sur un upload à 500 Mbps vers WeTransfer finit en environ 95 secondes ; SwissTransfer à débit similaire tourne autour de 105 secondes à cause de la surcharge occasionnelle de retry de morceaux.

Uploads resumables : le superpouvoir discret

Les uploads chunked débloquent la reprise. Si votre Wi-Fi tombe au morceau 47 sur 120, vous ne repartez pas à zéro, vous reprenez au morceau 48. Le protocole tus.io (un standard ouvert maintenant en version 2.0) formalise ça avec des requêtes HEAD pour interroger l'offset d'upload et des requêtes PATCH pour ajouter, en utilisant les en-têtes Upload-Offset et Upload-Length.

L'API resumable upload de Google Drive utilise des URI de session qui persistent 7 jours. Vous pouvez planter un portable, redémarrer, rouvrir l'onglet, et reprendre exactement où vous en étiez. C'est la différence entre un transfert utilisable de 10 Go et un coup de dés.

Le chiffrement côté client change la donne

Les services de transfert chiffrés de bout en bout doivent chiffrer chaque morceau côté client avant l'envoi. AES-256-GCM à 500 Mo/s sur un CPU de portable moderne n'est pas le goulot, mais l'ordre compte : chiffrer un morceau, uploader le morceau, chiffrer le suivant. Le pipelining avec un pool de workers compte ici. Les implémentations naïves sérialisent chiffrement et upload, divisant le débit effectif par deux. Les bonnes implémentations gardent 2 à 4 workers de chiffrement qui alimentent 4 à 8 workers d'upload via une file bornée.

C'est pourquoi HexaTransfer fait tourner le chiffrement AES-256-GCM dans des Web Workers en parallèle d'un pool XHR, donc le plafond de 10 Go est vraiment atteignable dans le navigateur sans bloquer sur la crypto.

Contre-pression et limites côté serveur

Plus de parallélisme n'est pas toujours plus rapide. Si le service récepteur applique un rate-limit par IP (courant avec CloudFront à 25 000 requêtes par seconde par distribution), pousser 32 morceaux concurrents peut déclencher des réponses 503 Slow Down. HTTP/2 aide parce qu'il multiplexe sur une seule connexion TCP, mais beaucoup de CDN terminent encore HTTP/2 à l'edge et déploient HTTP/1.1 vers l'origine, donc le parallélisme effectif dépend de la config de l'edge.

Testez avant de sur-paralléliser. 8 workers est presque toujours sûr ; 16 est la limite haute de ce que les object stores cloud acceptent proprement ; 32 commence à produire des retry qui coûtent plus qu'ils ne rapportent.

Limites du navigateur à connaître

Chrome et Firefox plafonnent les connexions concurrentes par origine à 6 sur HTTP/1.1 et effectivement illimitées sur HTTP/2. Si le service de transfert est encore en HTTP/1.1 (rare, mais certaines passerelles FTP-sur-HTTP héritées), votre plafond de parallélisme est de 6 quel que soit le nombre de workers que vous lancez. Vérifiez avec les DevTools : la colonne « Waterfall » du panneau Network montre les requêtes en queue qui s'empilent.

Safari sur iOS 17 et plus gère 6 XHR parallèles proprement mais commence à évincer les onglets en arrière-plan vers 1,5 Go de pression mémoire, ce qui compte pour les buffers d'upload chunked.

Quand les uploads parallèles n'aident pas

Sur les connexions résidentielles asymétriques (typique : 1 Gbps en descendant, 40 Mbps en montant), votre upload est le goulot, pas l'ingestion du serveur. Pousser 8 flux parallèles à 5 Mo chacun dans un tuyau de 40 Mbps ne va pas plus vite qu'un flux unique à 40 Mbps. Le parallélisme aide quand le plafond mono-flux est sous la capacité du tuyau, pas quand vous saturez déjà le lien.

Même histoire en cellulaire : si vous avez une barre de LTE, les workers en plus produisent surtout des retransmissions.

Ce qu'il faut chercher dans un service

Si vous choisissez un outil de transfert pour des gros fichiers fréquents, vérifiez trois choses : supporte-t-il les uploads chunked resumables, combien de workers parallèles l'UI web fait-elle tourner, et utilise-t-il HTTP/2 ou HTTP/3 jusqu'à l'edge. Les services qui cochent les trois cases déplaceront un fichier de 10 Go en quelques minutes sur une connexion correcte.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.