TCP Window Size & Scaling einfach erklärt: Der Schlüssel zu maximaler Netzwerk-Performance

Jeder, der schon eine Weile in der IT arbeitet, kennt diesen Moment: Ein Ticket ploppt auf, in dem steht: „Das Netzwerk ist zu langsam!“ Der Server-Administrator schwört, seine Maschinen langweilen sich, der Storage-Kollege zeigt auf seine blitzschnellen NVMe-LUNs, und das Applikationsteam verweist ohnehin aufs Netz. Als Netzwerk-Engineer oder IT-Leiter schaust du ins Monitoring und siehst: Die 1-Gigabit-Standortverbindung ist gerade einmal zu 5 Prozent ausgelastet. Warum tröpfeln die Daten dann nur im Schneckentempo durch die Leitung?

In den meisten Fällen liegt das Problem nicht an einer verstopften Leitung, sondern an der Art und Weise, wie Sender und Empfänger miteinander kommunizieren. Genau hier kommen die Konzepte der TCP Window Size und des TCP Window Scaling ins Spiel. (Eine allgemeine Einordnung, warum ein Netzwerk trotz Gigabit-Anbindung langsam sein kann, findest du in meinem Artikel Warum ist mein Netzwerk langsam trotz 1 Gbit? – hier steigen wir tief in den TCP-Mechanismus dahinter ein.)

Wer als technischer Entscheider oder IT-Administrator moderne Unternehmensnetze plant und betreibt, kommt nicht umhin, diese grundlegenden Mechanismen zu verstehen. Sie sind oft der unsichtbare Hebel, der darüber entscheidet, ob ein Backup in zwei Stunden oder in zwei Tagen durchläuft.

Kurz & knapp: Ein einzelner TCP-Datenstrom kann nie schneller sein als Window Size ÷ Round-Trip-Time. Ohne Window Scaling ist bei 40 ms Latenz schon bei ca. 13 Mbit/s Schluss – egal, wie dick die Leitung ist. Ob Scaling aktiv ist, entscheidet sich im Drei-Wege-Handshake, und genau dort musst du in Wireshark hinschauen.

Typisches Szenario: Die große Leitung, die nicht liefert

Fangen wir mit einem klassischen Beispiel aus meinem Netzwerkanalytik-Alltag an. Ein Kunde hatte gerade die Anbindung an sein neues Rechenzentrum auf 10 Gbit/s hochgerüstet. Doch als es darum ging, eine 500 GB große Datenbank vom Hauptstandort ins Rechenzentrum zu spiegeln, dauerte der Vorgang quälend lange. Der Durchsatz lag konstant bei mageren 13 Mbit/s – rechnerisch hätte die Übertragung über drei Tage gedauert. Bei voller Ausnutzung der 10-Gbit/s-Leitung wären es wenige Minuten gewesen.

Das WAN-Monitoring zeigte alles im grünen Bereich. Die Latenz (Round-Trip Time, RTT) betrug rund 40 Millisekunden – völlig normal für die Distanz. Trotzdem trat das Phänomen auf, das wir in der Netzwerkanalyse als „Long Fat Network“-Problem (LFN) bezeichnen: eine fette Leitung mit spürbarer Verzögerung, auf der TCP scheinbar Dienst nach Vorschrift macht.

Das Applikationsteam beschwerte sich über Performance-Probleme, das Management stellte die Investition in die 10G-Leitung infrage. Das Problem war jedoch nicht die physische Schicht. Das Problem war, dass die beiden Server sich nicht einig waren, wie viele Daten sie unbestätigt „in der Luft“ (in flight) halten durften. Der Empfänger bremste den Sender unbewusst aus. Wie der Fall ausging, zeige ich weiter unten – vorher brauchen wir das Handwerkszeug.

Technischer Hintergrund: Wie TCP den Datenfluss steuert

Um das zu verstehen, müssen wir kurz unter die Haube von TCP (Transmission Control Protocol) schauen. TCP ist ein verbindungsorientiertes und zuverlässiges Protokoll. Das bedeutet: Jedes gesendete Datenpaket muss vom Empfänger bestätigt werden (ACK). Wie Sequenznummern und Bestätigungen dabei zusammenspielen, erkläre ich ausführlich in Wie lese ich einen TCP Stream richtig?

