.. Titel: System Buffer Tuning – TCP- und Netzwerkleistungsoptimierung
.. Slug: System-Puffer-Tuning
.. Datum: 2026-02-02 10:00:00 UTC
.. Tags: Netzwerk, Leistung, Optimierung, TCP, Puffer
.. Kategorie: Artikel
.. Link:
.. Beschreibung: Systempuffer verstehen und optimieren, um TCP-Leistungsprobleme zu lösen, die oft fälschlicherweise als Netzwerkprobleme diagnostiziert werden
.. Typ: Text
<style>
.buffer-table {
    width: 100%;
    border-collapse: collapse;
    margin: 20px 0;
}
.buffer-table th, .buffer-table td {
    border: 1px solid #ddd;
    padding: 12px;
    text-align: left;
}
.buffer-table th {
    background-color: #4CAF50;
    color: white;
}
.buffer-table tr:nth-child(even) {
    background-color: #f2f2f2;
}
.os-section {
    margin: 30px 0;
    padding: 20px;
    border-left: 4px solid #4CAF50;
    background-color: #f9f9f9;
}
.warning-box {
    background-color: #fff3cd;
    border-left: 4px solid #ffc107;
    padding: 15px;
    margin: 20px 0;
}
.diagnostic-box {
    background-color: #e7f3ff;
    border-left: 4px solid #2196F3;
    padding: 15px;
    margin: 20px 0;
}
code {
    background-color: #f4f4f4;
    padding: 2px 6px;
    border-radius: 3px;
    font-family: 'Courier New', monospace;
}
pre {
    background-color: #f4f4f4;
    padding: 15px;
    border-radius: 5px;
    overflow-x: auto;
}
</style>
<h1>Systempufferoptimierung: Der versteckte Übeltäter hinter „Netzwerkproblemen“</h1>
<h2>Zusammenfassung</h2>
<p>Netzwerktechniker stoßen häufig auf Situationen, in denen TCP-Windowing oder Anwendungsleistung auf die Netzwerkinfrastruktur zurückzuführen sind. Nach umfangreichen Paketerfassungen, TCP-Dumps und Netzwerkanalysen wird häufig der wahre Engpass entdeckt: erschöpfte NIC- (Network Interface Card) oder Puffer auf Betriebssystemebene auf den Client- oder Serversystemen.</p>
<p>Dieser Artikel stellt sowohl ältere (ca. 2009) als auch aktuelle (2025–2026) Pufferkonfigurationen für Linux, Windows und macOS sowie Diagnosetechniken vor, um die Pufferauslastung zu erkennen, bevor sie zu einem kritischen Problem wird.</p>
<div class="diagnostic-box">
<h3>Häufige Symptome einer Puffererschöpfung</h3>
<ul>
<li>TCP Zero Window-Ereignisse in Paketerfassungen</li>
<li>Hohe Neuübertragungsraten trotz geringer Netzwerklatenz</li>
<li>Der Anwendungsdurchsatz liegt deutlich unter der verfügbaren Bandbreite</li>
<li>Leistungsabfall unter Last, der sich verbessert, wenn die Last abnimmt</li>
<li>Inkonsistente Leistung bei ähnlichen Hardwarekonfigurationen</li>
<li>Socket-Fehler oder Meldungen „Ressource vorübergehend nicht verfügbar“.</li>
</ul>
</div>
<h2>Das Problem verstehen</h2>
<h3>Der TCP-Fensterskalierungsmechanismus</h3>
<p>TCP verwendet einen Flusskontrollmechanismus, bei dem der Empfänger eine „Fenstergröße“ angibt, die angibt, wie viele Daten er akzeptieren kann. Wenn die Systempuffer voll sind, schrumpft dieses Fenster auf Null, was den Absender zum Warten zwingt. Dies scheint ein Netzwerkproblem zu sein, in Wirklichkeit handelt es sich jedoch um ein Problem mit den Hostressourcen.</p>
<h3>Wo Puffer wichtig sind</h3>
<ul>
<li><strong>Socket-Puffer (SO_SNDBUF/SO_RCVBUF):</strong>Sende- und Empfangspuffer pro Socket</li>
<li><strong>TCP-Fensterpuffer:</strong>Maximale TCP-Fenstergröße für Verbindungen</li>
<li><strong>Netzwerkgerätepuffer:</strong>NIC-Ringpuffer für die Paketwarteschlange</li>
<li><strong>Systemweiter Speicher:</strong>Gesamtspeicher, der für das Netzwerk reserviert ist</li>
</ul>
<h2>Diagnosebefehle</h2>
<div class="diagnostic-box">
<h3>Linux-Diagnose</h3>
<pre>
# Check current TCP buffer settings
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
sysctl net.core.rmem_max
sysctl net.core.wmem_max

