TCP-Optimierung für höhere Netzwerkleistung

Das globale Netzwerk in Google Cloud bietet hohe Zuverlässigkeit und niedrige Latenz, indem Anwendungen über Regionen und Zonen hinweg verbunden werden, ohne das Google-Netzwerk zu verlassen. Die standardmäßigen TCP/IP-Einstellungen für Linux sind jedoch häufig für lokale Umgebungen optimiert und können in der Cloud zu Leistungsengpässen führen.

Für eine optimale Leistung in Google Cloudverwenden Sie die TCP/IP-Einstellungen in diesem Dokument, die speziell für die Cloud-Umgebung optimiert sind.

Die in diesem Dokument erwähnten Einstellungen wurden für die Verwendung in derGoogle Cloud -Umgebung getestet. Die Einstellungen sind hauptsächlich für die interne Instanzkommunikation vorgesehen und gelten nicht unbedingt für die Kommunikation zwischen Compute Engine-Instanzen und externen Adressen.

Informationen zum Durchsatzlimit

TCP verwendet einen „Windowing“-Mechanismus, um den Datenfluss zwischen einem Sender und einem Empfänger zu verwalten. Der maximal erreichbare Durchsatz wird durch die folgende Beziehung bestimmt:

Throughput <= window size / round-trip time (RTT) latency

Im ursprünglichen TCP-Design ist die maximale Fenstergröße auf 65.535 Byte (64 KiB – 1) begrenzt. Das führt häufig dazu, dass moderne Hochgeschwindigkeitsnetzwerke nicht ausreichend genutzt werden, da der Absender auf Fensteraktualisierungen wartet.

Shell-Skript zur Optimierung der TCP-Leistung

Die folgenden TCP-Konfigurationen werden empfohlen, um die Leistung zu verbessern:

Sie können diese vorgeschlagenen Einstellungen mit dem folgenden Shell-Skript aktivieren. Bevor Sie das Skript ausführen, müssen Sie eth0 durch die primäre Netzwerkschnittstelle für Ihre Compute-Instanz ersetzen.

# Set DEV to your primary network interface
DEV=eth0

# 1. Reduce MinRTO
sysctl -w net.ipv4.tcp_rto_min_us=5000

# 2. Enable Fair Queueing
tc qdisc replace dev $DEV root fq

# 3. Disable slow start after idle
sysctl -w net.ipv4.tcp_slow_start_after_idle=0

# 4. Disable TCP Cubic HyStart ACK train
echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect

# 5. Increase socket memory budgets
echo 4194304 > /proc/sys/net/core/rmem_max
echo 4194304 > /proc/sys/net/core/wmem_max
echo 4194304 > /proc/sys/net/ipv4/tcp_notsent_lowat
echo "4096 262144 16777216" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 262144 33554432" > /proc/sys/net/ipv4/tcp_wmem

# 6. Enable hardware GRO
ethtool -K $DEV rx-gro-hw on

In den folgenden Abschnitten werden die einzelnen vorgeschlagenen Konfigurationseinstellungen genauer beschrieben.

MinRTO reduzieren

Schnellere Wiederherstellung nach Paketverlust durch Reduzierung von Verzögerungen bei der erneuten Übertragung.

Das TCP-Retransmission Timeout (RTO) steuert, wie lange ein TCP-Absender auf ein ACK-Signal wartet, bevor er die Übertragung wiederholt. Linux initialisiert das RTO auf eine Sekunde (gemäß RFC 6298, Abschnitt 2.1) und passt es dann im Laufe der Zeit an die Round-Trip-Zeit (RTT) plus einen Sicherheitsabstand an.

Mit dem minimalen RTO (MinRTO) wird eine Untergrenze für diese Anpassung festgelegt. Wenn die RTO-Schätzung zu niedrig ist, kann dies zu fälschlichen Neuübertragungen führen, bei denen der Absender Pakete neu überträgt, während die Antwort noch verarbeitet wird.

Der Standardwert für MinRTO ist 200 ms, was für moderne Cloud-Netzwerke unnötig konservativ ist. Ein Wert von 5 ms wurde inGoogle Cloud ausgiebig getestet und ist ein sicherer Standardwert für Verbindungen zwischen modernen Linux-Servern in Google Cloud.

