Astuces d'optimisation de bande passante pour les transferts

Pour tirer le maximum de votre bande passante en upload, quatre actions font la différence : passer en filaire sur Ethernet Gigabit plutôt qu'en Wi-Fi, activer le QoS ou le SQM sur votre routeur pour éliminer le bufferbloat, basculer en IPv6 si votre FAI le supporte, et mettre en pause les synchronisations en arrière-plan (Dropbox, iCloud, Google Drive) pendant le transfert. Sur une connexion à 500 Mbps en upload qui ne délivre réellement que 180 Mbps, ces quatre changements récupèrent typiquement 200 à 280 Mbps de débit utilisable et réduisent un transfert de 10 Go de 45 minutes à moins de 15.

Passez en filaire et oubliez le Wi-Fi pour les gros fichiers

Le Wi-Fi 6 (802.11ax) avec un bon client 2x2 à 1,5 mètre du point d'accès plafonne à environ 600 Mbps en conditions réelles. Le Wi-Fi 5 (802.11ac) se situe plutôt autour de 300 Mbps. Dans la pièce d'à côté avec un mur entre les deux, ces chiffres chutent de 40 à 60 %. L'Ethernet Gigabit délivre 940 Mbps de façon constante avec moins de 1 ms de gigue.

Un adaptateur USB-C vers Ethernet Gigabit à une quinzaine d'euros surpassera le Wi-Fi intégré de la plupart des portables pour les uploads au-delà de 2 Go. Si le câble n'est pas envisageable, restez au moins sur la bande 5 GHz en vue directe du routeur. La bande 2,4 GHz plafonne à 60-80 Mbps en conditions réelles et n'a aucune raison d'être utilisée pour un transfert de fichiers.

QoS et SQM : remède contre le bufferbloat

Le bufferbloat est la raison pour laquelle votre appel Zoom rame dès que quelqu'un démarre un upload dans la maison. Les buffers de routeur traditionnels mettent les paquets en file d'attente pendant des secondes sur les liens saturés, dégradant la latence. Les algorithmes de Smart Queue Management (SQM) comme CAKE et fq_codel maintiennent des files courtes même sous charge, de sorte qu'un upload à 500 Mbps n'ajoute pas 300 ms de latence à tout le reste.

OpenWrt, pfSense et la plupart des routeurs modernes (Asus avec firmware Merlin, Ubiquiti UniFi, eero Pro 6E) supportent le SQM. Activez-le, réglez le lien montant à environ 95 % de votre débit provisionné, et regardez votre test de bufferbloat sur DSLReports ou Waveform passer de F à A+.

Cela n'ajoute pas de bande passante, mais supprime la perte de débit de 40 à 60 % que provoque le bufferbloat en forçant votre émetteur TCP à reculer en boucle.

L'IPv6 est généralement plus rapide

Sur les FAI qui supportent la double pile, l'IPv6 emprunte souvent des chemins plus directs vers les grandes destinations cloud. AWS, Google Cloud, Cloudflare et Azure fonctionnent tous en IPv6 natif, et un paquet en IPv6 contourne typiquement un ou deux sauts NAT par rapport aux chemins IPv4 CGNAT courants sur le mobile et certains réseaux résidentiels.

Vérifiez sur ipv6-test.com ou test-ipv6.com. Si vous obtenez 10/10, vous utilisez déjà IPv6 là où c'est disponible. Sinon, activez-le dans votre routeur (la plupart des FAI poussent les configurations via DHCPv6 ou PPPoE automatiquement). La différence sur un upload transcontinental peut atteindre 20 à 40 %.

Coupez tout ce qui synchronise en arrière-plan

Dropbox, Google Drive, OneDrive, iCloud Photos, Time Machine via réseau et les outils de sauvegarde comme Backblaze consomment tous de la bande passante en upload en silence. Le Moniteur d'activité de macOS (onglet Réseau, tri par « Octets envoyés ») et le Moniteur de ressources Windows révèlent les coupables.

