Essayer de connaître les frais généraux TCP exacts

9

Correspondant à ce sujet:

/programming/3613989/what-of-traffic-is-network-overhead-on-top-of-http-s-requests

La taille de segment maximale (qui n'inclut pas les en-têtes TCP ou IP) est généralement négociée entre les couches à la taille de la MTU moins la taille des en-têtes. Pour Ethernet MTU est généralement configuré à 1500 octets. L'en-tête TCP est de 160 bits ou 20 octets. La partie fixe de l'en-tête IPv4 est de 160 bits, ou 20 octets également. ... Donc:

pour HTTP sur TCP / IPv4

surcharge = TCP + IP = 40 octets

charge utile = 1500 - 40 = 1460 octets

frais généraux% = 2% (40 * 100/1460)

Voici les résultats iperf de 100 Mbit et 1 Gbit en mode TCP avec les distributions Debian par défaut:

[  5] local 10.0.51.1 port 5001 connected with 10.0.51.20 port 45009
[  5]  0.0-10.0 sec   112 MBytes  94.1 Mbits/sec
[  4] local 10.0.51.1 port 5001 connected with 10.0.51.94 port 35065
[  4]  0.0-10.0 sec  1.10 GBytes   941 Mbits/sec

Je peux le réduire à près de 2% de frais généraux en augmentant le MTU à 9000:

[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.14 GBytes   982 Mbits/sec

Mais cela ne devrait-il pas être encore moins?

overhead = TCP + IP = 40 bytes
payload = 9000 - 40 = 8960 bytes
overhead % = 0.4% (40 * 100 / 8960)

Pourquoi la «perte de bande passante» réelle est notablement plus importante que la théorie? Si la formule manque quelque chose de précieux?

tcp bandwidth

— agrrh
source

16

Paquets Ethernet 1.5k

1500 - 20 B (IPv4) - 20 B (TCP + checksum) = 1460 B DATA (et 40 B Overhead)

Ajouter 40 B + 14 B (Ethernet) + 4 B (FCS) + 12 B (espace intertrame) + 8 B (préambule) = 78 B

78/1460 * 100 = 5,34% de frais généraux

1460 / (1460 + 78) * 100 = 94,93% débit / bon débit

10000000000 (1 Gbit) * 94,93% = 949 Mbit / s (0,949 Gbit / s)

vous avez mesuré 941 Mbit / s, ce qui donne (949 - 941) / 949 * 100 = 0,84% d'erreur entre théorique et réel.

Paquets Jumbo 9k - Théorique max

(9000-40) / ( 9000 - 40 + 78 ) *100 = 99.14%  (Overhead 0.86%)

10000000000 (1 Gbit) * 99,14% = 991 Mbit / s (0,99 Gbit / s)

— Pieter
source

1

Il y a probablement aussi l'influence de la fonction de démarrage lent, mais je ne sais pas si elle est assez grande. Je vous remercie. :)

— agrrh

Ah, Ethernet a un FCS de 4 octets à la fin de la trame, permettez-moi d'ajouter cela au calcul.

— Pieter

4

Les frais généraux sont généralement calculés en fonction de la taille totale des données. De cette façon, le chiffre correspond à la valeur d'efficacité.

Pour TCP sur IPv4 sur Ethernet, vous disposez (sans options d'en-tête):

Frais généraux L1 - préambule, IPG: 8 + 12 = 20
Surcharge L2 - en-tête Ethernet, FCS = 18
Surcharge L3 - en-tête IPv4 = 20
Surcharge L4 - en-tête TCP = 20

La taille de paquet maximale L3 de 1500 se traduit par une taille de données L1 totale de 1500 + 18 + 20 = 1538 octets et une taille de charge utile L4 maximale de 1500-20-20 = 1460 octets .

Frais généraux: 78/1538 * 100% = 5,07%
Efficacité: 1460/1538 * 100% = 94,93%

Avec des trames jumbo 9k (non 802.3), vous obtiendrez

Frais généraux: 78/9038 * 100% = 0,86%
Efficacité: 8960/9038 * 100% = 99,14%

Ce sont des valeurs théoriques dans le meilleur des cas . Dans la vraie vie, vous auriez également du matériel et des frais généraux du système d'exploitation qui réduiraient légèrement la valeur d'efficacité. Des fonctionnalités telles que le déchargement et la direction d'interruption multicœur peuvent réduire les frais généraux de traitement et vous rapprocher des chiffres théoriques (plus pertinents avec des cartes réseau plus rapides). Ceux que vous avez mesurés semblent assez réalistes, comme l'a déjà souligné Pieter.

— Zac67
source