NAS : pourquoi votre débit plafonne (et quoi régler)

Vous avez un NAS. Vous avez du «  2,5 GbE  » ou même du 10 GbE. Sur le papier, ça devait envoyer.

Et puis en vrai… vous copiez un fichier, ça monte à 110 Mo/s (ou 280 Mo/s), ça stagne, parfois ça fait du yo-yo, et vous vous retrouvez à regarder la barre de progression comme si c’était elle le problème.

Non. Le problème est presque toujours un goulot d’étranglement. Et la partie frustrante, c’est que ça peut venir de n’importe où dans la chaîne.

Dans cet article, on va faire simple et concret : on liste les causes les plus courantes d’un débit NAS qui plafonne, comment les diagnostiquer, et quoi régler. C’est le genre de check-list que vous pouvez refaire à chaque nouveau lab, typiquement le style qu’on aime bien sur BTS SIO2 SISR Tech Lab.

---

1. Commencer par une vérité bête : le débit dépend du plus lent

Un transfert NAS, c’est une chaîne :

• disque du NAS (ou pool)
• CPU du NAS (chiffrement, checksums, compression, services)
• carte réseau du NAS
• câbles
• switch (ou routeur, ou Wi‑Fi, ou CPL… oui)
• carte réseau du PC
• disque du PC
• protocole et réglages (SMB/NFS/iSCSI, MTU, multicanal, etc.)

Si un seul maillon est «  limite  », tout plafonne.

Donc avant d’aller tweaker des jumbo frames à 2 h du matin, première étape : mesurer et localiser.

---

2. Les unités et les plafonds « normaux » (pour éviter de courir après un fantôme)

Petit rappel utile, parce que ça piège encore beaucoup.

• 1 Gb/s réseau = environ 125 Mo/s théorique
• en pratique sur SMB, vous voyez souvent 105 à 115 Mo/s
• 2,5 Gb/s = 312 Mo/s théorique, souvent 260 à 290 Mo/s réel
• 10 Gb/s = 1,25 Go/s théorique, souvent 800 Mo/s à 1,1 Go/s selon le reste

Donc si vous êtes en 1 GbE et vous voyez 112 Mo/s, ce n’est pas « nul ». C’est même plutôt propre.

Le but de l’article, c’est quand vous devriez faire mieux… et que ça ne veut pas.

---

3. Vérifier le lien réseau négocié (ça prend 30 secondes et ça évite des heures)

Ça paraît trop simple, mais c’est un grand classique : lien à 100 Mb/s au lieu de 1 Gb/s. Ou 1 Gb/s au lieu de 2,5 Gb/s. Ou un port switch « éco » bridé.

Côté Windows

• Gestionnaire de périphériques → carte réseau → État → Vitesse
• Ou PowerShell :
  powershell Get-NetAdapter | Select Name, Status, LinkSpeed

Côté Linux

bash ethtool eth0 | grep -E "Speed|Duplex"

Côté NAS

Sur Synology, QNAP, TrueNAS, OMV, vous avez tous un écran « interface réseau » qui affiche la vitesse négociée.

Si vous constatez une connexion lente comme celle-ci, ne cherchez pas plus loin : câble, prise, panneau de brassage, port switch, autoneg foireux.

Il est également possible que votre système affiche une vitesse de lien incorrecte. Par exemple, il se peut que votre réglage réseau filaire indique une vitesse de 10 Mb/s, ce qui serait anormal pour une connexion moderne.

4. Tester le réseau sans les disques : iperf3 d’abord, fichiers ensuite

Le transfert de fichiers mélange réseau + stockage + protocole. Donc on sépare.

Installer iperf3

• sur un PC : Windows (binaire), Linux (apt/dnf), macOS (brew)
• sur NAS : parfois dispo via paquet, docker, ou shell

Lancer le serveur sur le NAS

bash iperf3 -s

Lancer le client sur le PC

bash iperf3 -c IP_DU_NAS -P 4

• -P 4 lance 4 flux parallèles, utile pour saturer correctement certains stacks.

Interprétation rapide :

• si iperf3 est bas, c’est réseau (câble, switch, MTU, pilotes, offload, etc.)
• si iperf3 est bon mais la copie SMB est basse, c’est stockage ou protocole

C’est vraiment LE test à faire en premier.