Damit der Sender nicht nach jedem einzelnen Paket auf das ACK warten muss – was extrem ineffizient wäre –, nutzt TCP ein Konzept namens Flow Control (Flusskontrolle). Der Empfänger teilt dem Sender in jedem TCP-Header mit: „Mein Empfangspuffer hat gerade noch Platz für X Bytes.“ Dieser Wert ist die TCP Window Size (Receive Window).

Zwei Fenster, eine Bremse: Receive Window und Congestion Window

Ein Punkt, der in vielen Erklärungen untergeht: TCP arbeitet mit zwei Fenstern. Das Receive Window (rwnd) legt der Empfänger fest und schreibt es in jedes Paket – das ist der Wert, den du in Wireshark siehst. Das Congestion Window (cwnd) führt der Sender intern, um das Netz nicht zu überlasten. Es taucht in keinem Header auf. Der Sender darf immer nur so viele Daten unbestätigt verschicken, wie das kleinere der beiden Fenster erlaubt:

Effektives Sendefenster = min(Receive Window, Congestion Window)

Für die Fehlersuche ist das entscheidend: Ein zu kleines Receive Window erkennst du direkt im Trace. Ein gedrosseltes Congestion Window – etwa nach Paketverlust – siehst du nur indirekt, zum Beispiel an den Bytes in Flight. In diesem Artikel geht es vor allem um das Receive Window. Die Rolle des Congestion Windows schauen wir uns im Abschnitt zu Paketverlusten an.

Die Grenze der 64 Kilobyte

Im ursprünglichen TCP-Standard ist das Feld für die Window Size genau 16 Bit groß. Der maximal darstellbare Wert ist damit 2¹⁶ − 1, also 65.535 Bytes (64 KB).

Ist der Empfangspuffer 64 KB groß, darf der Sender maximal 64 KB an Daten abschicken, bevor er stoppen und auf ein Acknowledgment warten muss. In einem lokalen Netzwerk (LAN) mit typischerweise 0,2 ms Latenz ist das kein Problem – die Bestätigungen kommen so schnell, dass selbst 64 KB für über 2 Gbit/s reichen. Aber was passiert auf einer WAN-Strecke mit 40 ms Latenz?

Hier kommt die Rechnung ins Spiel, die den Durchsatz eines einzelnen TCP-Datenstroms begrenzt:

Maximaler Durchsatz = TCP Window Size / Latenz (RTT)

Setzen wir unsere 64 KB und die 40 ms ein:

65.535 Bytes × 8 Bit = 524.280 Bits
524.280 Bits / 0,040 Sekunden = 13,1 Mbit/s

Egal wie viel Bandbreite dein Provider dir schaltet, ob 100 Mbit/s oder 100 Gbit/s – mit einem 64 KB großen TCP Window und 40 ms Latenz ist bei ca. 13 Mbit/s Schluss. Bei unserer 10-Gbit/s-Leitung nutzt der Datenstrom damit gerade einmal 0,13 % der verfügbaren Bandbreite. Hier liegt der Bottleneck nicht in der Hardware, sondern in der Mathematik.

Das Bandwidth-Delay Product (BDP): Wie groß muss das Window sein?

Dreht man die Rechnung um, erhält man das Bandwidth-Delay Product (BDP). Es sagt dir, wie viele Daten gleichzeitig „unterwegs“ sein müssen, um eine Leitung vollständig auszulasten:

BDP = Bandbreite × Latenz (RTT)
1 Gbit/s × 40 ms = 40 Mbit = 5 MB
10 Gbit/s × 40 ms = 400 Mbit = 50 MB

Die Window Size muss mindestens so groß sein wie das BDP – sonst bleibt die Leitung zwangsläufig teilweise leer. Mit 64 KB ist das auf modernen WAN-Strecken nicht zu schaffen. Genau dafür gibt es Window Scaling.

Weitere Infos und auch einen BDP-Rechner findest du in meinem Beitrag Congestion Control: Wie TCP Reno, CUBIC und BBR den Datendurchsatz steuern.

Die Rettung: TCP Window Scaling (RFC 1323 / 7323)

Um dieses Problem zu lösen, wurde die TCP-Erweiterung Window Scaling eingeführt (ursprünglich RFC 1323, heute RFC 7323). Da man den TCP-Header aus Kompatibilitätsgründen nicht einfach vergrößern konnte, nutzt man einen Trick: einen Multiplikator.