# Check NIC ring buffer sizes
ethtool -g eth0

# Monitor socket buffer usage
ss -tm

# Check for TCP zero window events
tcpdump -i any 'tcp[tcpflags] &amp; tcp-push != 0' -vv

# Check network statistics for buffer issues
netstat -s | grep -i "buffer\|queue\|drop"
</pre>
<h3>Windows-Diagnose</h3>
<pre>
# Check TCP parameters
netsh interface tcp show global

# View network adapter buffer settings
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object {$_.DisplayName -like "*buffer*"}

# Monitor TCP statistics
netstat -s -p tcp

# Check receive window auto-tuning
netsh interface tcp show global | findstr "Receive Window"
</pre>
<h3>macOS-Diagnose</h3>
<pre>
# Check current buffer settings
sysctl kern.ipc.maxsockbuf
sysctl net.inet.tcp.sendspace
sysctl net.inet.tcp.recvspace

# View network statistics
netstat -s -p tcp

# Monitor socket buffers
netstat -an -p tcp
</pre>
</div>
<h2>Linux-Pufferoptimierung</h2>
<div class="os-section">
<h3>Ältere Linux-Einstellungen (ca. 2009)</h3>
<table class="buffer-table">
<tr>
<th>Parameter</th>
<th>Legacy Value (2009)</th>
<th>Beschreibung</th>
</tr>
<tr>
<td>net.core.rmem_default</td>
<td>124928 (122 KB)</td>
<td>Standardgröße des Empfangs-Socket-Puffers</td>
</tr>
<tr>
<td>net.core.rmem_max</td>
<td>131071 (128 KB)</td>
<td>Maximale Größe des Empfangs-Socket-Puffers</td>
</tr>
<tr>
<td>net.core.wmem_default</td>
<td>124928 (122 KB)</td>
<td>Standardgröße des Sende-Socket-Puffers</td>
</tr>
<tr>
<td>net.core.wmem_max</td>
<td>131071 (128 KB)</td>
<td>Maximale Größe des Sende-Socket-Puffers</td>
</tr>
<tr>
<td>net.ipv4.tcp_rmem</td>
<td>4096 87380 174760</td>
<td>TCP-Empfangspuffer: Min., Standard, Max. (in Bytes)</td>
</tr>
<tr>
<td>net.ipv4.tcp_wmem</td>
<td>4096 16384 131072</td>
<td>TCP-Sendepuffer: Min., Standard, Max. (in Bytes)</td>
</tr>
<tr>
<td>net.ipv4.tcp_mem</td>
<td>196608 262144 393216</td>
<td>TCP-Speicherseiten: niedrig, Druck, hoch</td>
</tr>
<tr>
<td>net.core.netdev_max_backlog</td>
<td>1000</td>
<td>Maximale Pakete in der Eingabewarteschlange</td>
</tr>
<tr>
<td>net.core.optmem_max</td>
<td>10240 (10 KB)</td>
<td>Maximale zusätzliche Puffergröße pro Socket</td>
</tr>
</table>
<h3>Aktuelle Linux-Einstellungen (2025–2026)</h3>
<table class="buffer-table">
<tr>
<th>Parameter</th>
<th>Aktueller empfohlener Wert</th>
<th>Beschreibung</th>
</tr>
<tr>
<td>net.core.rmem_default</td>
<td>16777216 (16 MB)</td>
<td>Standardgröße des Empfangs-Socket-Puffers</td>
</tr>
<tr>
<td>net.core.rmem_max</td>
<td>134217728 (128 MB)</td>
<td>Maximale Größe des Empfangs-Socket-Puffers</td>
</tr>
<tr>
<td>net.core.wmem_default</td>
<td>16777216 (16 MB)</td>
<td>Standardgröße des Sende-Socket-Puffers</td>
</tr>
<tr>
<td>net.core.wmem_max</td>
<td>134217728 (128 MB)</td>
<td>Maximale Größe des Sende-Socket-Puffers</td>
</tr>
<tr>
<td>net.ipv4.tcp_rmem</td>
<td>4096 87380 134217728</td>
<td>TCP-Empfangspuffer: Min., Standard, Max. (max. 128 MB)</td>
</tr>
<tr>
<td>net.ipv4.tcp_wmem</td>
<td>4096 65536 134217728</td>
<td>TCP-Sendepuffer: Min., Standard, Max. (max. 128 MB)</td>
</tr>
<tr>
<td>net.ipv4.tcp_mem</td>
<td>8388608 12582912 16777216</td>
<td>TCP-Speicherseiten: niedrig, Druck, hoch (64-GB-System)</td>
</tr>
<tr>
<td>net.core.netdev_max_backlog</td>
<td>250000</td>
<td>Maximale Pakete in der Eingabewarteschlange (10GbE+)</td>
</tr>
<tr>
<td>net.core.optmem_max</td>
<td>65536 (64 KB)</td>
<td>Maximale zusätzliche Puffergröße pro Socket</td>
</tr>
<tr>
<td>net.ipv4.tcp_congestion_control</td>
<td>bbr</td>
<td>Verwenden Sie die BBR-Überlastungskontrolle (Googles Algorithmus).</td>
</tr>
<tr>
<td>net.ipv4.tcp_window_scaling</td>
<td>1</td>
<td>TCP-Fensterskalierung aktivieren (RFC 1323)</td>
</tr>
<tr>
<td>net.ipv4.tcp_timestamps</td>
<td>1</td>
<td>Aktivieren Sie TCP-Zeitstempel für eine bessere RTT-Schätzung</td>
</tr>
<tr>
<td>net.ipv4.tcp_sack</td>
<td>1</td>
<td>Aktivieren Sie die selektive Bestätigung</td>
</tr>
<tr>
<td>net.ipv4.tcp_no_metrics_save</td>
<td>1</td>
<td>Deaktivieren Sie das Caching von TCP-Metriken</td>
</tr>
</table>
<h3>Linux-Konfigurationsanwendung</h3>
<p>Fügen Sie diese Einstellungen hinzu<code>/etc/sysctl.conf</code>oder eine neue Datei erstellen<code>/etc/sysctl.d/99-network-tuning.conf</code>:</p>
<pre>
# Network Buffer Tuning for High-Performance Applications
# Optimized for 10GbE+ networks with RTT up to 300ms