---

5. SMB, NFS, iSCSI : le protocole peut être le goulot (ou le sauveur)

SMB (Windows, le plus courant)

SMB est pratique, mais sensible à pas mal de choses : latence, antivirus, chiffrement, signing, multicanal.

À regarder :

• SMB3 activé (normalement oui)
• SMB signing obligatoire ? (dans un domaine, ça arrive)
• chiffrement SMB activé ? (utile mais coûteux)

Sur un NAS, si vous activez le chiffrement SMB «  par partage  », vous pouvez perdre beaucoup de débit, surtout sur un CPU modeste. Et parfois ça se voit : CPU à 100 % pendant la copie.

NFS (souvent meilleur en débit brut sur Linux)

Si vous copiez entre Linux et NAS, NFS peut donner un meilleur débit et une latence plus stable. Mais il faut des permissions propres, et bien choisir les options de montage.

iSCSI (pour un usage bloc)

Si votre objectif est d’héberger une VM, un datastore, ou un volume «  comme un disque local  », iSCSI peut être plus adapté que SMB. Mais ça demande un peu de rigueur.

---

6. Le piège numéro un : les petits fichiers

Vous copiez 200 Go de films en gros fichiers, ça va vite.

Vous copiez 200 Go de projets, node_modules, photos, mails exportés… et là tout s’écroule.

Pourquoi ? Parce que les petits fichiers, c’est :

• beaucoup d’opérations metadata
• beaucoup d’allers-retours
• beaucoup d’IOPS
• et souvent une avalanche de scans antivirus côté client

Donc ce n’est pas «  le débit  » qui est lent, c’est le nombre d’opérations par seconde qui sature.

Ce que vous pouvez faire :

• compresser en une archive (zip, tar) avant transfert
• utiliser robocopy avec des options adaptées
• désactiver temporairement le scan temps réel sur le dossier de destination (en test, pas en prod aveugle)
• passer par rsync (si possible)

---

7. Le stockage NAS : HDD, RAID, cache SSD… et attentes réalistes

On y vient. Le NAS peut avoir un réseau rapide, mais des disques lents.

HDD seuls

Un HDD fait souvent 150 à 220 Mo/s en séquentiel. En RAID, on peut augmenter le débit en lecture, parfois en écriture selon le niveau RAID et le contrôleur, mais…

• RAID5/SHR : pénalité en écriture
• RAID6 : encore plus
• petits fichiers : IOPS faibles, c’est là que ça se casse la figure

SSD cache

Un cache SSD peut aider, mais pas magiquement.

• cache en lecture : bien pour accès répétitifs
• cache en écriture : attention aux risques, et aux modèles qui l’implémentent proprement

Pool full SSD

Là oui, on peut vraiment saturer du 2,5 GbE et commencer à bien manger du 10 GbE. Mais il faut aussi que le CPU et le protocole suivent.

---

8. Le CPU du NAS : quand il plafonne, votre débit plafonne aussi

Cas typique : NAS entrée de gamme, CPU peu puissant, et vous activez :

• chiffrement de volume
• chiffrement SMB
• compression
• déduplication (sur certains systèmes)
• antivirus sur le NAS
• indexation médias
• snapshots agressifs
• checksums partout

Résultat : lors d’une grosse copie, vous voyez CPU à 90 ou 100 %, et le débit fait une moyenne médiocre.

Ce que vous faites :

• regarder les graphes CPU/RAM (interface NAS)
• pendant un test, désactiver temporairement les services lourds
• vérifier si le chiffrement est réellement nécessaire sur ce partage
• planifier indexations et tâches de maintenance hors heures de copie

Oui c’est un peu «  admin  ». Mais c’est le vrai monde.

---

9. MTU et jumbo frames : utile, mais seulement si tout est aligné

Les jumbo frames (MTU 9000) peuvent réduire l’overhead CPU et améliorer un peu le débit, surtout en 10 GbE. Mais c’est un sujet à pièges.

Règle simple :

• si un seul équipement au milieu reste à 1500, vous risquez fragmentation, pertes, ou comportements bizarres
• ça inclut switch, routeur, carte réseau, VM, vSwitch, etc.

Donc si vous testez :

1. vous alignez MTU sur NAS + PC + switch
2. vous validez avec un ping avec taille adaptée