Im Drei-Wege-Handshake teilt jede Seite in ihrem SYN bzw. SYN-ACK einen Shift-Faktor mit – und zwar für ihr eigenes Empfangsfenster. Die Faktoren können sich je Richtung unterscheiden, etwa 8 beim Client und 7 beim Server. Beträgt der Faktor 7, wird der 16-Bit-Wert im Header mit 2⁷ (also 128) multipliziert. In der Info-Spalte von Wireshark erscheint das als WS=128. Typischerweise siehst du bei Windows WS=256 (Faktor 8) und bei aktuellen Linux-Systemen WS=128 (Faktor 7).

Wichtig: Window Scaling ist nur aktiv, wenn beide Seiten die Option im Handshake senden. Fehlt sie in einem der beiden Pakete, gilt für die gesamte Verbindung in beiden Richtungen wieder das 64-KB-Limit. Außerdem werden die Window-Werte im SYN und SYN-ACK selbst nie skaliert. Alles Wissenswerte zum Verbindungsaufbau findest du in meinem Artikel TCP Handshake analysieren mit Wireshark.

Was die einzelnen Faktoren auf unserer 40-ms-Strecke bedeuten, zeigt die folgende Übersicht:

Zwei Dinge fallen auf. Erstens: Für unsere 10-Gbit/s-Strecke mit einem BDP von 50 MB wäre mindestens Faktor 10 nötig. Zweitens: Der Faktor legt nur die Obergrenze fest. Wie groß das Window tatsächlich wird, bestimmt der Empfangspuffer des Betriebssystems. Mit den typischen Standardwerten kommt ein einzelner Datenstrom auch bei funktionierendem Scaling nicht auf 10 Gbit/s über 40 ms.

Window Scaling ist heute in jedem modernen Betriebssystem standardmäßig aktiv – und trotzdem scheitert es in der Praxis erstaunlich oft. Warum, finden wir mit Wireshark heraus.

Analyse mit Wireshark (konkrete Schritte)

Wenn ich als Netzwerkanalytiker in ein Projekt gerufen werde, ist mein erstes Werkzeug immer der Paketmitschnitt. Wir müssen auf den Draht schauen, denn Pakete lügen nicht. Hier sind die konkreten Schritte, mit denen du das Problem in Wireshark sichtbar machst.

Schritt 1: Den Handshake aufzeichnen

Das ist der wichtigste Punkt – und der am häufigsten gemachte Fehler: Du musst den Verbindungsaufbau (Drei-Wege-Handshake) im Mitschnitt haben! Die Window-Scaling-Faktoren werden ausschließlich in den initialen SYN- und SYN-ACK-Paketen übertragen. Fehlen diese Pakete im Trace, kann Wireshark den tatsächlichen (skalierten) Wert nicht berechnen und zeigt dir falsche Daten an. Bei bereits laufenden Verbindungen hilft nur: Mitschnitt starten, dann die Verbindung neu aufbauen lassen (z. B. die Dateiübertragung neu starten).

Achte außerdem auf den Messpunkt. Werte wie Bytes in Flight und die Meldung „Window Full“ berechnet Wireshark aus dem, was es am Messpunkt sieht – am aussagekräftigsten sind sie in einem Mitschnitt nahe am Sender. Ideal ist ein gleichzeitiger Mitschnitt an beiden Enden. Nur so erkennst du, ob unterwegs etwas am Handshake verändert wurde.

Schritt 2: Die richtigen Spalten in Wireshark einblenden

Die wichtigsten Felder blendest du am schnellsten ein, indem du im Paketdetail-Bereich unter „Transmission Control Protocol“ das gewünschte Feld mit der rechten Maustaste anklickst und „Als Spalte anwenden“ (Apply as Column) wählst. Diese Felder sind relevant:

• tcp.window_size_value – der rohe 16-Bit-Wert aus dem Header (max. 65.535)
• tcp.window_size – die von Wireshark berechnete, skalierte Window Size. Das ist der echte Wert!
• tcp.window_size_scalefactor – der verwendete Multiplikator. Ein Wert von -1 bedeutet „unbekannt“ (Handshake fehlt im Trace), -2 bedeutet „Window Scaling wird nicht verwendet“.

Um im Trace gezielt alle Verbindungen ohne Window Scaling zu finden, nutzt du diesen Filter:

Und so spürst du SYN-Pakete auf, die gar keine Window-Scale-Option mitbringen:

Schritt 3: Auf TCP-Warnungen achten

Filtere deinen Traffic gezielt auf Auffälligkeiten. Ein guter Startpunkt ist dieser Filter – Window Updates sind normales TCP-Verhalten und blähen die Liste nur auf, deshalb blende ich sie aus:

