Cercando di scoprire il costo esatto del TCP

9

Corrispondente a questo argomento:

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

La dimensione massima del segmento (che non include le intestazioni TCP o IP) viene in genere negoziata tra i livelli con la dimensione dell'MTU meno la dimensione delle intestazioni. Per Ethernet MTU è generalmente configurato a 1500 byte. L'intestazione TCP è di 160 bit o 20 byte. La parte fissa dell'intestazione IPv4 è di 160 bit o anche di 20 byte. ... Così:

per HTTP su TCP / IPv4

overhead = TCP + IP = 40 byte

payload = 1500 - 40 = 1460 byte

spese generali% = 2% (40 * 100/1460)

Ecco i risultati iperf a 100 Mbit e 1Gbit in modalità TCP con distribuzioni Debian predefinite:

[  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

Posso abbassarlo a quasi il 2% di sovraccarico aumentando MTU a 9000:

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

Ma non dovrebbe essere anche meno?

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

Perché l'attuale "perdita di larghezza di banda" è notevolmente maggiore di quella teorica? Se la formula manca qualcosa di prezioso?

tcp bandwidth

— agrrh
fonte

16

Pacchetti Ethernet 1.5k

1500-20 B (IPv4) - 20 B (TCP + checksum) = 1460 B DATI (e 40 B spese generali)

Aggiungi 40 B + 14 B (Ethernet) + 4 B (FCS) + 12 B (Interframe gap) + 8 B (preambolo) = 78 B Overhead

78/1460 * 100 = 5,34% di spese generali

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

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

hai misurato 941Mbit / s che dà un errore (949 - 941) / 949 * 100 = 0,84% tra teorico e reale.

Pacchetti jumbo 9k - teorico 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
fonte

1

Probabilmente c'è anche influenza della funzione di avvio lento, ma non sono sicuro che sia abbastanza grande. Grazie. :)

— agrrh

Ah, Ethernet ha un FCS a 4 byte alla fine del frame, permettetemi di aggiungerlo al calcolo.

— Pieter,

4

Le spese generali sono generalmente calcolate in base alla dimensione totale dei dati. In questo modo, la cifra corrisponde al valore di efficienza.

Per TCP su IPv4 su Ethernet hai (senza opzioni di intestazione):

Overhead L1 - preambolo, IPG: 8 + 12 = 20
Overhead L2 - header Ethernet, FCS = 18
Overhead L3 - intestazione IPv4 = 20
Overhead L4 - intestazione TCP = 20

La dimensione massima del pacchetto L3 di 1500 determina una dimensione totale dei dati L1 di 1500 + 18 + 20 = 1538 byte e una dimensione massima del carico utile L4 di 1500-20-20 = 1460 byte .

Spese generali: 78/1538 * 100% = 5,07%
Efficienza: 1460/1538 * 100% = 94,93%

Con 9k frame jumbo (non 802.3), otterrai

Spese generali: 78/9038 * 100% = .86%
Efficienza: 8960/9038 * 100% = 99,14%

Questi sono valori teorici, nel migliore dei casi . Nella vita reale, avresti anche un po 'di overhead hardware e SO che peggiorano il valore dell'efficienza. Funzionalità come l'offload e la gestione degli interrupt multi-core possono ridurre il sovraccarico di elaborazione e avvicinarti alle cifre teoriche (più rilevanti con schede di rete più veloci). Quelli che hai misurato sembrano piuttosto realistici come già sottolineato da Pieter.

— Zac67
fonte