# Core socket buffer settings
net.core.rmem_default = 16777216
net.core.rmem_max = 134217728
net.core.wmem_default = 16777216
net.core.wmem_max = 134217728

# TCP buffer settings
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_mem = 8388608 12582912 16777216

# Device buffer settings
net.core.netdev_max_backlog = 250000
net.core.netdev_budget = 50000
net.core.netdev_budget_usecs = 5000
net.core.optmem_max = 65536

# TCP optimizations
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1

# Apply with: sysctl -p /etc/sysctl.d/99-network-tuning.conf
</pre>
<h3>NIC-Ringpuffer-Tuning</h3>
<pre>
# Check current ring buffer sizes
ethtool -g eth0

# Set maximum ring buffer sizes (adjust based on NIC capabilities)
ethtool -G eth0 rx 4096 tx 4096

# Make persistent by adding to /etc/network/interfaces or systemd service
</pre>
<div class="warning-box">
<strong>Kritische Warnung – Speicherverbrauch:</strong>Die tcp_mem-Werte befinden sich in Speicherseiten (normalerweise 4 KB). Große Puffergrößen können zu einer starken Speicherbelastung führen:<ul>
<li><strong>Speicher pro Verbindung:</strong>Jede Verbindung kann bis zu rmem_max + wmem_max (256 MB mit 128 MB Puffern) verwenden.</li>
<li><strong>Gesamtauswirkungen auf das System:</strong>1.000 Verbindungen × 256 MB = 256 GB potenzielle Nutzung</li>
<li><strong>Sichere Schätzung:</strong>Die maximalen gleichzeitigen Verbindungen × 256 MB sollten 50 % des System-RAM nicht überschreiten</li>
<li><strong>Beispiel:</strong>Ein 64-GB-Server sollte die maximale Anzahl an Verbindungen auf etwa 125 gleichzeitige Verbindungen mit hohem Durchsatz und 128-MB-Puffer beschränken</li>
<li><strong>Empfehlung für Server mit &lt;16GB RAM:</strong>Reduzieren Sie die Puffer auf maximal 16–32 MB und passen Sie tcp_mem proportional an</li>
</ul>
</div>
</div>
<h2>Windows-Pufferoptimierung</h2>
<div class="os-section">
<h3>Ältere Windows-Einstellungen (ca. 2009 – Windows Vista/7/Server 2008)</h3>
<table class="buffer-table">
<tr>
<th>Parameter</th>
<th>Legacy Value (2009)</th>
<th>Standort</th>
</tr>
<tr>
<td>TcpWindowSize</td>
<td>65535 (64 KB)</td>
<td>Registrierung: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters</td>
</tr>
<tr>
<td>Tcp1323Opts</td>
<td>0 (deaktiviert)</td>
<td>Die Fensterskalierung ist standardmäßig deaktiviert</td>
</tr>
<tr>
<td>DefaultReceiveWindow</td>
<td>8192 (8 KB)</td>
<td>Standard-Empfangsfenster</td>
</tr>
<tr>
<td>DefaultSendWindow</td>
<td>8192 (8 KB)</td>
<td>Standard-Sendefenster</td>
</tr>
<tr>
<td>GlobalMaxTcpWindowSize</td>
<td>65535 (64 KB)</td>
<td>Maximale TCP-Fenstergröße</td>
</tr>
<tr>
<td>TcpNumConnections</td>
<td>16777214</td>
<td>Maximale TCP-Verbindungen</td>
</tr>
</table>
<h3>Aktuelle Windows-Einstellungen (Windows 10/11/Server 2019–2025)</h3>
<p>Modernes Windows verwendet das<strong>Fenster-Autotuning empfangen</strong>Funktion, die Empfangspuffer basierend auf den Netzwerkbedingungen dynamisch anpasst.</p>
<table class="buffer-table">
<tr>
<th>Besonderheit</th>
<th>Aktuelle empfohlene Einstellung</th>
<th>Beschreibung</th>
</tr>
<tr>
<td>Auto-Tuning-Ebene</td>
<td>normal (oder sehr experimentell für 10GbE+)</td>
<td>Dynamische Anpassung des Empfangsfensters</td>
</tr>
<tr>
<td>Empfangsseitige Skalierung (RSS)</td>
<td>ermöglicht</td>
<td>Verteilen Sie die Netzwerkverarbeitung auf CPUs</td>
</tr>
<tr>
<td>Schornsteinentladung</td>
<td>automatisch (oder auf modernen Netzwerkkarten deaktiviert)</td>
<td>TCP-Offload auf NIC-Hardware</td>
</tr>
<tr>
<td>NetDMA</td>
<td>deaktiviert</td>
<td>Direkter Speicherzugriff (veraltet)</td>
</tr>
<tr>
<td>Globale TCP-Parameter</td>
<td>Siehe Befehle unten</td>
<td>Systemweite TCP-Einstellungen</td>
</tr>
<tr>
<td>Überlastungsanbieter</td>
<td>CUBIC (oder NewReno-Fallback)</td>
<td>Algorithmus zur TCP-Überlastungskontrolle</td>
</tr>
</table>
<h3>Windows-Konfigurationsbefehle</h3>
<pre>
# Check current auto-tuning level
netsh interface tcp show global