Achte besonders auf folgende Meldungen in der Info-Spalte (weitere nützliche Filter für den Alltag findest du in Wireshark für Admins: Die 10 wichtigsten Display-Filter):

• TCP Window Full (tcp.analysis.window_full): Der Sender hat das Window des Empfängers komplett ausgeschöpft und muss jetzt auf ein ACK warten. Häufen sich diese Meldungen, ist das ein starker Beleg dafür, dass das Receive Window der limitierende Faktor ist.
• TCP Zero Window (tcp.analysis.zero_window): Der Empfänger ruft um Hilfe: „Mein Puffer ist voll, bitte sende keine Daten mehr!“ Hier ist das System des Empfängers überlastet – z. B. durch eine langsame Festplatte, hohe CPU-Last oder eine Anwendung, die die Daten nicht abholt. Mehr dazu in Verbindungsabbrüche analysieren.

Schritt 4: Bytes in Flight und Window-Verlauf grafisch auswerten

Mit dem Feld tcp.analysis.bytes_in_flight siehst du, wie viele unbestätigte Bytes aktuell unterwegs sind. Stößt dieser Wert regelmäßig an die Window Size des Empfängers, ist das Window der Flaschenhals.

Anschaulicher geht es grafisch. Markiere ein Datenpaket in Senderichtung und öffne Statistics → TCP Stream Graphs → Window Scaling. Der Graph zeigt das Receive Window und die Bytes in Flight über die Zeit. Eine flache Window-Linie bei 64 KB ist ein klares Indiz für fehlendes Scaling. Läuft die Bytes-in-Flight-Kurve ständig gegen diese Linie, bremst das Window.

Ebenso aufschlussreich ist der Graph Time/Sequence (tcptrace): Die obere Linie markiert das Ende des Receive Windows. Klebt die Datenkurve treppenförmig an dieser Linie, wartet der Sender permanent auf Platz beim Empfänger. Zeigt der Graph nichts Sinnvolles, hast du vermutlich die falsche Richtung erwischt – dann hilft der Button „Switch Direction“.

Entscheidungshilfe: Wer bremst hier eigentlich?

Wie der letzte Fall in der Praxis aussieht, zeige ich im Praxisfall SQL über WAN-Strecke. Wer das Muster „Netzwerk oder Anwendung?“ grundsätzlich systematisieren möchte, findet in Netzwerkprobleme eingrenzen: Die 5-Schritte-Methodik das passende Vorgehen.

Häufige Ursachen für Performance-Einbrüche

Wenn du in Wireshark siehst, dass das TCP Window Scaling fehlt oder die Windows extrem klein bleiben, hat das in der Regel handfeste Gründe. Aus meiner Erfahrung gibt es fünf typische Täter in Unternehmensnetzen.

1. Firewalls und Middleboxes

Ein Klassiker, der in gewachsenen Umgebungen immer noch erstaunlich oft auftaucht. Next-Generation Firewalls (NGFW), Load Balancer oder WAN-Optimierer inspizieren den Traffic. In einigen – meist älteren oder restriktiv konfigurierten – Setups entfernen sie unbekannte oder als unsicher eingestufte TCP-Optionen aus den Headern („TCP Option Stripping“ bzw. „TCP Normalization“).

Löscht die Firewall beim Handshake die Window-Scaling-Option aus dem SYN-Paket, fällt die Kommunikation gnadenlos auf das harte 64-KB-Limit zurück. Die Folge: massiver Performance-Verlust. Typisches Symptom im Trace: Das SYN-Paket am Sender enthält die Option „Window scale“, am Empfänger kommt es ohne diese Option an.

Seltener, aber tückischer ist der umgekehrte Fall: Die Option kommt durch, aber ein Stateful-Gerät auf dem Pfad rechnet selbst nicht korrekt mit dem Faktor. Es hält Pakete für „außerhalb des Fensters“ und verwirft sie. Im Trace siehst du dann Retransmissions und hängende Transfers, sobald das Window über 64 KB hinauswächst.

2. Paketverluste und TCP Retransmissions

Ein gesundes TCP-Window wächst dynamisch an, bis es die verfügbare Bandbreite optimal nutzt. Doch was passiert bei Paketverlusten? Klassische TCP-Algorithmen interpretieren einen Paketverlust als Anzeichen für Stau im Netzwerk.

