Hoeveel bruikbare doorvoersnelheid gaat er verloren door protocoloverhead op een thuis-NAS-verbinding?

Protocoloverhead verwijdert meestal een paar procent van een goed gevulde bekabelde NAS-verbinding voordat SMB- en applicatiegedrag worden meegerekend. Met een standaard MTU van 1500 bytes kan TCP over IPv4 1460 bytes applicatiepayload dragen in elk IP-pakket, terwijl Ethernet-framing, de preamble en de inter-frame gap extra kabeltijd verbruiken.

Die berekening is slechts een theoretisch efficiëntieplafond voor grote, schone overdrachten. Kleine bestanden, gedeeltelijke pakketten, bevestigingen, SMB-berichten, encryptie, latentie, retransmissies, opslagwachttijden en clientgedrag kunnen de werkelijke goodput veel verder verlagen.

Wat is het verschil tussen lijnsnelheid en goodput?

De lijnsnelheid beschrijft hoe snel de interface bits signaleert, terwijl goodput alleen de geleverde applicatiedata telt. Headers, bevestigingen, retransmissies en controlberichten zijn echt verkeer, maar geen bytes die aan het voltooide gebruikersbestand worden toegevoegd.

Een 1GbE-poort kan dus niet oneindig 125 MB/s aan bestands-payload leveren. Dat getal zet één miljard gesignaleerde bits per seconde om in bytes voordat framing of protocolwerk wordt afgetrokken.

Goodput moet worden gemeten bij de applicatie nadat de overdracht is voltooid. Interface-tellers meten breder verkeer en kunnen retries of data bevatten die de applicatie nog niet heeft verwerkt.

Hoeveel verwijderen Ethernet-, IP- en TCP-headers?

Voor standaard TCP over IPv4 zonder opties verminderen TCP- en IP-headers de payload-efficiëntie. De 40-byte TCP/IP-kosten zijn ongeveer 2,7% van de IP MTU voordat de Ethernet-kabeloverhead wordt meegerekend.

Op het Ethernet-kabelniveau gebruikt een frame van volledige grootte ook een header van 14 bytes, een FCS van 4 bytes, een preamble en startdelimiter van 8 bytes, en een inter-frame gap van 12 bytes. Een TCP-payload van 1460 bytes kan dus ongeveer 1538 byte-tijden innemen op een eenvoudig niet-getagd Ethernet-pad.

Die verhouding is ongeveer 94,9% payload-efficiëntie. Het geschatte maximum ligt daarom rond 949 Mbps op 1GbE, 2,37 Gbps op 2,5GbE en 9,49 Gbps op 10GbE voordat SMB, opslag, bevestigingen en implementatielimieten worden meegerekend.

Waarom verandert de payloadgrootte het percentage verloren data?

De meeste headers hebben een vaste grootte per pakket, dus grotere payloads spreiden vaste frame-overhead. Een volledig 1500-byte pakket is veel efficiënter dan een pakket dat slechts enkele honderden bytes bevat.

Kleine synchrone verzoeken kunnen daarom een groter deel van hun verbindingstijd besteden aan framing, verzoeken, antwoorden en bevestigingen. Het aantal bestanden en applicatierondreizen zijn belangrijk, zelfs als het totale aantal payloadbytes bescheiden is.

Jumbo-frames verbeteren de verhouding verder, maar de maximale wiskundige winst is kleiner dan veel opslagknelpunten. Ze vereisen ook consistente MTU-ondersteuning op elk apparaat en elke virtuele laag in het pad.

Welke Extra Taken Voegt SMB Toe Bovenop TCP?

SMB voegt berichtheaders, verzoek- en antwoordsemantiek, credits, authenticatiestatus, ondertekening of encryptie en bestandsoperatierondreizen toe. kleine bestanden herhalen applicatie- en protocolinstellingen.

Bij een grote gepijlde lees- of schrijfbewerking kan SMB-overhead worden verdeeld over aanzienlijke payloads en meerdere openstaande verzoeken. Bij kleine bestanden en metadata-operaties worden open-, query-, permissie-, sluit- en directoryberichten een groter deel van de verstreken tijd.