Ein weiterer Faktor sind verzögerte Bestätigungen, bei denen der Peer ACK-Antworten verzögert. Diese Verzögerung ermöglicht das Batching von ACKs über mehrere Datenpakete hinweg oder die Kombination eines ACK mit einem Datenpaket in umgekehrter Richtung. Verzögerte ACK-Timer basieren auf der RTT, ähnlich wie der RTO-Timer.

Durch Verringern von MinRTO wird die Fehlerbehebung bei Verbindungen mit niedriger RTT, z. B. Verbindungen innerhalb einer Zone oder Region, beschleunigt. Diese Anpassung hat keine Auswirkungen auf Verbindungen mit einer hohen RTT, da sich die geschätzte RTT nicht ändert.

MinRTO konfigurieren

Sie können MinRTO mit einer der beiden folgenden Methoden konfigurieren:

  1. sysctl (Linux 6.11 und höher) verwenden:

    Sie können den Standardwert für „MinRTO“ mit einem sysctl-Befehl konfigurieren:

    sysctl -w net.ipv4.tcp_rto_min_us=5000

  2. ip route verwenden (Steuerung pro Route oder Linux-Versionen vor 6.11):

    Alternativ kann MinRTO für ältere Linux-Versionen oder zur Steuerung pro Route auf Routenbasis festgelegt werden:

    ip route change default rto_min 5ms

Der Ansatz pro Route ist in Umgebungen vorzuziehen, in denen Verbindungen Google Cloud oder mit Nicht-Linux-TCP/IP-Stacks kommunizieren. Diese Systeme haben möglicherweise unterschiedliche Zeitgeber für verzögerte Bestätigungen. Für eine breite Bereitstellung im öffentlichen Internet wird empfohlen, die konservative Standardeinstellung für minRTO beizubehalten und die Einstellung von 5 ms nur für Routen innerhalb der Google Cloud Virtual Private Cloud anzuwenden.

Fair Queueing aktivieren

Überlastung und Paketverluste durch Anwendungs-Bursts minimieren

Im Gegensatz zu Standard-FIFO-Warteschlangen (First-In, First-Out) wird bei Fair Queueing (FQ) die Bandbreite gleichmäßig auf verschiedene Flows verteilt. Außerdem wird der Traffic durch die Berechnung der optimalen Übertragungsrate und ‑zeit für jedes Paket für jede TCP-Verbindung gesteuert. Wenn FQ vorhanden ist, werden Pakete im TCP-Stack mithilfe von FQ bis zum optimalen Zustellzeitpunkt zurückgehalten. Durch diese Ratenbegrenzung werden Bursts in einem Flow reduziert, was wiederum Paketverluste und Neuübertragungen minimiert.

Wenn Sie den FQ-Traffic Shaper als Traffic Shaper für das Netzwerkgerät festlegen möchten, verwenden Sie den folgenden tc-Befehl (Traffic Control):

tc qdisc replace dev $DEV root fq

Auf großen Instanzen mit hoher Bandbreite für ausgehenden Traffic kann das Netzwerkgerät mehrere Übertragungswarteschlangen haben. Für diese Instanzen kann es besser sein, die Traffic-Regelung auf die Übertragungswarteschlangen aufzuteilen, indem Sie den Multi Queue (MQ)-Traffic-Regler installieren. Dies ist ein Multiplexer, der jeder Übertragungswarteschlange einen unabhängigen Traffic Shaper zuweist. Traffic Shaper pro Warteschlange reduzieren die Konflikte bei Sperren und Cachezeilen über CPUs hinweg.

Langsamen Start nach Inaktivität deaktivieren

Hohe Übertragungsraten auch nach einer inaktiven Verbindung beibehalten.

Um Überlastungen zu vermeiden, werden bei TCP-Verbindungen Daten zuerst mit einer niedrigen Rate gesendet. Die Rate wird dann exponentiell erhöht, bis Paketverluste erkannt werden. Diese erste Phase wird als Slow Start bezeichnet.

Standardmäßig kehrt TCP nach einer Leerlaufphase zu den konservativen „Slow Start“-Einstellungen zurück. Eine Leerlaufphase kann so kurz wie ein RTO (Retransmission Timeout) sein, wie in RFC 2581 definiert. Wenn Sie diese Funktion deaktivieren, kann die Verbindung sofort mit der zuletzt als funktionierend bekannten Rate fortgesetzt werden.

