TCP-Optimierung für höhere Netzwerkleistung

Das globale Netzwerk in Cloud de Confiance bietet hohe Zuverlässigkeit und niedrige Latenz, indem es Anwendungen über Regionen und Zonen hinweg verbindet, ohne das Google-Netzwerk zu verlassen. Die Standardeinstellungen für Linux TCP/IP sind jedoch oft für lokale Umgebungen optimiert und können in der Cloud zu Leistungsengpässen führen.

Für die beste Leistung in Cloud de Confiance by S3NSverwenden 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 der Cloud de Confiance 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. Dadurch werden moderne Hochgeschwindigkeitsnetzwerke oft nicht ausreichend genutzt, da der Sender 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, ersetzen Sie eth0 durch die primäre Netzwerkschnittstelle für Ihre Compute Engine-Instanz.

# 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 Paketverlusten durch Reduzierung der Verzögerungen bei der erneuten Übertragung.

Das TCP-Zeitlimit für die erneute Übertragung (Retransmission Timeout, RTO) steuert, wie lange ein TCP-Sender auf ein ACK-Signal wartet, bevor er die Daten noch einmal sendet. Linux initialisiert das RTO auf eine Sekunde (gemäß RFC 6298, Abschnitt 2.1) und passt es dann im Laufe der Zeit an die Umlaufzeit (Round Trip Time, RTT) zuzüglich einer Sicherheitsmarge an.

Das Minimum RTO (MinRTO) implementiert eine Untergrenze für diese Anpassung. Wenn die RTO-Schätzung zu niedrig ist, kann es zu unnötigen erneuten Übertragungen kommen, bei denen der Sender Pakete noch einmal sendet, während die Antwort noch verarbeitet wird.

Das Standard-MinRTO beträgt 200 ms, was für moderne Cloud-Netzwerke unnötig konservativ ist. Ein Wert von 5 ms wurde inausgiebig getestet in Cloud de Confiance und ist ein sicherer Standardwert für Verbindungen zwischen modernen Linux-Servern in Cloud de Confiance.

Ein weiterer Faktor sind verzögerte ACKs, 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 das Reduzieren des MinRTO wird die Wiederherstellung nach Verlusten bei Verbindungen mit niedriger RTT beschleunigt, z. B. bei Verbindungen innerhalb einer Zone oder Region. Diese Anpassung hat keine Auswirkungen auf das Verhalten bei Verbindungen mit einer hohen RTT, da sich die geschätzte RTT nicht ändert.

MinRTO konfigurieren

Sie können MinRTO mit einer von zwei Methoden konfigurieren:

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

    Sie können das Standard-MinRTO mit einem sysctl-Befehl konfigurieren:

    sysctl -w net.ipv4.tcp_rto_min_us=5000

  2. Mit ip route (pro Route oder für Linux-Versionen vor 6.11):

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

    ip route change default rto_min 5ms

Der Ansatz pro Route ist in Umgebungen vorzuziehen, in denen Verbindungen verlassen Cloud de Confiance oder mit Nicht-Linux-TCP/IP-Stacks kommunizieren. Diese Systeme haben möglicherweise unterschiedliche verzögerte ACK-Timer. Für eine breite öffentliche Internetbereitstellung, empfiehlt es sich, die konservative Standardeinstellung für MinRTO beizubehalten und die 5 ms Einstellung nur für Routen innerhalb der Cloud de Confiance Virtual Private Cloud (VPC) anzuwenden.

Fair Queueing aktivieren

Überlastung und Paketverluste aufgrund von Anwendungsspitzen minimieren.

Im Gegensatz zu Standard-FIFO-Warteschlangen (First-In, First-Out) verteilt Fair Queueing (FQ) die Bandbreite gleichmäßig auf verschiedene Datenflüsse. Außerdem wird der Traffic begrenzt, indem jede TCP-Verbindung ihre optimale Übertragungsrate und -zeit für jedes Paket berechnet. Wenn FQ vorhanden ist, hält der TCP-Stack Pakete so lange zurück, bis die optimale Übertragungszeit erreicht ist. Diese Begrenzung reduziert Spitzen innerhalb eines Datenflusses, was wiederum Paketverluste und erneute Übertragungen minimiert.