Um die Überlast nicht weiter zu verschlimmern, reduziert der Sender sofort sein Congestion Window – bei Reno auf die Hälfte, bei CUBIC auf rund 70 Prozent – und verfällt in einen Recovery-Modus. In Wireshark siehst du dann gehäuft TCP Retransmissions. Wie stark das wirkt, zeigt eine Faustformel, die Mathis-Formel für klassisches Reno-Verhalten:

Max. Durchsatz ≈ (MSS / RTT) × (1,22 / √Verlustrate)

Mit einer MSS von 1.460 Byte, 40 ms RTT und nur 0,1 % Verlust ergibt das für einen einzelnen Datenstrom rund 11 Mbit/s – unabhängig von der Leitungsgröße und selbst bei perfekt funktionierendem Window Scaling. Hier bremst nicht das Receive Window, sondern das Congestion Window. Modernere Algorithmen wie CUBIC oder BBR gehen mit Verlusten besser um, ganz verschwindet das Problem aber nicht.

Wie du Paketverlust sauber nachweist und von anderen Ursachen abgrenzt, zeige ich in Packet Loss messen und analysieren. Den Unterschied zwischen Retransmission, Dup ACK und Out-of-Order erklärt dieser Artikel, und warum Retransmissions so teuer sind, steht in TCP Retransmissions: Der stille Performance-Killer. Wie sich die einzelnen Algorithmen unterscheiden, erfährst du unter Congestion Control: Reno, CUBIC und BBR.

3. Falsche Betriebssystem-Konfigurationen (Legacy Systems)

TCP Auto-Tuning gibt es unter Windows seit Vista bzw. Server 2008 und unter Linux seit den 2.6er-Kerneln. Trotzdem treffe ich immer wieder auf „kaputtkonfigurierte“ Server. Irgendwann hat ein Admin einen Foreneintrag aus dem Jahr 2008 gefunden und statische TCP-Parameter in der Windows-Registry oder per sysctl unter Linux erzwungen. Ist Auto-Tuning deaktiviert oder die maximale Puffergröße künstlich klein gehalten, kann sich die Window Size nicht mehr an die RTT anpassen. Unter Windows bremsen neben disabled übrigens auch die Stufen restricted und highlyrestricted.

4. Anwendungen mit fest eingestellten Socket-Puffern

Ein Fall, der leicht übersehen wird: Manche Anwendungen – ältere Backup- und Replikationstools, Java-Anwendungen oder selbstgeschriebene Dienste – legen die Größe ihres Socket-Puffers fest im Code fest. Setzt eine Anwendung den Empfangspuffer explizit (SO_RCVBUF), nimmt das Betriebssystem diesen Socket vom Auto-Tuning aus. Unter Linux wird zudem der Shift-Faktor schon beim Verbindungsaufbau passend klein gewählt.

Typisches Bild: Andere Verbindungen desselben Servers skalieren sauber, nur diese eine Anwendung kommt nie über ein kleines Window hinaus. Mit einem Kreuztest, etwa per iperf3 zwischen denselben Systemen (siehe unten), grenzt du das schnell ein.

5. Standard-Limits bei sehr hohem BDP

Selbst ein perfekt eingerichtetes System stößt bei 10 Gbit/s über größere Entfernungen an Grenzen. Viele Linux-Distributionen begrenzen den Empfangspuffer ab Werk auf 6 MB (dritter Wert von net.ipv4.tcp_rmem) und den Sendepuffer auf 4 MB (net.ipv4.tcp_wmem). Bei 40 ms RTT reicht das pro Datenstrom für gut 800 Mbit/s bis 1,2 Gbit/s. Windows kommt mit dem typischen Faktor 8 auf maximal rund 16 MB, also etwa 3,4 Gbit/s. Für die meisten Standortverbindungen genügt das – für 10 Gbit/s über Distanz nicht.

Das gleiche Problem in der Cloud und im SD-WAN

Das BDP-Limit ist keine reine WAN-Disziplin – es trifft dich überall dort, wo Latenz und TCP aufeinandertreffen. Und das ist heute praktisch jede moderne IT-Umgebung.

Azure und AWS: Der unsichtbare Flaschenhals in der Cloud-Anbindung