Wo möglich, sollten Anwendungen langlebige Verbindungen anstelle von wiederholten Verbindungsaufbauten zum selben Peer verwenden. So werden die Kosten für den Verbindungsaufbau vermieden und die Informationen zur Überlastung bleiben erhalten. Auch bei langlebigen Verbindungen vergisst TCP jedoch nach einer Leerlaufphase standardmäßig Informationen zur Überlastung und kehrt zur ursprünglichen konservativen Einstellung und zur „Slow Start“-Phase zurück.

Verwenden Sie den folgenden Befehl, um die Funktion „Langsamer Start nach Inaktivität“ zu deaktivieren:

sysctl -w net.ipv4.tcp_slow_start_after_idle=0

TCP Cubic HyStart ACK-Train deaktivieren

Schnell auf hohe Übertragungsraten skalieren, indem falsch positive Überlastungssignale ignoriert werden.

Die exponentielle Wachstumsrate in der Phase „Langsamer Start“ kann aggressiv sein und möglicherweise die optimale Zielrate überschreiten. Hybrid Start (HyStart) ist ein zusätzlicher Mechanismus, der darauf ausgelegt ist, die „Slow Start“-Phase früher zu beenden. Dazu werden zwei wichtige Überlastungssignale verwendet:

  • Verzögerung durch die Umlaufzeit (Round Trip Time, RTT): Misst die Ausbreitungsverzögerung von Paketen im Netzwerk. Bei Netzwerküberlastung bilden sich an Engstellen im Netzwerk Paketwarteschlangen. Dadurch erhöht sich die RTT, was auf eine Überlastung hinweisen kann.
  • ACK-Abstand: Hier werden Signale verwendet, die darauf hinweisen, dass Pakete an einem Engpass verzögert werden. Der Fokus liegt jedoch auf den Antwort-ACKs. Bei diesem Mechanismus wird davon ausgegangen, dass Bestätigungen ohne Überlastung mit demselben Abstand wie die ursprünglichen Datenpakete eintreffen. Dieses Muster wird oft als ACK-Train bezeichnet. Wenn ACKs länger als erwartet verzögert werden, deutet dies auf eine mögliche Überlastung hin.

Um die Leistung zu optimieren, sollten Sie die Erkennung von ACK-Paketfolgen deaktivieren, während der RTT-Verzögerungsmechanismus aktiviert bleibt.

echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect

Sockel-Arbeitsspeicherbudgets erhöhen

Den maximalen Durchsatz auf Verbindungen mit hoher RTT erhöhen, indem mehr Daten in der Übertragung zugelassen werden.

Die Menge der übertragenen Daten ist eine Funktion der Bandbreite und der Signallaufzeit, die als Verzögerungs-Bandbreiten-Produkt (Bandwidth-Delay Product, BDP) bezeichnet wird. Das BDP wird durch Multiplikation der Bandbreite mit der Umlaufzeit (RTT) berechnet. Dieser Wert gibt die optimale Anzahl von Bits an, die zum Füllen der Pipe gesendet werden sollten:

BDP (bits) = bandwidth (bits/second) * RTT (seconds)

Alle Daten, die gerade übertragen werden, müssen auf dem Absender gepuffert werden, falls sie noch einmal gesendet werden müssen. Die TCP-Socket-Speicherlimits können den erreichbaren Durchsatz direkt begrenzen, da sie festlegen, wie viele In-Flight-Daten gepuffert werden können.

In Linux werden die TCP-Socket-Arbeitsspeicherlimits mit den folgenden sysctl(8)-Einstellungen konfiguriert:

  • net.core.rmem_max
  • net.core.wmem_max
  • net.ipv4.tcp_rmem
  • net.ipv4.tcp_wmem

Diese TCP-Socket-Arbeitsspeicherlimits sind dazu da, zu verhindern, dass der gesamte Systemspeicher aufgebraucht wird und es zu Arbeitsspeichermangel kommt, insbesondere bei Arbeitslasten mit vielen Verbindungen. Durch Erhöhen dieser Limits kann der Durchsatz insbesondere bei Pfaden mit hoher RTT gesteigert werden. Sofern die Anzahl der Verbindungen nicht im Millionenbereich liegt, besteht kaum ein Risiko, wenn Sie diese Limits erhöhen.

Diese Variablen legen Obergrenzen für die Größe des Socket-Puffers fest, nicht für die direkte Speicherzuweisung. Das Erhöhen dieser Werte hat keine Auswirkungen auf die tatsächliche Speicherzuweisung für Verbindungen mit niedriger RTT, z. B. innerhalb einer Google Cloud -Zone.