Exemple (Linux) : bash ping -M do -s 8972 IP_DU_NAS

Sur Windows, c’est un peu différent (-f -l), mais l’idée est la même.

Si vous n’êtes pas sûr, restez en 1500. Beaucoup de labs très rapides tournent en MTU 1500 sans drame.

---

10. Pilotes, offload, et fonctions « intelligentes » qui cassent tout

Certains adaptateurs 2,5 GbE et certains drivers ont eu des périodes… compliquées. Idem pour des fonctions d'offload.

À vérifier côté PC :

• Mettre le driver NIC à jour.
• En cas de symptômes (coupures, débit instable), désactiver en test les options avancées suivantes : Large Send Offload (LSO), Interrupt Moderation, Energy Efficient Ethernet (EEE), Flow Control.

Attention, je ne dis pas « désactivez tout tout le temps ». Je dis : si vous avez un débit instable ou inférieur à ce que votre lien permet, ça se teste.

Côté switch, si EEE est activé et mal supporté, vous pouvez voir des micro latences. Ça suffit parfois à ruiner SMB sur certains workloads.

---

11. Antivirus et inspection : le frein invisible côté client

Sur Windows, la copie SMB peut être fortement impactée par les éléments suivants :

• Antivirus (Defender inclus)
• DLP
• Agent EDR
• Inspection SSL/TLS ou analyse de fichiers réseau

Symptôme : CPU PC qui monte, activité disque PC élevée, et débit qui s'effondre surtout sur petits fichiers.

Pour isoler le problème, effectuez deux tests de copie : un sur un gros fichier unique (10 Go), puis un sur un dossier contenant 50 000 fichiers. Si le gros fichier va vite mais pas le dossier, ce n'est pas « le réseau » en premier.

---

12. Multicanal SMB : la bonne surprise si vous avez plusieurs liens

SMB Multichannel permet d'utiliser plusieurs interfaces réseau en parallèle. Pour en bénéficier, trois conditions doivent être réunies : le client et le serveur doivent le supporter, vous devez disposer de plusieurs NIC ou d'une NIC avec plusieurs queues efficaces, et la fonctionnalité doit être correctement configurée.

Sur certains NAS et Windows, ça peut faire une différence énorme, surtout si vous avez deux liens 1 GbE ou deux liens 2,5 GbE.

À vérifier côté Windows (selon version) : Get-SmbMultichannelConnection (PowerShell)

Si vous êtes en lab et que vous aimez expérimenter, c'est un sujet cool à documenter, typiquement le genre de mini-projet E4/E5 à mettre au propre.

---

13. Une méthode de diagnostic rapide (celle qui évite de partir dans tous les sens)

Je vous donne une routine en 7 étapes. Vous la suivez dans l’ordre, sinon vous allez vous éparpiller.

1. Vérifier la vitesse négociée (100 Mb ? 1 Gb ? 2,5 Gb ? 10 Gb ?)
2. Lancer iperf3 et noter le débit
3. Copier un gros fichier unique (10 à 50 Go) et noter le débit
4. Copier un dossier avec beaucoup de petits fichiers, comparer
5. Regarder CPU/RAM du NAS pendant les copies
6. Vérifier l’état des disques, IOPS, et si le pool est saturé
7. Seulement après, tester MTU 9000 et réglages avancés

Vous pouvez même faire une petite fiche de résultats, et la garder dans vos notes. Si vous suivez BTS SIO2 SISR Tech Lab, c’est le genre de contenu qu’on pousse souvent : des procédures reproductibles, pas juste «  essaie ça  ».

---

14. Réglages concrets à faire selon le symptôme

Symptôme : plafonné à ~110 Mo/s alors que vous pensiez faire plus

• vous êtes probablement en 1 GbE, et c’est normal
• si vous avez du 2,5 GbE, vérifier lien négocié et switch compatible

Symptôme : iperf3 faible

• câble Cat5e douteux, prise murale, patch, port switch
• driver NIC
• options EEE/offload à tester
• Wi‑Fi ou CPL dans le chemin (oui, ça arrive…)

Symptôme : iperf3 bon mais SMB lent

• chiffrement SMB ou signing
• antivirus côté client
• CPU NAS à 100 %
• petits fichiers et metadata

Symptôme : débit en dents de scie

