Wie viel nutzbare Durchsatzkapazität nimmt der Protokolloverhead von einer Heim-NAS-Verbindung in Anspruch?

Protokoll-Overhead entfernt normalerweise einige Prozent eines gut ausgelasteten kabelgebundenen NAS-Links, bevor SMB- und Anwendungsverhalten berücksichtigt werden. Mit einer Standard-MTU von 1500 Bytes kann TCP über IPv4 1460 Bytes Anwendungs-Payload in jedem IP-Paket transportieren, während Ethernet-Frame, Präambel und Zwischenrahmenlücke zusätzliche Kabelzeit beanspruchen.

Diese Rechnung ist nur eine theoretische Effizienzobergrenze für große, saubere Übertragungen. Kleine Dateien, Teilpakete, Bestätigungen, SMB-Nachrichten, Verschlüsselung, Latenz, Wiederholungen, Speicherwartezeiten und das Verhalten des Clients können das reale Goodput deutlich weiter reduzieren.

Was ist der Unterschied zwischen Leitungsgeschwindigkeit und Goodput?

Die Leitungsgeschwindigkeit beschreibt, wie schnell die Schnittstelle Bits signalisiert, während Goodput nur die tatsächlich gelieferte Anwendungsdatenmenge zählt. Header, Bestätigungen, Wiederholungen und Steuerungsnachrichten sind echter Datenverkehr, aber keine Bytes, die zur fertigen Benutzerdatei hinzugefügt werden.

Ein 1GbE-Port kann daher nicht dauerhaft 125 MB/s an Dateipayload liefern. Diese Zahl wandelt eine Milliarde signalisierter Bits pro Sekunde in Bytes um, bevor Framing oder Protokollarbeit abgezogen werden.

Goodput sollte nach Abschluss der Übertragung auf Anwendungsebene gemessen werden. Schnittstellen-Zähler messen den gesamten Datenverkehr und können Wiederholungen oder Daten enthalten, die die Anwendung noch nicht bestätigt hat.

Wie viel entfernen Ethernet-, IP- und TCP-Header?

Für Standard-TCP über IPv4 ohne Optionen reduzieren TCP- und IP-Header die Payload-Effizienz. Die 40-Byte-Kosten für TCP/IP entsprechen etwa 2,7 % der IP-MTU, bevor der Ethernet-Kabel-Overhead einbezogen wird.

Auf der Ethernet-Kabel-Ebene verwendet ein vollformatiger Frame außerdem einen 14-Byte-Header, 4-Byte-FCS, 8-Byte-Präambel und Start-Delimiter sowie eine 12-Byte-Zwischenrahmenlücke. Eine 1460-Byte-TCP-Payload kann daher ungefähr 1538 Byte-Zeiten auf einem einfachen ungetaggten Ethernet-Pfad belegen.

Dieses Verhältnis entspricht etwa 94,9 % Payload-Effizienz. Die ungefähre Obergrenze liegt daher bei etwa 949 Mbps bei 1GbE, 2,37 Gbps bei 2,5GbE und 9,49 Gbps bei 10GbE, bevor SMB, Speicher, Bestätigungen und Implementierungsgrenzen berücksichtigt werden.

Warum ändert sich die prozentuale Verlustquote mit der Payload-Größe?

Die meisten Header haben eine feste Größe pro Paket, daher verteilen größere Nutzlasten den festen Rahmen-Overhead. Ein volles 1500-Byte-Paket ist viel effizienter als ein Paket mit nur wenigen hundert Bytes.

Kleine synchrone Anfragen können daher einen größeren Anteil ihrer Übertragungszeit mit Rahmen, Anfragen, Antworten und Bestätigungen verbringen. Dateianzahl und Anwendungs-Rundreisen sind wichtig, selbst wenn die Gesamt-Nutzlastbytes gering sind.

Jumbo Frames verbessern das Verhältnis weiter, aber der maximale mathematische Gewinn ist kleiner als viele Speicherengpässe. Sie erfordern außerdem eine konsistente MTU-Unterstützung über jedes Gerät und jede virtuelle Schicht auf dem Pfad.

Welche zusätzliche Arbeit fügt SMB über TCP hinaus hinzu?

SMB fügt Nachrichten-Header, Anforderungs- und Antwortsemantik, Credits, Authentifizierungsstatus, Signierung oder Verschlüsselung sowie Dateibetriebs-Rundreisen hinzu. kleine Dateien wiederholen Anwendungs- und Protokoll-Setup.