# Enable auto-tuning (normal mode - default for most scenarios)
netsh interface tcp set global autotuninglevel=normal

# For high-bandwidth, high-latency networks (10GbE+, data center environments)
netsh interface tcp set global autotuninglevel=experimental

# For conservative tuning (if experimental causes issues)
netsh interface tcp set global autotuninglevel=restricted

# For very conservative tuning (not recommended for high-performance networks)
netsh interface tcp set global autotuninglevel=highlyrestricted

# Enable CUBIC congestion provider (Windows Server 2022/Windows 11+ only)
netsh interface tcp set supplemental template=Internet congestionprovider=cubic

# Note: Windows 10 and Server 2019 use Compound TCP or NewReno by default
# CUBIC is not available on these older versions

# Enable Receive-Side Scaling (RSS)
netsh interface tcp set global rss=enabled

# Set chimney offload (automatic is recommended)
netsh interface tcp set global chimney=automatic

# Disable NetDMA (recommended for modern systems)
netsh interface tcp set global netdma=disabled

# Enable Direct Cache Access (if supported)
netsh interface tcp set global dca=enabled

# Enable ECN (Explicit Congestion Notification)
netsh interface tcp set global ecncapability=enabled

# Set initial congestion window to 10 (RFC 6928)
netsh interface tcp set global initialRto=3000
</pre>
<h3>Erweiterte NIC-Puffereinstellungen (über Geräte-Manager oder PowerShell)</h3>
<pre>
# View current adapter settings
Get-NetAdapterAdvancedProperty -Name "Ethernet"

