Hur mycket användbar genomströmning tar protokollöverhuvud från en hem-NAS-länk?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How Much Usable Throughput Does Protocol Overhead Take From a Home NAS Link? - Zima Store Online

Protokolloverhead tar vanligtvis bort några procent av en välfylld trådbunden NAS-länk innan SMB och applikationsbeteende beaktas. Med en standard 1500-byte MTU kan TCP över IPv4 bära 1460 byte applikationsnyttolast i varje IP-paket, medan Ethernet-inramning, preamble och mellanrumsintervall förbrukar ytterligare kabeltid.

Den beräkningen är bara ett teoretiskt effektivitetsmaximum för stora rena överföringar. Små filer, delvisa paket, bekräftelser, SMB-meddelanden, kryptering, latens, omöverföringar, lagringsväntan och klientbeteende kan minska verklig goodput mycket mer.

Vad är skillnaden mellan linjehastighet och goodput?

Linjehastighet beskriver hur snabbt gränssnittet signalerar bitar, medan goodput räknar endast levererad applikationsdata. Huvuden, bekräftelser, omöverföringar och kontrollmeddelanden är verklig trafik men inte byte som läggs till den färdiga användarfiler.

En 1GbE-port kan därför inte leverera 125 MB/s filnyttolast oavbrutet. Det talet omvandlar en miljard signalerade bitar per sekund till byte innan någon inramning eller protokollarbete dras av.

Goodput bör mätas vid applikationen efter att överföringen är klar. Gränssnittsräknare mäter bredare trafik och kan inkludera omförsök eller data som applikationen ännu inte har bekräftat.

Hur mycket tar Ethernet-, IP- och TCP-huvuden bort?

För standard TCP över IPv4 utan alternativ minskar TCP- och IP-huvuden nyttolasteffektiviteten. Den 40-byte TCP/IP-kostnaden är ungefär 2,7 % av IP MTU innan Ethernet-kabelns overhead inkluderas.

På Ethernet-kabelnivå använder en fullstor ram också en 14-byte header, 4-byte FCS, 8-byte preamble och startavgränsare samt ett 12-byte mellanrumsintervall. En 1460-byte TCP-nyttolast kan därför uppta ungefär 1538 byte-tider på en enkel otaggad Ethernet-väg.

Den andelen är ungefär 94,9 % nyttolasteffektivitet. Den ungefärliga takgränsen är därför runt 949 Mbps på 1GbE, 2,37 Gbps på 2,5GbE och 9,49 Gbps på 10GbE innan SMB, lagring, bekräftelser och implementeringsbegränsningar.

Varför ändrar storleken på nyttolasten den procentuella förlusten?

De flesta headers har en fast storlek per paket, så större nyttolaster fördelar fast ramöverhuvud. Ett fullt 1500-byte paket är mycket mer effektivt än ett paket som bara bär några hundra byte.

Små synkrona förfrågningar kan därför spendera en större del av sin trådtid på ramning, förfrågningar, svar och bekräftelser. Antal filer och applikationsrundresor spelar roll även när totala nyttolastbitar är måttliga.

Jumbo-ramar förbättrar förhållandet ytterligare, men den maximala matematiska vinsten är mindre än många lagringsflaskhalsar. De kräver också konsekvent MTU-stöd över varje enhet och virtuell lager på vägen.

Vilket ytterligare arbete lägger SMB till ovanpå TCP?

SMB lägger till meddelandehuvuden, förfrågnings- och svarssyntax, krediter, autentiseringstillstånd, signering eller kryptering och filoperationsrundresor. små filer upprepar applikations- och protokolluppsättning.

För en stor pipelined läsning eller skrivning kan SMB-överhuvudet fördelas över betydande nyttolaster och flera pågående förfrågningar. För små filer och metadataoperationer blir öppna, fråga, behörighet, stäng och katalogmeddelanden en större del av den förflutna tiden.

Signering och kryptering förbrukar också CPU och minnesbandbredd utan att nödvändigtvis lägga till ett stort antal trådbitar. Protokollöverhuvud inkluderar därför bearbetningskostnad, inte bara headerstorlek.