• cache qui se remplit puis flush sur HDD
• pool RAID en écriture pénalisée
• snapshots ou tâches NAS en arrière-plan
• problème driver NIC ou EEE

---

15. Ce que je ferais, moi, si je débarque sur votre réseau et que « ça plafonne »

Je commence par iperf3. Toujours.

Ensuite, je fais une copie d’un fichier unique de 20 Go. Puis un dossier de 20 000 petits fichiers.

Je regarde le CPU NAS, et l’activité disque. Si le NAS respire, je suspecte le poste client. Si le NAS étouffe, je simplifie les services.

Et seulement à la fin, je touche aux jumbo frames. Parce que c’est utile, oui. Mais c’est rarement le premier blocage.

---

Conclusion : vous n’avez pas un problème de NAS, vous avez un problème de goulot

Un débit NAS qui plafonne, c’est rarement mystérieux. C’est juste… réparti. Réseau, disques, CPU, protocole, fichiers, sécurité.

Si vous voulez, prenez cet article comme une check-list de dépannage, et faites-en une version «  fiche de TP  » pour vos labs. Sur BTS SIO2 SISR Tech Lab, on publie exactement ce genre de contenu orienté terrain, et si vous avez un cas concret (modèle NAS, switch, OS client, protocole), ça vaut le coup de le documenter, captures à l’appui, pour que ça serve aux autres aussi.

Et oui, parfois la réponse est frustrante : «  c’est normal en 1 GbE  ». Mais au moins, vous le savez. Et vous arrêtez de vous battre contre la barre de progression.

Questions fréquemment posées

Pourquoi mon transfert de fichiers NAS plafonne-t-il malgré une connexion 2,5 GbE ou 10 GbE ?

Le débit d'un transfert NAS dépend du maillon le plus lent dans la chaîne, qui peut être le disque du NAS, le CPU, la carte réseau, les câbles, le switch, la carte réseau du PC, ou même les réglages du protocole. Un goulot d'étranglement à n'importe quel point peut limiter la vitesse.

Comment vérifier si ma connexion réseau négocie la bonne vitesse ?

Sur Windows, vous pouvez vérifier la vitesse via le Gestionnaire de périphériques ou PowerShell avec 'Get-NetAdapter'. Sur Linux, utilisez 'ethtool eth0' pour voir la vitesse et le duplex. Sur votre NAS (Synology, QNAP...), l'interface réseau affiche aussi la vitesse négociée. Une vitesse inférieure à celle attendue indique souvent un problème de câble, port ou configuration.

Quels sont les débits théoriques et réels attendus pour différentes vitesses Ethernet ?

Pour 1 Gb/s réseau, le débit théorique est environ 125 Mo/s avec un réel souvent entre 105 et 115 Mo/s en SMB. Pour 2,5 Gb/s c'est environ 312 Mo/s théorique et 260-290 Mo/s réel. Pour 10 Gb/s on attend 1,25 Go/s théorique et souvent entre 800 Mo/s et 1,1 Go/s en pratique.

Comment diagnostiquer si le problème vient du réseau ou du stockage lors d’un transfert NAS ?

Utilisez iperf3 pour tester uniquement le réseau : lancez iperf3 en serveur sur le NAS et en client sur le PC. Si iperf3 montre un débit bas, c’est un problème réseau (câble, switch, MTU...). Si iperf3 est bon mais que la copie SMB est lente, alors c’est probablement un problème de stockage ou de protocole.

Pourquoi est-il important de mesurer avant de modifier les réglages comme les jumbo frames ?

Parce que sans mesure précise et localisation du goulot d’étranglement, on risque de passer des heures à tweaker des paramètres qui n’amélioreront pas forcément les performances. Mesurer permet d’identifier clairement où se situe la limite dans la chaîne.

Quels sont les éléments à vérifier dans la chaîne de transfert pour optimiser les débits NAS ?

Il faut vérifier successivement : le disque ou pool du NAS (vitesse et santé), le CPU du NAS (charge liée au chiffrement ou compression), la carte réseau du NAS et ses câbles, le switch ou routeur utilisé (vitesse des ports), la carte réseau du PC ainsi que ses disques et enfin les protocoles utilisés (SMB/NFS/iSCSI) et leurs réglages comme MTU ou multicanal.