Verwenden Sie den folgenden tc-Befehl (Traffic Control), um den FQ-Traffic-Shaper als Traffic-Shaper für das Netzwerkgerät festzulegen:

tc qdisc replace dev $DEV root fq

Auf großen Instanzen mit hoher ausgehender Bandbreite hat das Netzwerkgerät möglicherweise mehrere Übertragungswarteschlangen. Für diese Instanzen ist es möglicherweise besser, die Traffic-Begrenzung auf die Übertragungswarteschlangen zu verteilen, indem Sie den Multi Queue (MQ)-Traffic-Shaper installieren. Dies ist ein Multiplexer, der jeder Übertragungswarteschlange einen unabhängigen Traffic-Shaper zuweist. Traffic-Shaper pro Warteschlange reduzieren die Konflikte bei Sperren und Cache-Lines über mehrere CPUs hinweg.

Slow Start nach Inaktivität deaktivieren

Hohe Übertragungsraten beibehalten, nachdem eine Verbindung inaktiv war.

Um Überlastung zu vermeiden, senden TCP-Verbindungen Daten zunächst mit einer niedrigen Rate und erhöhen die Rate dann exponentiell, bis ein Paketverlust erkannt wird. Diese Anfangsphase wird als Slow Start bezeichnet.

Standardmäßig kehrt TCP nach einer Inaktivitätsphase zu konservativen „Slow Start“-Einstellungen zurück. Eine Inaktivitätsphase kann so kurz wie ein Zeitlimit für die erneute Übertragung (RTO) sein, wie in RFC 2581 definiert. Wenn Sie diese Funktion deaktivieren, kann die Verbindung sofort mit der zuletzt bekannten guten Rate fortgesetzt werden.

Wenn möglich, sollten Anwendungen langlebige Verbindungen anstelle wiederholter Verbindungsaufbauten zum selben Peer verwenden. So werden die Kosten für den Verbindungsaufbau vermieden und die Informationen zur Überlastung beibehalten. Auch bei langlebigen Verbindungen vergisst TCP nach einer Inaktivitätsphase standardmäßig die 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 „Slow 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 Sie falsch positive Überlastungssignale ignorieren.

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

  • RTT-Verzögerung (Round Trip Time): Misst die Ausbreitungsverzögerung von Paketen im Netzwerk. Bei Netzwerküberlastung bilden sich an Engstellen in der Verbindung Paketwarteschlangen. Dadurch erhöht sich die RTT, was auf eine Überlastung hinweisen kann.
  • ACK-Abstand: Verwendet Signale, dass Pakete an einer Engstelle verzögert werden, konzentriert sich aber auf die Antwort-ACKs. Dieser Mechanismus geht davon aus, dass ACKs ohne Überlastung mit demselben Abstand wie die ursprünglichen Datenpakete eintreffen. Dieses Muster wird oft als ACK-Train bezeichnet. Wenn sich ACKs über dieses erwartete Muster hinaus verzögern, kann dies auf eine Überlastung hindeuten.

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

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

Socket-Arbeitsspeicherbudgets erhöhen

Den maximalen Durchsatz bei Verbindungen mit hoher RTT erhöhen, indem mehr Daten während der Übertragung zugelassen werden.

Die Menge der Daten während der Übertragung ist eine Funktion der Bandbreite und der Ausbreitungsverzögerung, 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 während der Übertragung müssen auf dem Sender gepuffert bleiben, falls sie noch einmal gesendet werden müssen. Die TCP-Socket-Arbeitsspeicherlimits können den erreichbaren Durchsatz direkt begrenzen, indem sie festlegen, wie viele Daten während der Übertragung gepuffert werden können.