Varför kan verkliga överföringar förlora mer än vad headeraritmetik förutspår?

Headeraritmetik förutsätter fulla nyttolaster, ingen förlust, tillräckliga fönster och ändpunkter som bearbetar paket tillräckligt snabbt. latens och förlust skapar kostnader utöver headerbytes.

Paketförlust leder till omöverföringar och minskningar i trängselkontroll. Latens begränsar hur snabbt sändaren får återkoppling. Små TCP-fönster, underfyllda köer, lagringspauser eller en upptagen CPU-kärna kan lämna ledningen tom trots att den teoretiska ramningseffektiviteten är hög.

En filhanterare kan också utföra buffrade enkelströmskopior, medan ett benchmark använder flera arbetare eller minnesbuffertar. Skillnaden mellan dessa verktyg är applikationsbeteende, inte bara protokollhuvuden.

Hur bör en hemmabaserad NAS uppskatta praktisk genomströmning?

jumbo frames minskar överhuvud endast på en validerad väg. Börja med standard-MTU trådeffektivitetstak, dra sedan bort uppmätta ändpunkt- och arbetsbelastningsbegränsningar istället för att använda en universell procentsats.

Använd ett nätverksendast-test för att fastställa TCP-godput, kör sedan en storfilskopia på NAS, en liten filarbetsbelastning och den faktiska applikationen. Registrera linjehastighet, applikationsbyte, CPU, lagringslatens, ombearbetningar, paketstorlek och om signering eller kryptering är aktiverat.

En planeringsmarginal på 10–15 % under länkhastigheten kan vara rimlig för schemaläggning av stora överföringar, men det är inte en protokollkonstant. Ett väloptimerat LAN kan närma sig trådeffektivitetstaket, medan små filer eller begränsade ändpunkter kan förlora mycket mer.

Lager eller villkor	Vad det förbrukar	Effekt på godput
Ethernet + IP + TCP	Headers, preamble, FCS och mellanramsgap	Några procent med fullständiga standardramar
SMB	Kommandon, krediter, autentisering, signering, kryptering	Liten för stor pipelined I/O; större för metadataintensivt arbete
Små eller delvisa payloads	Fast överhuvud upprepat över färre byte	Lägre effektivitet per paket och per fil
Förlust, latens och stopp vid ändpunkter	Ombearbetning, väntan, minskad sändningshastighet, tom tråd	Kan överstiga förlust endast för header avsevärt

Vanliga frågor

Vad är det teoretiska TCP-payloadtaket på 1GbE?

Med fulla 1500-byte TCP/IPv4-paket och enkel Ethernet-trådräkning är det ungefär 949 Mbps före SMB- och ändpunktbegränsningar.

Kostar SMB alltid 10 eller 15 procent?

Nej. Dess påverkan beror på förfrågningsstorlek, antal filer, signering, kryptering, samtidighet, CPU, lagring och klientimplementering.

Kommer jumbo frames att återställa all protokollöverhuvud?

Nej. De minskar per-paket inramning och bearbetningsfrekvens men tar inte bort SMB-operationer, bekräftelser, lagringsväntan eller applikationsbeteende.

Varför kan en 10GbE NAS-kopia ligga under 9,49 Gbps?

Lagringsarrayen, klientdisken, CPU:n, PCIe-vägen, SMB-inställningar, ködjup, paketförlust och kopieringsverktyget kan bli begränsande innan trådeffektiviteten.

Slutlig slutsats

Protokollöverhuvud förvandlar linjehastighet till lägre godput genom fast Ethernet, IP, TCP och SMB-arbete. Fullständiga standardramar kan behålla ungefär 95 % av trådhastigheten som TCP-payload, men verkliga NAS-överföringar betalar också för filoperationer, säkerhet, återkoppling, förlust, latens och stopp vid ändpunkter. Beräkna först header-taket, mät sedan arbetsbelastningsspecifika gapet.