Mettez-les en pause avant un gros transfert. iCloud Photos en particulier peut pousser des gigaoctets en silence après l'importation d'une session photo. Le throttle par défaut de Backblaze est « automatique », ce qui signifie « prendre tout ce qui est disponible » sur une connexion peu chargée.

Un appel Zoom en 1080p utilise environ 3 Mbps en montant. Un appel Google Meet HD se situe près de 2,5 Mbps. Si quelqu'un dans la maison est en visioconférence, planifiez le transfert autour ou acceptez une réduction de 2 à 3 Mbps.

DNS et le temps de premier octet

Un DNS mal configuré peut ajouter 50 à 200 ms de latence avant même qu'une connexion TCP ne démarre. Si vous utilisez encore le résolveur par défaut de votre FAI, essayez le 1.1.1.1 de Cloudflare ou le 8.8.8.8 de Google. Utilisez dig +stats service-de-transfert.com pour comparer les temps de réponse. Pour les uploads en morceaux qui ouvrent de nombreuses connexions, un résolveur rapide se traduit par un débit global nettement amélioré.

Sur macOS, changez le DNS dans Réglages Système > Réseau > Détails > DNS. Sur Windows 11, Paramètres > Réseau et Internet > (votre adaptateur) > Modifier le serveur DNS.

Réglage du MTU sur les réseaux non standard

Si vous êtes sur un VPN, une connexion DSL PPPoE ou un lien cellulaire, votre MTU est peut-être inférieur aux 1 500 octets par défaut. Un MTU mal dimensionné provoque de la fragmentation TCP, des retransmissions et un effondrement du débit. Testez avec ping -s 1472 -D google.com sur macOS/Linux ou ping -f -l 1472 google.com sur Windows. Si les paquets ne reviennent pas, réduisez le MTU par incréments de 10 octets jusqu'à ce qu'ils reviennent, puis définissez cette valeur (plus 28 pour l'overhead ICMP) comme MTU de votre interface.

Valeurs courantes : 1 500 pour la majorité du haut débit, 1 492 sur DSL PPPoE, 1 428 sur certains VPN Wireguard, 1 400 sur la plupart des opérateurs 5G.

Contrôle de congestion : BBR versus Cubic

Sur les systèmes Linux qui uploadent vers le cloud, passer le contrôle de congestion TCP de Cubic à BBR (Bottleneck Bandwidth and RTT) peut doubler le débit sur des liens à haute latence avec un peu de perte. Activez avec sysctl -w net.ipv4.tcp_congestion_control=bbr. macOS et Windows utilisent des variantes de Cubic par défaut et n'exposent pas facilement ce paramètre, mais les endpoints de transfert hébergés sur cloud font de plus en plus tourner BBR de leur côté, ce qui aide même si votre côté ne le fait pas.

C'est une raison pour laquelle des services tournant sur Google Cloud (Smash, une partie du trafic SwissTransfer) semblent souvent plus rapides que des services identiques sur des hébergeurs legacy.

Le choix du navigateur compte

Les navigateurs basés sur Chromium (Chrome, Edge, Brave, Arc) supportent HTTP/3 et QUIC par défaut, surpassant HTTP/2 sur HTTPS sur les liens à perte de 15 à 25 %. Firefox embarque aussi QUIC. Safari 17+ supporte HTTP/3 mais bascule sur HTTP/2 pour certains services. Vérifiez via l'onglet Réseau des DevTools, colonne « Protocole ».

Si l'endpoint d'upload d'un service répond en HTTP/3, cela signifie moins de round-trips de handshake par fragment, ce qui compte pour les uploads parallèles qui ouvrent 4 à 8 flux simultanés.

Choisissez un service qui respecte votre débit

Certains services de transfert brident les uploads quel que soit le débit disponible. Une ligne à 500 Mbps peut ramper sur un outil qui limite le débit par transfert à 30 Mbps. HexaTransfer transfère les fragments en parallèle via HTTP/2 avec chiffrement AES-256-GCM dans des Web Workers, de sorte que votre upload sature tout ce que votre connexion peut réellement délivrer jusqu'au plafond de 10 Go par transfert.

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