Die ersten beiden einstellbaren Parameter wirken sich auf die maximale TCP-Fenstergröße für Anwendungen aus, die die TCP-Fenstergröße direkt festlegen. Das ist bei relativ wenigen Anwendungen der Fall. Diese Grenzwerte begrenzen, was eine Anwendung mit den Socket-Optionen SO_RCVBUF und SO_SNDBUF explizit anfordern kann.

Bei Linux-Kernel-Versionen 6.18 und höher sind net.core.rmem_max und net.core.wmem_max standardmäßig auf 4 MB festgelegt. Diese Einstellungen gelten aufgrund jahrelanger Erfahrung als sicher. Bei älteren Linux-Versionen empfehlen wir, diese Grenzwerte auf modernen Plattformen auf 4 MB zu erhöhen:

echo 4194304 > /proc/sys/net/core/rmem_max
echo 4194304 > /proc/sys/net/core/wmem_max

Die zweite Gruppe von Grenzwerten, net.ipv4.tcp_rmem und net.ipv4.tcp_wmem, steuert die Grenzwerte für die automatische Anpassung des TCP-Sende- und ‑Empfangspuffers.

Jede dieser Einstellungen hat drei Werte: die Mindest-, die anfängliche Standard- und die maximale Socket-Arbeitsspeichergröße. Die Standard-Höchstwerte sind oft konservativer als auf modernen Plattformen erforderlich, z. B.:

  • tcp_rmem: 4096, 131072, 6291456
  • tcp_wmem: 4096, 16384, 4194304

Der TCP-Stack passt die Größe der TCP-Sende- und ‑Empfangspuffer automatisch an, basierend auf Schätzungen von RTT und Congestion Window. Eine maximale Schreibpuffergröße von 4.194.304 oder 4 MB ist für Verbindungen mit hoher RTT klein. Bei einer RTT von 100 ms wird der Durchsatz mit dieser Einstellung im besten Fall auf 40 MB/s begrenzt. Anstatt zu versuchen, die zu verwendenden Werte zu berechnen, ist es einfacher, sichere Standardwerte für moderne Server mit viel RAM zu verwenden.

Als zusätzliche Vorsichtsmaßnahme empfehlen wir, die Menge der Daten zu begrenzen, die im Socket in die Warteschlange gestellt, aber noch nicht gesendet werden können. Das Ziel, die maximale wmem zu erhöhen, besteht darin, mehr Daten zu übertragen. Ein Prozess kann jedoch schneller in den Socket schreiben, als TCP die Daten senden kann. Dadurch kann sich auf dem Host eine Warteschlange mit nicht gesendeten Daten bilden, die Speicherplatz verschwendet. Um dies zu verhindern, begrenzen Sie die Menge der noch nicht gesendeten Daten, indem Sie tcp_notsent_lowat festlegen, und erhöhen Sie dann das allgemeine wmem-Limit, um größere In-Flight-Puffer zu ermöglichen.

Sofern ein Server nicht Millionen von Verbindungen hat, sollten die folgenden Einstellungen sicher sein. Wenn Sie jedoch bei vielen Verbindungen Probleme mit dem Arbeitsspeicher haben, sollten Sie eine niedrigere maximale Puffergröße verwenden.

echo 4194304 > /proc/sys/net/ipv4/tcp_notsent_lowat

echo "4096 262144 16777216" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 262144 33554432" > /proc/sys/net/ipv4/tcp_wmem

Hardware-GRO aktivieren

Die Effizienz der TCP/IP-Empfangsverarbeitung für große Datenströme wird erhöht. CPU-Overhead durch Batchverarbeitung empfangener Pakete reduzieren

Bei den meisten TCP/IP-Vorgängen skaliert der CPU-Zyklusaufwand mit der Paketrate, nicht mit der Byterate. Um diesen Übertragungs-Overhead zu verringern, senden moderne Betriebssysteme TCP-Daten über den Übertragungspfad in großen Paketen, die mehrere TCP-Segmente enthalten. Diese können bis zu 64 KB oder mit Linux BIG-TCP sogar Hunderte von Kilobyte groß sein.

Solche großen Pakete überschreiten die maximale Paketgröße im Netzwerk, die MTU. Diese Betriebssystemoptimierung setzt voraus, dass das Netzwerkgerät die Pakete aufteilen und als Reihe kleinerer Pakete senden kann, die jeweils ein einzelnes TCP-Segment enthalten. Diese Unterstützung, TCP Segmentation Offload (TSO), ist weit verbreitet und standardmäßig aktiviert.