Unter 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 vorhanden, um zu vermeiden, dass der gesamte Systemspeicher belegt wird und es zu Fehlern aufgrund mangelnden Arbeitsspeichers (Out-of-Memory, OOM) kommt, insbesondere bei Arbeitslasten mit vielen Verbindungen. Durch das Erhöhen dieser Limits kann der Durchsatz insbesondere bei Verbindungen mit hoher RTT gesteigert werden. Sofern die Anzahl der Verbindungen nicht in die Millionen geht, besteht nur ein geringes 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 Arbeitsspeicherzuweisung. Das Erhöhen dieser Werte hat keine Auswirkungen auf die tatsächliche Arbeitsspeicherzuweisung für Verbindungen mit niedriger RTT, z. B. innerhalb einer Cloud de Confiance Zone.

Die ersten beiden anpassbaren Parameter beeinflussen die maximale TCP-Fenstergröße für Anwendungen, die die TCP-Fenstergröße direkt festlegen. Das tun jedoch relativ wenige Anwendungen. Diese Limits begrenzen, was eine Anwendung mit den Socket-Optionen SO_RCVBUF und SO_SNDBUF explizit anfordern kann.

Für Linux-Kernel-Versionen 6.18 und höher sind net.core.rmem_max und net.core.wmem_max standardmäßig auf 4 MB festgelegt. Basierend auf jahrelanger Erfahrung gelten diese Einstellungen als sicher. Für frühere Linux-Versionen empfehlen wir, diese Limits 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 Limits, net.ipv4.tcp_rmem und net.ipv4.tcp_wmem, verwaltet die Limits für die automatische Anpassung des TCP-Sende- und ‑Empfangspuffers.

Jede dieser Einstellungen hat drei Werte: minimale, anfängliche Standard- und maximale Socket-Arbeitsspeichergröße. Die Standardmaximalwerte sind auf modernen Plattformen oft konservativer als nötig, 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 Schätzungen der RTT und des Überlastungsfensters an. 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 begrenzt diese Einstellung den Durchsatz im besten Fall auf 40 MB/s. Anstatt zu versuchen, die richtigen Werte zu berechnen, ist es einfacher, sichere Standardwerte für moderne Server mit vielen GB 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 wurden. Ziel der Erhöhung des maximalen wmem ist es, mehr Daten während der Übertragung zuzulassen. Ein Prozess kann jedoch schneller in den Socket schreiben, als TCP sie senden kann. Dadurch entsteht auf dem Host eine Warteschlange mit nicht gesendeten Daten, die Arbeitsspeicher belegt. 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 Puffer während der Übertragung zu ermöglichen.

Sofern ein Server nicht Millionen von Verbindungen hat, sollten die folgenden Einstellungen sicher sein. Wenn es jedoch bei vielen Verbindungen zu Fehlern aufgrund mangelnden Arbeitsspeichers kommt, verwenden Sie eine niedrigere maximale Puffergröße.

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 Datenflüsse erhöhen. CPU-Overhead durch Batching empfangener Pakete reduzieren

Bei den meisten TCP/IP-Vorgängen skaliert der CPU-Zykluskosten mit der Paketrate, nicht mit der Byterate. Um diesen Overhead bei der Übertragung zu reduzieren, 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 erfordert die Unterstützung des Netzwerkgeräts, um diese Pakete aufzuteilen und als Reihe kleinerer Pakete zu senden, 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 höher das Gegenteil tun: Sie puffern Segmente kurz im Gerät, um zu sehen, ob aufeinanderfolgende Segmente eintreffen. Wenn ja, werden sie kombiniert und als Pakete mit mehreren Segmenten an den Host weitergeleitet. Diese Funktion wird unter Windows als Receive Segment Coalescing (RSC) und unter 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. Dies geschieht gegebenenfalls automatisch.

Aktivieren Sie HW-GRO in der Zwischenzeit auf Plattformen mit GVNIC-Geräten, die die Funktion unterstützen, mit ethtool. Je nach Kernel- und Treiberversion wird die Funktion als LRO oder HW-GRO beworben. Die Implementierung ist unabhängig vom Namen.

    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 Datenflüsse mit hohem Durchsatz erhöhen.

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

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

