Quanta larghezza di banda utilizzabile viene sottratta dal sovraccarico del protocollo in un collegamento NAS domestico?

L'overhead del protocollo solitamente rimuove qualche percentuale di un collegamento NAS cablato ben riempito prima di considerare SMB e comportamento dell'applicazione. Con un MTU standard di 1500 byte, TCP su IPv4 può trasportare 1460 byte di payload applicativo all'interno di ogni pacchetto IP, mentre il framing Ethernet, il preambolo e l'intervallo inter-frame consumano tempo aggiuntivo sul cavo.

Quell'aritmetica è solo un limite teorico di efficienza per trasferimenti grandi e puliti. File piccoli, pacchetti parziali, acknowledgements, messaggi SMB, crittografia, latenza, ritrasmissioni, attese di storage e comportamento del client possono ridurre molto di più il goodput reale.

Qual è la differenza tra velocità di linea e goodput?

La velocità di linea descrive quanto velocemente l'interfaccia segnala i bit, mentre il goodput conta solo i dati applicativi consegnati. Header, acknowledgements, ritrasmissioni e messaggi di controllo sono traffico reale ma non byte aggiunti al file utente completato.

Una porta 1GbE quindi non può fornire indefinitamente 125 MB/s di payload file. Quel numero converte un miliardo di bit segnalati al secondo in byte prima di sottrarre qualsiasi lavoro di framing o protocollo.

Il goodput dovrebbe essere misurato all'applicazione dopo il completamento del trasferimento. I contatori dell'interfaccia misurano un traffico più ampio e possono includere ritrasmissioni o dati che l'applicazione non ha ancora confermato.

Quanto rimuovono gli header Ethernet, IP e TCP?

Per il TCP standard su IPv4 senza opzioni, gli header TCP e IP riducono l'efficienza del payload. Il costo di 40 byte per TCP/IP è circa il 2,7% dell'MTU IP prima di includere l'overhead del cavo Ethernet.

A livello di cavo Ethernet, un frame a grandezza piena utilizza anche un header di 14 byte, un FCS di 4 byte, un preambolo e delimitatore di inizio di 8 byte e un intervallo inter-frame di 12 byte. Un payload TCP di 1460 byte può quindi occupare circa 1538 byte-time su un percorso Ethernet semplice e non taggato.

Quel rapporto corrisponde a circa il 94,9% di efficienza del payload. Il limite approssimativo è quindi intorno a 949 Mbps su 1GbE, 2,37 Gbps su 2,5GbE e 9,49 Gbps su 10GbE prima di SMB, storage, acknowledgements e limiti di implementazione.

Perché la dimensione del payload cambia la percentuale persa?

La maggior parte degli header ha una dimensione fissa per pacchetto, quindi payload più grandi ammortizzano il sovraccarico fisso del frame. Un pacchetto completo da 1500 byte è molto più efficiente di un pacchetto che trasporta solo poche centinaia di byte.

Le richieste sincrone piccole possono quindi spendere una quota maggiore del loro tempo sul collegamento per incapsulamento, richieste, risposte e riconoscimenti. Il numero di file e i round trip dell'applicazione contano anche quando i byte totali del payload sono modesti.

I jumbo frame migliorano ulteriormente il rapporto, ma il guadagno matematico massimo è inferiore a molti colli di bottiglia di archiviazione. Richiedono inoltre un supporto MTU coerente su ogni dispositivo e livello virtuale del percorso.

Quale lavoro aggiuntivo fa SMB rispetto a TCP?

SMB aggiunge header dei messaggi, semantica di richiesta e risposta, crediti, stato di autenticazione, firma o crittografia e round trip delle operazioni sui file. i file piccoli ripetono la configurazione dell'applicazione e del protocollo.