Viele Unternehmen verlagern Workloads in die Cloud und wundern sich anschließend, warum die Anbindung an Azure oder AWS „irgendwie lahm“ wirkt – obwohl ExpressRoute, Direct Connect oder eine andere dedizierte Leitung gebucht wurde. Das Muster ist identisch: Die Bandbreite ist da, aber die Latenz zur nächsten Cloud-Region beträgt je nach Standort 10–25 ms, zu US-Regionen schnell 80–120 ms. Ist Window Scaling auf einem der beteiligten Server deaktiviert oder wird es durch ein zwischengeschaltetes Security-Gateway entfernt, greift wieder das harte 64-KB-Limit – und deine teure Cloud-Anbindung liefert nur einen Bruchteil der möglichen Performance.

Besonders tückisch sind per Lift & Shift migrierte Server. Hat ein Vorgänger-Admin sie irgendwann mit statischen TCP-Parametern „optimiert“, überleben diese Einstellungen jede Migration und bremsen die Performance still und leise. Wie du die Latenz deiner Strecke vorab sauber misst, zeigt Hohe Latenz im Firmennetz: RTT mit Wireshark analysieren.

SD-WAN: Wenn die Intelligenz zur Falle wird

SD-WAN-Lösungen versprechen optimierte Pfade, automatisches Failover und bessere Performance. In der Praxis fügen sie aber eine weitere Schicht ein, an der TCP-Optionen manipuliert werden können. Das Ergebnis kennst du vielleicht: Zwei Standorte sind per SD-WAN verbunden, die Overlay-Verbindung sieht im Dashboard grün aus, aber der tatsächliche Durchsatz bleibt weit unter den Erwartungen.

Hier hilft ein Wireshark-Capture auf beiden Seiten der Appliance. Wichtig ist dabei die Frage, wie das Gerät arbeitet. Reicht es TCP transparent durch, muss der Handshake auf beiden Seiten identisch aussehen. Fehlt die Window-Scale-Option auf einer Seite, hast du deinen Täter und weißt, worüber du mit dem Hersteller sprechen musst. Terminiert die Appliance TCP dagegen (TCP-Proxy, WAN-Optimierung), gibt es zwei getrennte Verbindungen mit eigenem Handshake. Unterschiedliche Optionen sind dann normal, und du bewertest jedes Teilstück einzeln.

Lösung / Best Practices: So machst du den Weg frei

Wie bekommen wir die PS nun endlich auf die Straße? Die Vorgehensweise ist logisch und methodisch.

1. Messen, nicht raten: Starte immer mit einem sauberen Wireshark-Capture an beiden Enden (Sender und Empfänger), inklusive Drei-Wege-Handshake. Vergleiche die SYN-Pakete am Sender mit denen, die am Empfänger ankommen.

2. Firewall-Regeln prüfen: Ist senderseitig die Window-Scale-Option (WS) gesetzt, fehlt beim Empfänger aber, hast du den Täter. Prüfe das TCP-Options-Handling auf allen Firewalls und Load Balancern entlang der Route und stelle sicher, dass die Optionen aus RFC 7323 transparent durchgereicht werden.

3. Betriebssystem-Tuning zurücksetzen: Verlass dich auf die modernen OS-Mechanismen. Unter Windows prüfst du, ob das „Receive Window Auto-Tuning Level“ auf normal steht:

Steht es auf disabled oder einer der restriktiven Stufen, setzt du es so zurück:

Unter Linux prüfst du, ob Window Scaling aktiv ist (tcp_window_scaling = 1) und wie groß die maximalen Puffer sind – jeweils der dritte Wert von tcp_rmem und tcp_wmem:

Nur wenn das BDP deiner Strecke die Standardwerte klar übersteigt (z. B. 10 Gbit/s über 40 ms), lohnt es sich, die Obergrenzen anzuheben – etwa auf 64 MB für Empfangs- und Sendepuffer:

Die Änderung gilt nur für neue Verbindungen und geht beim Neustart verloren. Dauerhaft hinterlegst du sie in einer Datei unter /etc/sysctl.d/ – aber bitte erst, nachdem du den Effekt gemessen hast.

4. Die Single-Stream-Grenze testen: Mit iperf3 findest du schnell heraus, ob ein Limit pro Datenstrom bremst. Starte auf dem Zielsystem den Server (iperf3 -s) und miss vom Quellsystem zuerst mit einem Datenstrom:

Danach mit acht parallelen Datenströmen:

Liefern acht Ströme annähernd das Achtfache, ist nicht die Leitung das Limit, sondern Window und RTT pro Verbindung. Dann helfen größere Puffer oder Werkzeuge, die von sich aus parallel übertragen – etwa robocopy /MT oder Backup-Software mit mehreren Streams. Lastintensive Tests auf produktiven Strecken gehören natürlich in ein Wartungsfenster.