Bei großen, pipelined Lese- oder Schreibvorgängen kann der SMB-Overhead über beträchtliche Nutzlasten und mehrere ausstehende Anfragen verteilt werden. Bei winzigen Dateien und Metadatenoperationen werden Öffnen, Abfragen, Berechtigungen, Schließen und Verzeichnisnachrichten zu einem größeren Anteil der verstrichenen Zeit.

Signierung und Verschlüsselung verbrauchen ebenfalls CPU- und Speicherbandbreite, ohne unbedingt viele zusätzliche Bytes auf der Leitung hinzuzufügen. Protokoll-Overhead umfasst daher auch Verarbeitungskosten, nicht nur die Header-Größe.

Warum können reale Übertragungen mehr verlieren als die Header-Arithmetik vorhersagt?

Header-Arithmetik geht von vollen Nutzlasten, keinem Verlust, ausreichenden Fenstern und Endpunkten aus, die Pakete schnell genug verarbeiten. Latenz und Verlust verursachen Kosten, die über die Header-Bytes hinausgehen.

Paketverlust führt zu erneuten Übertragungen und Reduzierungen der Staukontrolle. Latenz begrenzt, wie schnell der Sender Feedback erhält. Kleine TCP-Fenster, unterfüllte Warteschlangen, Speicherpausen oder eine ausgelastete CPU-Kern können die Leitung trotz hoher theoretischer Rahmen-Effizienz untätig lassen.

Ein Dateimanager kann auch gepufferte Einzelstromkopien durchführen, während ein Benchmark mehrere Worker oder Speicherpuffer verwendet. Der Unterschied zwischen diesen Tools liegt im Anwendungsverhalten, nicht nur in den Protokoll-Headern.

Wie sollte ein Heim-NAS den praktischen Durchsatz schätzen?

Jumbo Frames reduzieren den Overhead nur auf einem validierten Pfad. Beginnen Sie mit der Standard-MTU-Leitungs-Effizienzgrenze und ziehen Sie dann gemessene Endpunkt- und Arbeitslastgrenzen ab, anstatt einen universellen Prozentsatz anzuwenden.

Verwenden Sie einen reinen Netzwerktest, um die TCP-Nutzdatenrate zu ermitteln, und führen Sie dann eine NAS-Kopie großer Dateien, eine Arbeitslast mit kleinen Dateien und die tatsächliche Anwendung aus. Protokollieren Sie Leitungsgeschwindigkeit, Anwendungsbytes, CPU, Speicherlatenz, Neusendungen, Paketgröße sowie ob Signierung oder Verschlüsselung aktiviert sind.

Eine Planungspuffer von etwa 10–15 % unter der Leitungsrate kann für die Planung großer Übertragungen sinnvoll sein, ist aber keine Protokollkonstante. Ein gut abgestimmtes LAN kann sich der Leitungs-Effizienzgrenze nähern, während kleine Dateien oder eingeschränkte Endpunkte deutlich mehr verlieren können.

FAQ

Wie hoch ist die theoretische TCP-Nutzlastobergrenze bei 1GbE?

Bei vollen 1500-Byte-TCP/IPv4-Paketen und einfacher Ethernet-Leitungsabrechnung sind es etwa 949 Mbit/s vor SMB- und Endpunktgrenzen.

Verursacht SMB immer 10 oder 15 Prozent Overhead?

Nein. Die Auswirkung hängt von Anforderungsgröße, Dateianzahl, Signierung, Verschlüsselung, Parallelität, CPU, Speicher und Client-Implementierung ab.

Werden Jumbo Frames den gesamten Protokolloverhead ausgleichen?

Nein. Sie reduzieren die Rahmen- und Verarbeitungsfrequenz pro Paket, entfernen aber nicht SMB-Operationen, Bestätigungen, Speicherwartezeiten oder Anwendungsverhalten.

Warum bleibt eine 10GbE-NAS-Kopie unter 9,49 Gbit/s?

Das Speichersystem, die Client-Festplatte, die CPU, der PCIe-Pfad, SMB-Einstellungen, Warteschlangentiefe, Paketverluste und das Kopierwerkzeug können vor der Leitungseffizienz zum Engpass werden.

Fazit

Protokolloverhead reduziert die Leitungsgeschwindigkeit auf eine geringere Nutzdatenrate durch festen Ethernet-, IP-, TCP- und SMB-Aufwand. Vollständige Standard-Frames können etwa 95 % der Leitungsgeschwindigkeit als TCP-Nutzlast beibehalten, aber echte NAS-Übertragungen zahlen auch für Dateioperationen, Sicherheit, Rückmeldungen, Verluste, Latenz und Endpunktverzögerungen. Berechnen Sie zuerst die Header-Obergrenze und messen Sie dann die arbeitslastspezifische Lücke.