Quelle quantité de débit utilisable la surcharge du protocole retire-t-elle d'une connexion NAS domestique ?

La surcharge du protocole retire généralement quelques pourcents d'un lien NAS câblé bien rempli avant de considérer SMB et le comportement applicatif. Avec une MTU standard de 1500 octets, TCP sur IPv4 peut transporter 1460 octets de charge utile applicative dans chaque paquet IP, tandis que le cadrage Ethernet, le préambule et l'intervalle inter-trames consomment du temps supplémentaire sur le câble.

Ce calcul n'est qu'un plafond théorique d'efficacité pour de gros transferts propres. Les petits fichiers, paquets partiels, accusés de réception, messages SMB, chiffrement, latence, retransmissions, attentes de stockage et comportement client peuvent réduire considérablement le débit utile réel.

Quelle est la différence entre le débit de ligne et le débit utile ?

Le débit de ligne décrit la rapidité avec laquelle l'interface signale les bits, tandis que le débit utile ne compte que les données applicatives livrées. Les en-têtes, accusés de réception, retransmissions et messages de contrôle sont un trafic réel mais ne sont pas des octets ajoutés au fichier utilisateur finalisé.

Un port 1GbE ne peut donc pas fournir indéfiniment 125 Mo/s de charge utile de fichier. Ce chiffre convertit un milliard de bits signalés par seconde en octets avant de soustraire toute surcharge de trame ou de protocole.

Le débit utile doit être mesuré au niveau de l'application après la fin du transfert. Les compteurs d'interface mesurent un trafic plus large et peuvent inclure des retransmissions ou des données que l'application n'a pas encore validées.

Combien les en-têtes Ethernet, IP et TCP retirent-ils ?

Pour le TCP standard sur IPv4 sans options, les en-têtes TCP et IP réduisent l'efficacité de la charge utile. Le coût de 40 octets TCP/IP représente environ 2,7 % de la MTU IP avant d'inclure la surcharge du câble Ethernet.

Au niveau du câble Ethernet, une trame pleine taille utilise également un en-tête de 14 octets, un FCS de 4 octets, un préambule et un délimiteur de début de 8 octets, ainsi qu'un intervalle inter-trames de 12 octets. Une charge utile TCP de 1460 octets peut donc occuper environ 1538 octets-temps sur un chemin Ethernet simple non tagué.

Ce ratio correspond à environ 94,9 % d'efficacité de la charge utile. Le plafond approximatif est donc d'environ 949 Mbps sur 1GbE, 2,37 Gbps sur 2,5GbE, et 9,49 Gbps sur 10GbE avant SMB, stockage, accusés de réception et limites d'implémentation.

Pourquoi la taille de la charge utile modifie-t-elle le pourcentage perdu ?

La plupart des en-têtes ont une taille fixe par paquet, donc les charges utiles plus grandes amortissent le surcoût fixe des trames. Un paquet complet de 1500 octets est bien plus efficace qu'un paquet ne transportant que quelques centaines d'octets.

Les petites requêtes synchrones peuvent donc passer une plus grande part de leur temps sur le câble à gérer le cadrage, les requêtes, les réponses et les accusés de réception. Le nombre de fichiers et les allers-retours applicatifs comptent même lorsque le total des octets de charge utile est modeste.

Les trames jumbo améliorent encore le ratio, mais le gain mathématique maximal est inférieur à celui de nombreux goulets d'étranglement de stockage. Elles nécessitent également un support MTU cohérent sur chaque appareil et couche virtuelle du chemin.

Quel travail supplémentaire SMB ajoute-t-il par rapport à TCP ?

SMB ajoute des en-têtes de message, la sémantique des requêtes et réponses, des crédits, l'état d'authentification, la signature ou le chiffrement, et des allers-retours d'opérations sur fichiers. les petits fichiers répètent la configuration de l'application et du protocole.

Pour une lecture ou écriture en pipeline importante, le surcoût SMB peut être amorti sur des charges utiles substantielles et plusieurs requêtes en cours. Pour les petits fichiers et les opérations de métadonnées, les messages d'ouverture, de requête, de permission, de fermeture et de répertoire représentent une part plus importante du temps écoulé.