# Increase receive buffers (adjust based on NIC)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue 2048

# Increase transmit buffers
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Transmit Buffers" -DisplayValue 2048

# Enable Jumbo Frames (if network supports it)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Jumbo Packet" -DisplayValue 9014

# Enable Large Send Offload (LSO)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload V2 (IPv4)" -DisplayValue Enabled
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload V2 (IPv6)" -DisplayValue Enabled
</pre>
<h3>Registrierungsoptimierungen (Erweitert – mit Vorsicht verwenden)</h3>
<pre>
# These settings are typically NOT needed on Windows 10/11 due to auto-tuning
# Only modify if auto-tuning is disabled or problematic

# Registry path: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

# Maximum TCP window size (if auto-tuning disabled)
# TcpWindowSize = 16777216 (16MB) - REG_DWORD

# Enable window scaling (enabled by default on modern Windows)
# Tcp1323Opts = 3 - REG_DWORD

# Number of TCP Timed Wait Delay
# TcpTimedWaitDelay = 30 - REG_DWORD (default 240)
</pre>
<div class="warning-box">
<strong>Warnung:</strong>Vermeiden Sie unter modernem Windows (10/11/Server 2019+) manuelle Registrierungsänderungen, es sei denn, die automatische Optimierung verursacht Probleme. Die Auto-Tuning-Algorithmen sind im Allgemeinen den statischen Einstellungen überlegen.</div>
</div>
<h2>macOS-Pufferoptimierung</h2>
<div class="os-section">
<h3>Ältere macOS-Einstellungen (ca. 2009 – Mac OS X 10.5/10.6)</h3>
<table class="buffer-table">
<tr>
<th>Parameter</th>
<th>Legacy Value (2009)</th>
<th>Beschreibung</th>
</tr>
<tr>
<td>kern.ipc.maxsockbuf</td>
<td>262144 (256 KB)</td>
<td>Maximale Socket-Puffergröße</td>
</tr>
<tr>
<td>net.inet.tcp.sendspace</td>
<td>32768 (32 KB)</td>
<td>Standard-TCP-Sendepuffer</td>
</tr>
<tr>
<td>net.inet.tcp.recvspace</td>
<td>32768 (32 KB)</td>
<td>Standard-TCP-Empfangspuffer</td>
</tr>
<tr>
<td>net.inet.tcp.autorcvbufmax</td>
<td>131072 (128 KB)</td>
<td>Maximaler automatisch abgestimmter Empfangspuffer</td>
</tr>
<tr>
<td>net.inet.tcp.autosndbufmax</td>
<td>131072 (128 KB)</td>
<td>Maximaler automatisch abgestimmter Sendepuffer</td>
</tr>
<tr>
<td>net.inet.tcp.rfc1323</td>
<td>0 (deaktiviert)</td>
<td>TCP-Fensterskalierung</td>
</tr>
</table>
<h3>Aktuelle macOS-Einstellungen (macOS 12–15 Monterey bis Sequoia)</h3>
<table class="buffer-table">
<tr>
<th>Parameter</th>
<th>Aktueller empfohlener Wert</th>
<th>Beschreibung</th>
</tr>
<tr>
<td>kern.ipc.maxsockbuf</td>
<td>8388608 (8 MB)</td>
<td>Maximale Socket-Puffergröße</td>
</tr>
<tr>
<td>net.inet.tcp.sendspace</td>
<td>131072 (128 KB)</td>
<td>Standard-TCP-Sendepuffer</td>
</tr>
<tr>
<td>net.inet.tcp.recvspace</td>
<td>131072 (128 KB)</td>
<td>Standard-TCP-Empfangspuffer</td>
</tr>
<tr>
<td>net.inet.tcp.autorcvbufmax</td>
<td>16777216 (16 MB)</td>
<td>Maximaler automatisch abgestimmter Empfangspuffer</td>
</tr>
<tr>
<td>net.inet.tcp.autosndbufmax</td>
<td>16777216 (16 MB)</td>
<td>Maximaler automatisch abgestimmter Sendepuffer</td>
</tr>
<tr>
<td>net.inet.tcp.rfc1323</td>
<td>1 (aktiviert)</td>
<td>Aktivieren Sie die TCP-Fensterskalierung</td>
</tr>
<tr>
<td>net.inet.tcp.sack</td>
<td>1 (aktiviert)</td>
<td>Aktivieren Sie die selektive Bestätigung</td>
</tr>
<tr>
<td>net.inet.tcp.mssdflt</td>
<td>1440</td>
<td>Standardmäßige maximale TCP-Segmentgröße</td>
</tr>
<tr>
<td>net.inet.tcp.delayed_ack</td>
<td>3</td>
<td>Verzögertes ACK-Verhalten</td>
</tr>
</table>
<h3>macOS-Konfigurationsanwendung</h3>
<pre>
# Check current settings
sysctl kern.ipc.maxsockbuf
sysctl net.inet.tcp.sendspace
sysctl net.inet.tcp.recvspace
sysctl net.inet.tcp.autorcvbufmax
sysctl net.inet.tcp.autosndbufmax

