Der Versuch, die genauen TCP-Gemeinkosten herauszufinden

9

Entsprechend diesem Thema:

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

Die maximale Segmentgröße (ohne TCP- oder IP-Header) wird normalerweise zwischen den Layern auf die Größe der MTU abzüglich der Headergröße ausgehandelt. Für Ethernet ist MTU normalerweise auf 1500 Bytes konfiguriert. Der TCP-Header ist 160 Bit oder 20 Byte. Der feste Teil des IPv4-Headers besteht aus 160 Bit oder 20 Byte. .... Somit:

für HTTP über TCP / IPv4

Overhead = TCP + IP = 40 Bytes

Nutzlast = 1500 - 40 = 1460 Bytes

Overhead% = 2% (40 * 100/1460)

Hier sind 100 Mbit und 1 Gbit iperf Ergebnisse im TCP-Modus mit Standard-Debian-Distributionen:

[  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

Ich kann den Overhead auf fast 2% senken, indem ich die MTU auf 9000 erhöhe:

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

Aber sollte es nicht noch weniger sein?

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

Warum ist der tatsächliche "Bandbreitenverlust" deutlich größer als der theoretische? Fehlt der Formel etwas Wertvolles?

tcp bandwidth

— agrrh
quelle

15

Ethernet-Pakete 1.5k

1500 - 20 B (IPv4) - 20 B (TCP + Prüfsumme) = 1460 B DATEN (und 40 B Overhead)

Addiere 40 B + 14 B (Ethernet) + 4 B (FCS) + 12 B (Interframe-Lücke) + 8 B (Präambel) = 78 B Overhead

78/1460 * 100 = 5,34% Overhead

1460 / (1460 + 78) * 100 = 94,93% Durchsatz / Goodput

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

Sie haben 941 Mbit / s gemessen, was (949 - 941) / 949 * 100 = 0,84% Fehler zwischen theoretisch und tatsächlich ergibt .

Jumbo-Pakete 9k - Theoretische max

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

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

— Pieter
quelle

1

Wahrscheinlich gibt es auch Einfluss der Funktion für langsamen Start, aber ich bin mir nicht sicher, ob sie groß genug ist. Vielen Dank. :)

— Agrrh

Ah, Ethernet hat am Ende des Frames ein 4-Byte-FCS. Lassen Sie mich das zur Berechnung hinzufügen.

— Pieter

4

Der Overhead wird normalerweise basierend auf der Gesamtdatengröße berechnet. Auf diese Weise entspricht die Zahl dem Wirkungsgrad.

Für TCP über IPv4 über Ethernet haben Sie (ohne Header-Optionen):

L1 Overhead - Präambel, IPG: 8 + 12 = 20
L2-Overhead - Ethernet-Header, FCS = 18
L3-Overhead - IPv4-Header = 20
L4-Overhead - TCP-Header = 20

Die maximale L3- Paketgröße von 1500 ergibt eine Gesamt-L1-Datengröße von 1500 + 18 + 20 = 1538 Byte und eine maximale L4-Nutzlastgröße von 1500-20-20 = 1460 Byte .

Gemeinkosten: 78/1538 * 100% = 5,07%
Effizienz: 1460/1538 * 100% = 94,93%

Mit 9k Jumbo-Frames (nicht 802.3) erhalten Sie

Gemeinkosten: 78/9038 * 100% = 0,86%
Effizienz: 8960/9038 * 100% = 99,14%

Dies sind theoretische Best-Case- Werte. Im wirklichen Leben würden Sie auch Hardware- und Betriebssystem-Overhead haben, der den Effizienzwert leicht beeinträchtigt. Funktionen wie Offloading und Multi-Core-Interrupt-Steuerung können den Verarbeitungsaufwand reduzieren und Sie näher an die theoretischen Zahlen bringen (relevanter bei NICs mit höherer Geschwindigkeit). Die, die Sie gemessen haben, sehen ziemlich realistisch aus, wie Pieter bereits betont hat.

— Zac67
quelle