5. Paketverluste aufspüren: Siehst du viele TCP Retransmissions, prüfe die Interfaces deiner Switches und Router auf Fehler (FCS Errors, Drops, Microbursts). Das Netzwerk muss sauber laufen, damit TCP sauber skalieren kann.

6. Anwendung prüfen: Zeigt der Trace weder Window Full noch Zero Window noch Verluste, liegt die Ursache meist nicht im Transport, sondern in der Anwendung oder im Datenbankzugriff (siehe Praxisfall: Sequentielle DB-Requests & N+1 Query).

Zurück zum Szenario: Was der Trace gezeigt hat

Und wie ging es bei unserem Kunden mit der 10-Gbit/s-Leitung aus? Der beidseitige Mitschnitt war nach wenigen Minuten eindeutig: Das SYN verließ den Quellserver mit WS=256, am Zielserver im Rechenzentrum kam es ohne Window-Scale-Option an. Eine ältere Firewall am RZ-Übergang entfernte die Option. tcp.window_size_scalefactor stand auf -2, das Window klebte bei 64 KB, und der Durchsatz lag exakt dort, wo die Formel ihn vorhersagt: bei 13 Mbit/s.

Nach der Korrektur der Firewall-Konfiguration skalierte das Window sauber, und ein einzelner Datenstrom erreichte Gigabit-Niveau. Aus drei Tagen wurde rund eine Stunde. Die letzte Lücke zur vollen 10-Gbit/s-Leistung schloss die Replikation mit mehreren parallelen Streams. Die 10G-Leitung war nie das Problem – sie wurde nur nicht genutzt.

Fazit + Handlungsempfehlung

Eine langsame Dateiübertragung oder spürbare Performance-Probleme in WAN-, Cloud- und SD-WAN-Szenarien liegen selten an der gebuchten Bandbreite. Oft ist es das Zusammenspiel aus Latenz und einer limitierten TCP Window Size, das wie eine unsichtbare Handbremse wirkt. Mit Wireshark machst du diese Mechanismen sichtbar, identifizierst blockierende Security-Gateways und findest Konfigurationsfehler. Ein sauberes Netzwerkanalyse-Setup erspart dir wochenlanges Rätselraten und Fingerzeig-Spielchen zwischen den IT-Abteilungen.

Für IT-Leiter und Entscheider steckt darin eine wichtige Botschaft: Mehr Bandbreite hilft nur, wenn TCP sie auch nutzen kann. Bevor du eine größere Leitung bestellst oder eine Investition infrage stellst, lohnt ein Paketmitschnitt. Er kostet einen Bruchteil und zeigt dir, ob Bandbreite, Latenz, Paketverlust oder die Anwendung bremst.

Hast du gerade mit einem hartnäckigen Performance-Engpass zu kämpfen? Ob quälend langsames Backup übers WAN, Storage-Replikationen, die nicht fertig werden, Cloud-Anbindungen, die nicht liefern, oder SD-WAN-Deployments mit unerklärlich schlechtem Durchsatz – ich werte deine Mitschnitte aus und lege offen, wo die Zeit verloren geht. Egal, ob du aus dem Netzwerkteam, aus dem Applikationsbetrieb oder aus der IT-Leitung kommst. Mehr zu meinem Vorgehen findest du auf der Seite Netzwerk-Performance- & Latenzanalyse (TCP) – oder du vereinbarst direkt ein kostenloses Erstgespräch, und wir schauen gemeinsam in deine Pakete.

Weiterführende Artikel

• TCP Handshake analysieren mit Wireshark – so erkennst du fehlendes Window Scaling direkt im SYN
• Wie lese ich einen TCP Stream richtig?
• Congestion Control: Wie TCP Reno, CUBIC und BBR den Datendurchsatz steuern
• Packet Loss messen und analysieren
• Hohe Latenz im Firmennetz: RTT mit Wireshark analysieren
• Praxisfall: SQL über WAN-Strecke
• Praxisfall: Single-Threading als Performance-Killer

FAQ: Häufige Fragen zu TCP Window Size & Scaling

Was ist das TCP Window?

Das TCP Window ist der freie Platz im Empfangspuffer, den ein Empfänger dem Sender in jedem TCP-Segment mitteilt. Es gibt an, wie viele Daten der Sender unbestätigt – also ohne auf ein Acknowledgment zu warten – verschicken darf. Je größer dieses Fenster, desto mehr Daten können gleichzeitig „unterwegs“ sein, was die Geschwindigkeit auf Strecken mit hoher Latenz maßgeblich bestimmt.