Ondertekening en encryptie verbruiken ook CPU- en geheugenbandbreedte zonder noodzakelijkerwijs veel extra bytes op de verbinding toe te voegen. Protocoloverhead omvat daarom verwerkingskosten, niet alleen de headergrootte.

Waarom Kunnen Werkelijke Overdrachten Meer Verliezen Dan Headerrekenkunde Voorspelt?

Headerrekenkunde gaat uit van volledige payloads, geen verlies, voldoende vensters en eindpunten die pakketten snel genoeg verwerken. latentie en verlies veroorzaken kosten die verder gaan dan headerbytes.

Pakketverlies veroorzaakt hertransmissies en verminderingen door congestiecontrole. Latentie bepaalt hoe snel de zender feedback ontvangt. Kleine TCP-vensters, niet volledig gevulde wachtrijen, opslagpauzes of één drukke CPU-kern kunnen de verbinding inactief laten, ook al is de theoretische framing-efficiëntie hoog.

Een bestandsbeheerder kan ook gebufferde enkelvoudige stream-kopieën uitvoeren, terwijl een benchmark meerdere werkers of geheugenbuffers gebruikt. Het verschil tussen die tools is het gedrag van de applicatie, niet alleen de protocolheaders.

Hoe moet een thuis-NAS praktische doorvoersnelheid inschatten?

jumbo frames verminderen overhead alleen op een gevalideerd pad. Begin met het standaard-MTU draadefficiëntieplafond en trek vervolgens gemeten eindpunt- en werklastlimieten af in plaats van één universeel percentage toe te passen.

Gebruik een netwerk-only test om TCP-doorvoersnelheid vast te stellen, voer vervolgens een grote-bestand NAS-kopie uit, een kleine-bestand werklast en de daadwerkelijke applicatie. Noteer lijnsnelheid, applicatiebytes, CPU, opslaglatentie, hertoezendingen, pakketgrootte en of ondertekening of encryptie is ingeschakeld.

Een planningsmarge van bijvoorbeeld 10–15% onder de link-snelheid kan redelijk zijn voor het plannen van grote overdrachten, maar het is geen protocolconstante. Een goed afgestemd LAN kan het draadefficiëntieplafond benaderen, terwijl kleine bestanden of beperkte eindpunten veel meer kunnen verliezen.

Veelgestelde vragen

Wat is het theoretische TCP-payloadplafond op 1GbE?

Met volledige 1500-byte TCP/IPv4-pakketten en eenvoudige Ethernet-draadverantwoording is het ongeveer 949 Mbps vóór SMB- en eindpuntlimieten.

Kosten SMB altijd 10 of 15 procent?

Nee. De impact hangt af van de verzoekgrootte, het aantal bestanden, ondertekening, encryptie, gelijktijdigheid, CPU, opslag en clientimplementatie.

Herstellen jumbo frames alle protocoloverhead?

Nee. Ze verminderen de framing en verwerkingsfrequentie per pakket, maar verwijderen geen SMB-bewerkingen, bevestigingen, opslagwachttijden of applicatiegedrag.

Waarom blijft een 10GbE NAS-kopie onder de 9,49 Gbps?

De opslagarray, client-schijf, CPU, PCIe-pad, SMB-instellingen, wachtrijdiepte, pakketverlies en kopieerhulpmiddel kunnen beperkend worden voordat de draadefficiëntie dat is.

Belangrijkste conclusie

Protocol overhead verlaagt de lijnsnelheid tot een lagere effectieve doorvoersnelheid door vaste Ethernet-, IP-, TCP- en SMB-taken. Volledige standaardframes kunnen ongeveer 95% van de draadnelheid behouden als TCP-payload, maar echte NAS-overdrachten betalen ook voor bestandsbewerkingen, beveiliging, feedback, verlies, latentie en vertragingen bij eindpunten. Bereken eerst het headerplafond en meet vervolgens de werklastspecifieke kloof.