Beim Empfang können GVNIC-Geräte auf Plattformen der dritten Generation und neuer das Gegenteil tun: Segmente werden kurz auf dem Gerät gepuffert, um zu sehen, ob aufeinanderfolgende Segmente eintreffen. Wenn dies der Fall ist, werden sie kombiniert und als Pakete mit mehreren Segmenten an den Host weitergeleitet. Diese Funktion wird in Windows als „Receive Segment Coalescing“ (RSC) und in Linux als „Large Receive Offload“ (LRO) oder „Hardware Generic Receive Offload“ (HW-GRO) bezeichnet. HW-GRO ist eine strengere Verfeinerung von LRO.

HW-GRO kann standardmäßig aktiviert werden. Das geschieht dann, wenn die Funktion verfügbar ist.

In der Zwischenzeit können Sie auf Plattformen mit GVNIC-Geräten, die das Feature unterstützen, HW-GRO mit „ethtool“ aktivieren. Je nach Kernel- und Treiberversion wird die Funktion als LRO oder HW-GRO beworben. Die Implementierung ist unabhängig vom Namen gleich.

    ethtool -K $DEV large-receive-offload on
    ethtool -K $DEV rx-gro-hw on

MTU-Größe auf 4.082 Byte erhöhen

Die Effizienz der Datenübertragung für Flows mit hohem Durchsatz wird erhöht.

Durch Erhöhen der Paketgröße, ähnlich wie bei TSO- und HW-GRO-Optimierungen, wird die Übertragungseffizienz gesteigert, da die meiste Verarbeitung pro Paket und nicht pro Byte erfolgt.

Google Cloud VPC-Netzwerke können Pakete mit bis zu 8.898 Byte unterstützen. Das ist deutlich mehr als die Standard-MTU von 1.460 Byte. Durch die Verwendung einer größeren Netzwerkpaketgröße werden die CPU-Zyklen reduziert, die pro Byte Durchsatz (Goodput) aufgewendet werden.

Überlegungen zur optimalen Paketgröße

Größere Pakete sind zwar im Allgemeinen besser, die maximal mögliche MTU ist jedoch nicht immer die optimale Wahl. Die Effizienz, die durch das Senden weniger Pakete erzielt wird, muss gegen die folgenden Kosten abgewogen werden:

  • Arbeitsspeichernutzung: Größere Puffer erfordern mehr Arbeitsspeicher, der dem Netzwerkgerät für den Paketempfang zugewiesen wird. Wenn Sie viele Warteschlangen haben, kann eine beträchtliche Menge an Arbeitsspeicher ungenutzt bleiben.
  • Verarbeitung kleiner Pakete: Größere Puffer verarbeiten kleine Pakete wie reine Bestätigungen (ACKs) weniger effizient.
  • Kosten für die CPU-Zuweisung: Die Kosten für den Datenpfad werden erheblich durch die Speicherzuweisung und -freigabe beeinflusst. Wenn Sie die Paketgröße an einem Vielfachen von Speicherseiten ausrichten, können Sie diese CPU-Kosten optimieren.
  • TSO-Interaktion: Die Paketgröße wirkt sich subtil auf TSO (TCP Segmentation Offload) aus. Wenn Sie das größtmögliche TSO-Paket erstellen möchten, müssen Sie möglicherweise eine kleinere maximale Segmentgröße (MSS) auswählen. Bei einem maximalen IP-Paket von 64 KB einschließlich Headern führt ein MSS von 4 KB zu einer größeren Nutzlast (60 KB) als ein MSS von 8 KB (56 KB).

Bei den meisten Arbeitslasten ist der Effizienzunterschied zwischen 4 KB, 8 KB oder 9 KB MTUs gering. Jede dieser Optionen stellt jedoch eine erhebliche Verbesserung gegenüber den Standardpaketen mit 1.460 Byte dar.

Empfehlung für Pakete in Seitengröße

Als robuste und in der Regel effiziente Option empfehlen wir, die MTU-Größe für Ihr VPC-Netzwerk auf 4.082 Byte festzulegen. Diese Größe wird empfohlen, da das gesamte Ethernet-Paket in eine 4096-Byte-Speicherseite passt, was die Zuweisung von Speicherseiten optimiert. Diese Empfehlung bezieht sich auf die MTU der Schicht 3, die den IP-Header, aber nicht die 14 Byte der Ethernet-Verbindungsschicht enthält.