Überlegungen zur optimalen Paketgröße

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

  • Arbeitsspeichernutzung: Größere Puffer erfordern mehr Arbeitsspeicher, der dem Netzwerk gerät für den Paketempfang zugewiesen wird. Wenn Sie viele Warteschlangen haben, kann eine erhebliche Menge an Arbeitsspeicher ungenutzt bleiben.
  • Verarbeitung kleiner Pakete: Größere Puffer verarbeiten kleine Pakete, z. B. reine Bestätigungen (ACKs), weniger effizient.
  • Kosten für die CPU-Zuweisung: Die Kosten für den Datenpfad werden erheblich durch die Arbeitsspeicherzuweisung und ‑freigabe beeinflusst. Wenn Sie die Paketgröße an ein Vielfaches der Arbeitsspeicherseiten anpassen, können Sie diese CPU-Kosten optimieren.
  • TSO-Interaktion: Die Paketgröße wirkt sich geringfügig auf TCP Segmentation Offload (TSO) aus. Um das größtmögliche TSO-Paket zu erstellen, müssen Sie möglicherweise eine kleinere maximale Segmentgröße (Maximum Segment Size, MSS) auswählen. Bei dem größtmöglichen IP-Paket von 64 KB einschließlich Headern ergibt eine MSS von 4 KB beispielsweise eine größere Nutzlast (60 KB) als eine MSS von 8 KB (56 KB).

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

Empfehlung für Pakete in Seitengröße

Als robuste und im Allgemeinen 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 4.096-Byte-Arbeitsspeicherseite passt, was die Zuweisung von Arbeitsspeicherseiten optimiert. Diese Empfehlung gilt für die Layer-3-MTU, die den IP-Header enthält, aber die 14-Byte-Ethernet-Verbindungsschicht ausschließt.

IP-MTU-Konfiguration

Sie können die MTU für jedes VPC-Netzwerk direkt über die Cloud de Confiance Console konfigurieren.

Bei den meisten Linux-Distributionen in Cloud de Confianceist keine manuelle Konfiguration erforderlich auf der Compute-Instanz. Die Instanz ermittelt die Netzwerk-MTU beim Booten automatisch über DHCP (mit Option 26). Anschließend wird die MTU des Netzwerkgeräts entsprechend festgelegt. 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 Pfad-MTU möglicherweise niedriger ist, ist das Festlegen der MTU auf bestimmten Routen die bevorzugte Option. 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 Routen innerhalb der VPC 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

TCP Maximum Segment Size (MSS) konfigurieren

Die TCP Maximum Segment Size (MSS) bestimmt die Paketnutzlastgröße 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.

Die MSS umfasst die Nutzlast und die TCP-Optionen, nicht jedoch den 20-Byte-IPv4-Header und den 20-Byte-TCP-Header. In einem IPv4-Netzwerk ist die MSS daher in der Regel 40 Byte kleiner als die MTU.

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

ip -4 route change default dev $DEV advmss 4042

Header-Split-Modus

Der gve-Treiber von gVNIC in Linux-Kernel-Versionen 6.9 und höher unterstützt die Aufteilung von TCP-Headern und ‑Daten (tcp-data-split), die standardmäßig deaktiviert ist.

Bei der Header-Aufteilung werden Paketheader und ‑daten in separate Puffer aufgeteilt. So kann eine gesamte Arbeitsspeicherseite mit 4.096 Byte Daten gefüllt werden. Diese Trennung ermöglicht wichtige Optimierungen, z. B. das Ersetzen teurer Kopieraktionen vom Kernel- in den Nutzerbereich durch günstigere Arbeitsspeicherseiten-Zuordnungsaktionen (z. B. mit Linux TCP_ZEROCOPY_RECEIVE).

Wenn die Funktion zur Aufteilung des Empfangs-Headers 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 Header-Aufteilung aktiviert ist:

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

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

Nächste Schritte