Per una lettura o scrittura pipeline di grandi dimensioni, il sovraccarico SMB può essere ammortizzato su payload sostanziali e diverse richieste in sospeso. Per file piccoli e operazioni di metadati, messaggi di apertura, query, permessi, chiusura e directory diventano una quota maggiore del tempo trascorso.

La firma e la crittografia consumano anche CPU e larghezza di banda della memoria senza necessariamente aggiungere un gran numero di byte sul collegamento. Il sovraccarico del protocollo include quindi il costo di elaborazione, non solo la dimensione dell'header.

Perché i trasferimenti reali possono perdere più di quanto prevede l'aritmetica degli header?

L'aritmetica degli header presume payload completi, nessuna perdita, finestre adeguate e endpoint che elaborano i pacchetti abbastanza velocemente. latenza e perdita creano costi oltre i byte dell'header.

La perdita di pacchetti aggiunge ritrasmissioni e riduzioni del controllo della congestione. La latenza limita la rapidità con cui il mittente riceve il feedback. Finestre TCP piccole, code non piene, pause di archiviazione o un core CPU occupato possono lasciare il collegamento inattivo anche se l'efficienza teorica dell'incapsulamento è alta.

Un file manager può anche eseguire copie a flusso singolo con buffer, mentre un benchmark utilizza diversi worker o buffer di memoria. La differenza tra questi strumenti è il comportamento dell'applicazione, non solo gli header del protocollo.

Come dovrebbe un NAS domestico stimare la velocità pratica?

i jumbo frame riducono il sovraccarico solo su un percorso convalidato. Inizia con il limite di efficienza del cavo MTU standard, poi sottrai i limiti misurati di endpoint e carico di lavoro invece di applicare una percentuale universale.

Usa un test solo di rete per stabilire la buona velocità TCP, poi esegui una copia NAS di file grandi, un carico di lavoro con file piccoli e l'applicazione reale. Registra la velocità di linea, i byte dell'applicazione, la CPU, la latenza di archiviazione, le ritrasmissioni, la dimensione dei pacchetti e se la firma o la crittografia sono abilitate.

Una tolleranza di pianificazione come il 10–15% sotto la velocità di collegamento può essere ragionevole per programmare grandi trasferimenti, ma non è una costante del protocollo. Una LAN ben ottimizzata può avvicinarsi al limite di efficienza del cavo, mentre file piccoli o endpoint limitati possono perdere molto di più.

FAQ

Qual è il limite teorico del payload TCP su 1GbE?

Con pacchetti TCP/IPv4 completi da 1500 byte e una semplice contabilizzazione Ethernet, è circa 949 Mbps prima dei limiti SMB e degli endpoint.

SMB costa sempre il 10 o 15 percento?

No. Il suo impatto dipende dalla dimensione della richiesta, dal numero di file, dalla firma, dalla crittografia, dalla concorrenza, dalla CPU, dall'archiviazione e dall'implementazione client.

I jumbo frame recupereranno tutto il sovraccarico del protocollo?

No. Riduce la frequenza di incorniciatura e elaborazione per pacchetto ma non elimina le operazioni SMB, gli acknowledgements, le attese di archiviazione o il comportamento dell'applicazione.

Perché una copia NAS 10GbE può rimanere sotto i 9,49 Gbps?

L'array di archiviazione, il disco client, la CPU, il percorso PCIe, le impostazioni SMB, la profondità della coda, la perdita di pacchetti e lo strumento di copia possono diventare limitanti prima dell'efficienza del cavo.

Conclusione finale

Il sovraccarico del protocollo trasforma la velocità di linea in una buona velocità inferiore attraverso il lavoro fisso di Ethernet, IP, TCP e SMB. I frame standard completi possono mantenere circa il 95% della velocità di linea come payload TCP, ma i trasferimenti reali NAS pagano anche per operazioni sui file, sicurezza, feedback, perdite, latenza e blocchi degli endpoint. Calcola prima il limite dell'intestazione, poi misura il divario specifico del carico di lavoro.