# Apply settings temporarily (until reboot)
sudo sysctl -w kern.ipc.maxsockbuf=8388608
sudo sysctl -w net.inet.tcp.sendspace=131072
sudo sysctl -w net.inet.tcp.recvspace=131072
sudo sysctl -w net.inet.tcp.autorcvbufmax=16777216
sudo sysctl -w net.inet.tcp.autosndbufmax=16777216
sudo sysctl -w net.inet.tcp.rfc1323=1
sudo sysctl -w net.inet.tcp.sack=1

# Make settings persistent (create /etc/sysctl.conf)
sudo tee /etc/sysctl.conf &lt;&lt;EOF
kern.ipc.maxsockbuf=8388608
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.inet.tcp.autorcvbufmax=16777216
net.inet.tcp.autosndbufmax=16777216
net.inet.tcp.rfc1323=1
net.inet.tcp.sack=1
net.inet.tcp.mssdflt=1440
net.inet.tcp.delayed_ack=3
EOF

# Note: On recent macOS versions, /etc/sysctl.conf may not be read automatically
# Use a LaunchDaemon to apply settings at boot
</pre>
<h3>Erstellen eines LaunchDaemon für persistente Einstellungen</h3>
<pre>
# Create /Library/LaunchDaemons/com.local.sysctl.plist
sudo tee /Library/LaunchDaemons/com.local.sysctl.plist &lt;&lt;EOF
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
&lt;plist version="1.0"&gt;
&lt;dict&gt;
    &lt;key&gt;Label&lt;/key&gt;
    &lt;string&gt;com.local.sysctl&lt;/string&gt;
    &lt;key&gt;ProgramArguments&lt;/key&gt;
    &lt;array&gt;
        &lt;string&gt;/usr/sbin/sysctl&lt;/string&gt;
        &lt;string&gt;-w&lt;/string&gt;
        &lt;string&gt;kern.ipc.maxsockbuf=8388608&lt;/string&gt;
    &lt;/array&gt;
    &lt;key&gt;RunAtLoad&lt;/key&gt;
    &lt;true/&gt;
&lt;/dict&gt;
&lt;/plist&gt;
EOF

sudo chmod 644 /Library/LaunchDaemons/com.local.sysctl.plist
sudo launchctl load /Library/LaunchDaemons/com.local.sysctl.plist
</pre>
<div class="warning-box">
<strong>Warnung:</strong>Für macOS Ventura (13) und höher gelten Einschränkungen für den Systemintegritätsschutz (SIP). Einige Kernel-Parameter können möglicherweise nicht einmal mit sudo geändert werden. Testen Sie die Einstellungen in Ihrer spezifischen Umgebung.</div>
</div>
<h2>Leistungstests und Validierung</h2>
<h3>Tools zum Testen der Pufferleistung</h3>
<div class="diagnostic-box">
<h4>iperf3 – Netzwerkleistungstests</h4>
<pre>
# Server side
iperf3 -s