La signature et le chiffrement consomment également du CPU et de la bande passante mémoire sans nécessairement ajouter un grand nombre d'octets sur le câble. Le surcoût du protocole inclut donc le coût de traitement, pas seulement la taille de l'en-tête.

Pourquoi les transferts réels peuvent-ils perdre plus que ce que prédit l'arithmétique des en-têtes ?

L'arithmétique des en-têtes suppose des charges utiles complètes, aucune perte, des fenêtres adéquates et des points de terminaison qui traitent les paquets assez rapidement. la latence et la perte engendrent des coûts au-delà des octets d'en-tête.

La perte de paquets entraîne des retransmissions et des réductions du contrôle de congestion. La latence limite la rapidité avec laquelle l'expéditeur reçoit les retours. De petites fenêtres TCP, des files d'attente sous-remplies, des pauses de stockage ou un cœur CPU occupé peuvent laisser le câble inactif même si l'efficacité théorique du cadrage est élevée.

Un gestionnaire de fichiers peut également effectuer des copies en flux unique avec tampon, tandis qu'un benchmark utilise plusieurs travailleurs ou tampons mémoire. La différence entre ces outils réside dans le comportement de l'application, pas seulement dans les en-têtes de protocole.

Comment un NAS domestique doit-il estimer le débit pratique ?

les trames jumbo réduisent la surcharge uniquement sur un chemin validé. Commencez par le plafond d'efficacité du fil MTU standard, puis soustrayez les limites mesurées des points de terminaison et de la charge de travail plutôt que d'appliquer un pourcentage universel.

Utilisez un test réseau uniquement pour établir le débit utile TCP, puis effectuez une copie NAS de gros fichiers, une charge de travail de petits fichiers et l'application réelle. Enregistrez le débit de ligne, les octets de l'application, le CPU, la latence du stockage, les retransmissions, la taille des paquets et si la signature ou le chiffrement est activé.

Une marge de planification telle que 10 à 15 % en dessous du débit du lien peut être raisonnable pour planifier de gros transferts, mais ce n'est pas une constante du protocole. Un LAN bien réglé peut approcher le plafond d'efficacité du fil, tandis que les petits fichiers ou les points de terminaison contraints peuvent perdre beaucoup plus.

FAQ

Quel est le plafond théorique de la charge utile TCP sur 1GbE ?

Avec des paquets TCP/IPv4 complets de 1500 octets et une comptabilité simple du fil Ethernet, c'est environ 949 Mbps avant les limites SMB et des points de terminaison.

Le SMB coûte-t-il toujours 10 ou 15 pour cent ?

Non. Leur impact dépend de la taille des requêtes, du nombre de fichiers, de la signature, du chiffrement, de la concurrence, du CPU, du stockage et de l'implémentation client.

Les trames jumbo vont-elles récupérer toute la surcharge du protocole ?

Non. Ils réduisent la fréquence de cadrage et de traitement par paquet mais ne suppriment pas les opérations SMB, les accusés de réception, les attentes de stockage ou le comportement des applications.

Pourquoi une copie NAS 10GbE peut-elle rester en dessous de 9,49 Gbps ?

Le tableau de stockage, le disque client, le CPU, le chemin PCIe, les paramètres SMB, la profondeur de file d'attente, la perte de paquets et l'outil de copie peuvent devenir des limites avant l'efficacité du fil.

Conclusion finale

La surcharge du protocole transforme le débit de ligne en un débit utile inférieur à travers le travail fixe d'Ethernet, IP, TCP et SMB. Les trames standard complètes peuvent conserver environ 95 % du débit filaire en tant que charge utile TCP, mais les transferts NAS réels paient également pour les opérations de fichiers, la sécurité, les retours, les pertes, la latence et les blocages aux points de terminaison. Calculez d'abord le plafond des en-têtes, puis mesurez l'écart spécifique à la charge de travail.