Warum ist mein File-Transfer langsam, obwohl ich eine Gigabit-Leitung habe?

Das liegt meistens am Bandwidth-Delay Product (BDP). Bei einer Verbindung mit hoher Latenz (z. B. 50 ms) müssen Sender und Empfänger große Datenmengen unbestätigt übertragen können. Ist die TCP Window Size begrenzt – z. B. weil eine Firewall die TCP-Option „Window Scaling“ entfernt –, sinkt dein Durchsatz pro Datenstrom auf wenige Megabit pro Sekunde, egal wie groß deine Leitung ist.

Wie berechne ich das Bandwidth-Delay Product?

Multipliziere die Bandbreite deiner Strecke mit der Round-Trip-Time. Beispiel: 1 Gbit/s × 0,04 s = 40 Mbit, also 5 MB. So groß muss die TCP Window Size mindestens sein, damit ein einzelner Datenstrom die Leitung vollständig auslasten kann. Die RTT liest du am einfachsten am Drei-Wege-Handshake ab – Wireshark zeigt sie im Feld tcp.analysis.initial_rtt.

Wie erkenne ich, ob TCP Window Scaling aktiv ist?

Öffne den Mitschnitt, suche das SYN- und das SYN-ACK-Paket der Verbindung und schau in den TCP-Optionen nach „Window scale“. Steht die Option in beiden Paketen, ist Scaling aktiv. Komfortabler: Das Feld tcp.window_size_scalefactor zeigt den verwendeten Faktor – bei -2 wird kein Scaling verwendet, bei -1 fehlt der Handshake im Trace.

Warum zeigt Wireshark eine Window Size von nur wenigen hundert Bytes an?

Fast immer fehlt der Handshake im Mitschnitt. Ohne SYN und SYN-ACK kennt Wireshark den Shift-Faktor nicht und zeigt den rohen Header-Wert an. Ein angezeigter Wert von 1.026 Bytes kann bei Faktor 8 in Wahrheit rund 262 KB bedeuten. Starte den Mitschnitt vor dem Verbindungsaufbau, dann stimmen die Werte. In den TCP-Einstellungen von Wireshark kannst du zwar einen Standardfaktor vorgeben, das ist aber geraten und nicht gemessen.

Was bedeutet „TCP Zero Window“ in Wireshark?

„TCP Zero Window“ bedeutet, dass der Empfangspuffer des Zielsystems komplett voll ist (0 Bytes frei). Das Zielsystem signalisiert dem Sender damit: „Halt, sende nichts mehr, ich komme nicht hinterher!“ Das ist kein Netzwerkproblem im eigentlichen Sinne, sondern meist ein Indiz dafür, dass der Empfänger überlastet ist – durch hohe CPU-Auslastung, langsamen Storage oder eine blockierte Anwendung.

Wie erkenne ich Paketverluste in Wireshark?

Paketverluste erkennst du in Wireshark an TCP Retransmissions (Neuübertragungen) und „Dup ACKs“ (Duplicate Acknowledgements). Sie zeigen, dass Pakete unterwegs verloren gegangen sind und der Sender sein Congestion Window reduziert hat – was die Geschwindigkeit drosselt und zu spürbaren Performance-Einbrüchen führt. Eine ausführliche Anleitung findest du in Packet Loss messen und analysieren.

Wie groß sollte die TCP Window Size sein?

Eine pauschale Antwort gibt es nicht – die optimale Window Size hängt von Bandbreite und Latenz deiner Strecke ab (Stichwort: Bandwidth-Delay Product). Moderne Betriebssysteme regeln das automatisch über TCP Auto-Tuning der Empfangspuffer: Windows passt die Window Size dynamisch an, Linux regelt das über die tcp_rmem-Parameter. Davon zu unterscheiden ist die Congestion Control (z. B. CUBIC oder BBR), die auf Senderseite bestimmt, wie aggressiv Daten ins Netz geschickt werden. Die beste Empfehlung lautet: Lass das Betriebssystem seinen Job machen und stelle sicher, dass nichts – weder Firewalls noch manuelle Registry-Einträge – das Auto-Tuning blockiert. Nur bei sehr hohem BDP, etwa 10 Gbit/s über größere Entfernungen, reichen die Standardgrenzen nicht. Dann helfen größere Puffer oder parallele Datenströme.