# Client side - test TCP throughput
iperf3 -c server_ip -t 60 -i 5 -w 16M

# Test with multiple parallel streams
iperf3 -c server_ip -P 10 -t 60

# Test UDP performance
iperf3 -c server_ip -u -b 1000M -t 60
</pre>
<h4>tcpdump – TCP-Fenstergrößen erfassen</h4>
<pre>
# Capture and display TCP window sizes
tcpdump -i any -n 'tcp' -vv | grep -i window

# Save capture for Wireshark analysis
tcpdump -i any -w /tmp/capture.pcap 'tcp port 443'
</pre>
<h4>Wireshark-Analyse</h4>
<p>Suchen Sie nach diesen Indikatoren für Pufferprobleme:</p>
<ul>
<li>TCP Zero Window-Nachrichten</li>
<li>TCP-Fensteraktualisierungspakete</li>
<li>Benachrichtigungen über vollständige TCP-Fenster</li>
<li>Hohe Neuübertragungsraten bei niedrigem RTT</li>
</ul>
<h4>Systemüberwachung</h4>
<pre>
# Linux - Monitor network buffer statistics
watch -n 1 'cat /proc/net/sockstat'
watch -n 1 'ss -tm | grep -i mem'

# Check for drops
netstat -s | grep -i drop

# Windows - Monitor TCP statistics
netstat -e 1

# macOS - Monitor network statistics
netstat -s -p tcp
</pre>
</div>
<h2>Berechnung des Bandbreitenverzögerungsprodukts (BDP).</h2>
<p>Um optimale Puffergrößen für Ihr Netzwerk zu ermitteln, berechnen Sie das Bandbreiten-Verzögerungsprodukt:</p>
<pre>
BDP = Bandwidth (bits/sec) × RTT (seconds)

Example for 10 Gigabit Ethernet with 50ms RTT:
BDP = 10,000,000,000 × 0.050 = 500,000,000 bits = 62.5 MB

Buffer Size = BDP × 2 (for bidirectional traffic and headroom)
Buffer Size = 62.5 MB × 2 = 125 MB