IP-MTU-Konfiguration

Sie können die MTU für jedes VPC-Netzwerk direkt über die Google Cloud Konsole konfigurieren.

Bei den meisten Linux-Distributionen in Google Cloudist keine manuelle Konfiguration auf der Compute-Instanz erforderlich. Die Instanz ermittelt die Netzwerk-MTU beim Booten automatisch über DHCP (mit Option 26). Die Instanz legt dann die MTU des Netzwerkgeräts entsprechend fest. Wir empfehlen, diese automatische Konfiguration zu verwenden.

Wenn eine manuelle Konfiguration erforderlich ist, kann die MTU des Netzwerkgeräts mit dem folgenden Befehl auf einen Wert unter der MTU des VPC-Netzwerk festgelegt werden:

ip link set dev $DEV mtu 4082

Unterschiedliche MTU-Größen für bestimmte Routen festlegen

Wenn Ihre Compute-Instanz extern außerhalb der VPC kommuniziert, wo die Path-MTU möglicherweise niedriger ist, ist es besser, die MTU für bestimmte Routen festzulegen. Legen Sie in diesem Fall die Standard-MTU auf die konservativen 1.460 Byte fest und wenden Sie die höhere MTU (z. B. 4.082 Byte) nur für VPC-interne Routen an:

#Set intra-VPC route MTU:
ip -4 route change $SUBNET/$MASK dev $DEV mtu 4082
#Set default route MTU:
ip -4 route change default dev $DEV mtu 1460

Maximale Segmentgröße (MSS) für TCP konfigurieren

Die maximale Segmentgröße (Maximum Segment Size, MSS) von TCP bestimmt die Größe der Paketnutzlast für eine TCP-Verbindung. Da TCP/IP-Pakete die MTU-Größe nicht überschreiten dürfen, um Fragmentierung oder Paketverluste zu vermeiden, muss die MSS entsprechend skaliert werden.

Im Allgemeinen müssen Sie die TCP-MSS nicht manuell konfigurieren, da das Betriebssystem sie automatisch aus der Pfad-MTU ableitet.

MSS umfasst die Nutzlast und die TCP-Optionen, schließt aber den 20 Byte großen IPv4-Header und den 20 Byte großen TCP-Header aus. Daher ist die MSS in einem IPv4-Netzwerk in der Regel 40 Byte kleiner als die MTU.

Wenn Sie für bestimmten Traffic eine kleinere MSS bevorzugen, können Sie sie für jede Route konfigurieren. Wenn Ihr VPC-Netzwerk und Ihre Geräte-MTU beispielsweise die maximale MTU (8.896 Byte) für allgemeinen Traffic verwenden, Sie aber eine 4-KB-MTU für TCP-Traffic verwenden möchten, können Sie den folgenden Befehl verwenden:

ip -4 route change default dev $DEV advmss 4042

Modus für geteilte Kopfzeilen

Plattformen der dritten Generation bieten eine optionale Funktion zum Aufteilen von Empfangsheadern, die standardmäßig deaktiviert ist.

Beim Header-Split werden Paketheader und Daten in separate Puffer aufgeteilt. So kann eine gesamte Speicherseite mit 4.096 Byte Daten gefüllt werden. Diese Trennung ermöglicht wichtige Optimierungen, z. B. das Ersetzen von teuren Kopiervorgängen vom Kernel zum Userspace durch günstigere Vorgänge zum Zuordnen von Speicherseiten (z. B. mit TCP_ZEROCOPY_RECEIVE unter Linux).

Wenn die Funktion zum Aufteilen des Empfangsheaders aktiviert ist, ändert sich die MTU-Berechnung. Die optimale MTU ist eine, bei der alle Header dem Header-Puffer zugeordnet werden und der Nutzlastpuffer eine ganze Datenseite füllt. Wenn die Aufteilung der Kopfzeile aktiviert ist:

  • Ein Header-Puffer enthält:
    • Ethernet (14 Byte)
    • IPv4 (20 Byte)
    • TCP-Header (20 Byte)
    • Gängige TCP-Optionen (12 Byte für die Standardkonfiguration mit TCP-Zeitstempeln)
  • Der Datenpuffer enthält 4.096 Byte Nutzlastdaten.

Das ergibt eine Gesamt-Frame-Größe von 4.162 Byte und damit eine MTU von 4.148 Byte.

Nächste Schritte