This is why modern settings recommend 128MB maximum buffers.
</pre>
<h2>Workload-spezifische Empfehlungen</h2>
<table class="buffer-table">
<tr>
<th>Arbeitslasttyp</th>
<th>Empfohlene Puffergröße</th>
<th>Schlüsselparameter</th>
</tr>
<tr>
<td>Webserver (Geringe Latenz)</td>
<td>4-16 MB</td>
<td>Weniger Puffer, mehr Verbindungen, schnelle Reaktion</td>
</tr>
<tr>
<td>Datenbankserver</td>
<td>16-32 MB</td>
<td>Moderate Puffer, konsistenter Durchsatz</td>
</tr>
<tr>
<td>Dateiübertragung/Sicherung</td>
<td>64-128 MB</td>
<td>Maximale Puffer, hohe Durchsatzpriorität</td>
</tr>
<tr>
<td>Video-Streaming</td>
<td>32-64 MB</td>
<td>Große Puffer, konstante Lieferrate</td>
</tr>
<tr>
<td>HPC / Rechenzentrum</td>
<td>128-256 MB</td>
<td>Maximale Puffer, spezielle Überlastungskontrolle</td>
</tr>
<tr>
<td>Kabellos / Mobil</td>
<td>2-8 MB</td>
<td>Konservative Puffer, Handhabung variabler Latenz</td>
</tr>
</table>
<h2>Häufige Fehler und Fallstricke</h2>
<div class="warning-box">
<h3>Zu vermeidende Fehler</h3>
<ul>
<li><strong>Überpufferung:</strong>Zu große Puffer können zu einem Bufferbloat führen und die Latenz erhöhen</li>
<li><strong>Speicherbeschränkungen ignorieren:</strong>Große Puffer vervielfachen sich mit der Anzahl der Verbindungen; Ein Server mit 10.000 Verbindungen und 128 MB Puffern benötigt 1,25 TB RAM</li>
<li><strong>Autotuning ohne Angabe von Gründen deaktivieren:</strong>Die automatische Optimierung moderner Betriebssysteme ist normalerweise besser als statische Einstellungen</li>
<li><strong>Nach Änderungen nicht getestet:</strong>Validieren Sie Leistungsverbesserungen immer anhand realer Arbeitslasten</li>
<li><strong>NIC-Puffer vergessen:</strong>Die Erschöpfung des Ringpuffers kann unabhängig von den Socket-Puffer auftreten</li>
<li><strong>Inkonsistente Einstellungen:</strong>Client und Server sollten kompatible Pufferkonfigurationen haben</li>
<li><strong>Staukontrolle ignorieren:</strong>BBR und CUBIC sind deutlich besser als ältere Algorithmen</li>
</ul>
</div>
<h2>Fehlerbehebungs-Workflow</h2>
<ol>
<li><strong>Basislinie festlegen:</strong>Messen Sie die aktuelle Leistung mit iperf3 oder ähnlichen Tools</li>
<li><strong>Pakete erfassen:</strong>Verwenden Sie tcpdump/Wireshark, um das TCP-Fensterverhalten zu identifizieren</li>
<li><strong>Systemstatistiken prüfen:</strong>Suchen Sie nach Ausfällen, Puffererschöpfung und erneuten Übertragungen</li>
<li><strong>BDP berechnen:</strong>Bestimmen Sie theoretisch optimale Puffergrößen</li>
<li><strong>Inkrementelle Änderungen anwenden:</strong>Ändern Sie nicht alles auf einmal</li>
<li><strong>Testen und validieren:</strong>Messen Sie die tatsächliche Leistungsverbesserung</li>
<li><strong>Überwachen Sie im Laufe der Zeit:</strong>Stellen Sie sicher, dass die Einstellungen bei unterschiedlichen Belastungen optimal bleiben</li>
</ol>
<h2>Referenzen und weiterführende Literatur</h2>
<ul>
<li>RFC 1323 – TCP-Erweiterungen für hohe Leistung (Fensterskalierung)</li>
<li>RFC 2018 – Optionen für selektive TCP-Bestätigung</li>
<li>RFC 6928 – Erhöhung des anfänglichen TCP-Fensters</li>
<li>RFC 8312 – CUBIC-Algorithmus zur Überlastungskontrolle</li>
<li>BBR-Überlastungskontrolle (Google) – https://research.google/pubs/pub45646/</li>
<li>Linux-Kernel-Dokumentation – networking/ip-sysctl.txt</li>
<li>Leitfaden zur Windows TCP/IP-Leistungsoptimierung (Microsoft)</li>
<li>Leitfaden zur ESnet-Netzwerkoptimierung – https://fasterdata.es.net/</li>
</ul>
<h2>Abschluss</h2>
<p>Die Erschöpfung des Puffers ist eine häufige Ursache für Leistungsprobleme, die scheinbar mit dem Netzwerk zusammenhängen. Durch das Verständnis der Entwicklung der Puffergröße von den 128-KB-Grenzwerten im Jahr 2009 bis zu den heutigen 128-MB-Kapazitäten können Netzwerktechniker diese Probleme schnell erkennen und lösen.</p>
<p>Wichtige Erkenntnisse:</p>
<ul>
<li>Moderne Systeme benötigen deutlich größere Puffer als ältere (2009) Konfigurationen</li>
<li>Berechnen Sie den BDP immer für Ihre spezifischen Netzwerkbedingungen</li>
<li>Verwenden Sie die Funktionen zur automatischen Optimierung des Betriebssystems, sofern verfügbar (Windows, modernes Linux).</li>
<li>Überwachen und testen Sie, um Änderungen zu validieren</li>
<li>Berücksichtigen Sie bei der Optimierung arbeitslastspezifische Anforderungen</li>
</ul>
<p>Denken Sie daran: Ein „Netzwerkproblem“, das durch die Paketanalyse aufgedeckt wird und TCP-Nullfenster anzeigt, ist eigentlich ein Ressourcenproblem des Hostsystems. Mit der richtigen Pufferabstimmung können Sie diese Fehldiagnosen beseitigen und eine optimale Leistung erzielen.</p>
<hr/>
<p><em>Letzte Aktualisierung: 2. Februar 2026</em></p>
<p><em>Autor: Baud9600 Technisches Team</em></p>