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, und der Storage-Kollege zeigt auf seine blitzschnellen NVMe-LUNs. Als Netzwerk-Engineer oder IT-Leiter schaust du auf das 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.

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.

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 Hauptquartier ins Rechenzentrum zu spiegeln, dauerte der Vorgang quälend lange. Der Durchsatz lag konstant bei mageren 20 Mbit/s.

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. Doch trotzdem trat das Phänomen auf, das wir in der Netzwerkanalyse scherzhaft als „Long Fat Network”-Problem bezeichnen: Eine fette Leitung mit spürbarer Verzögerung, auf der TCP scheinbar den Dienst nach Vorschrift macht.

Die Entwickler beschwerten sich über Performance-Probleme, das Management stellte die Investition in die 10G-Leitung in Frage. 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.

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).

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 im TCP-Header kontinuierlich mit: „Hey, mein Empfangspuffer hat gerade noch Platz für X Bytes.” Dieser Wert ist die TCP Window Size (Receive Window).

Die Grenze der 64 Kilobyte

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

Wenn der Empfangspuffer 64 KB groß ist, darf der Sender maximal 64 KB an Daten abschicken, bevor er stoppen und auf ein Acknowledgment warten muss. In einem lokalen Netzwerk (LAN) mit unter 1 ms Latenz ist das kein Problem – die Bestätigungen kommen sofort. Aber was passiert auf einer WAN-Strecke mit 40 ms Latenz?

Hier kommt das Bandwidth-Delay Product (BDP) ins Spiel. Die Formel für den maximal möglichen Durchsatz ist einfach:

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 physikalisch Schluss. Hier liegt der Bottleneck nicht in der Hardware, sondern in der Mathematik.

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

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

Während des Verbindungsaufbaus (im Drei-Wege-Handshake, in den SYN- und SYN-ACK-Paketen) handeln Client und Server einen Shift-Faktor aus. Wenn der Faktor beispielsweise 7 beträgt, wird der ursprüngliche 16-Bit-Wert im Header intern mit 2⁷ (also 128) multipliziert.

Aus maximal 64 KB werden so plötzlich über 8 Megabyte. Damit lassen sich auch auf Leitungen mit hoher Latenz problemlos Gigabit-Geschwindigkeiten erreichen. Dieser TCP-Algorithmus ist heute in jedem modernen Betriebssystem standardmäßig aktiv.

Doch warum funktioniert es in der Praxis oft trotzdem nicht? Das finden wir mit Wireshark heraus.

Analyse mit Wireshark (konkrete Schritte)

Wenn ich als Consultant in ein Projekt gerufen werde, ist mein erstes Werkzeug immer der Paket-Sniffer. Wir müssen auf den Draht schauen, denn Pakete lügen nicht. Hier sind die konkreten Schritte, wie du das Problem mit Wireshark sichtbar machen kannst:

Schritt 1: Den Handshake aufzeichnen

Das ist der wichtigste – und 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 später nicht berechnen und zeigt dir falsche Daten an.

Schritt 2: Die richtigen Spalten in Wireshark einblenden

Standardmäßig zeigt Wireshark oft nur die unskalierte Window Size an. Mach einen Rechtsklick auf die Spaltenköpfe, wähle „Spalteneinstellungen” und füge folgende Filter hinzu:

• 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!

Schritt 3: Auf TCP-Warnungen achten

Filtere deinen Traffic in Wireshark gezielt auf Probleme. Ein guter Startpunkt ist der Filter:

tcp.analysis.flags

Achte besonders auf folgende Meldungen in der „Info”-Spalte:

• TCP Window Full: Der Sender meldet: „Ich habe das Window des Empfängers komplett ausgeschöpft und muss jetzt auf ein ACK warten.” Das ist der ultimative Beweis, dass das Receive Window der limitierende Faktor ist.
• TCP Zero Window: Der Empfänger ruft um Hilfe: „Mein Puffer ist zu 100 % voll, bitte sende keine Daten mehr!” Hier ist das System des Empfängers überlastet – z. B. durch eine langsame Festplatte oder hohe CPU-Last – und bremst den Sender aktiv aus.

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 drei Haupttäter in Unternehmensnetzen:

1. Firewalls und Middleboxes

Das ist mit Abstand der häufigste Fehler. Moderne Next-Generation Firewalls (NGFW), Load Balancer oder WAN-Optimierer inspizieren den Traffic. In einigen – meist älteren oder restriktiv konfigurierten – Setups sind Firewalls so eingestellt, dass sie unbekannte oder als unsicher eingestufte TCP-Optionen rigoros aus den Headern entfernen („TCP Option Stripping”).

Wenn die Firewall beim Handshake die Window-Scaling-Option aus dem SYN-Paket löscht, fällt die Kommunikation gnadenlos auf das harte 64-KB-Limit zurück. Die Folge: massiver Performance-Verlust.

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? Der TCP-Algorithmus interpretiert einen Paketverlust grundsätzlich als Anzeichen für Stau im Netzwerk.

Um das Überlastverhalten nicht weiter zu verschlimmern, halbiert der Sender sofort sein Congestion Window und verfällt in einen Recovery-Modus. Wir sehen in Wireshark dann gehäuft TCP Retransmissions. Selbst eine sehr geringe Verlustrate von 0,1 % reicht aus, um auf Hochgeschwindigkeitsstrecken den Durchsatz drastisch einbrechen zu lassen – weil das Window nie seine maximale Größe erreicht.

3. Falsche Betriebssystem-Konfigurationen (Legacy Systems)

Obwohl moderne Systeme (Windows 10/11, Windows Server 2019+, aktuelle Linux-Kernel) über ein hervorragendes TCP Auto-Tuning verfügen, treffe ich immer wieder auf „kaputtkonfigurierte” Server. Irgendwann hat mal ein Admin einen Foreneintrag aus dem Jahr 2008 gefunden und statische TCP-Parameter in der Windows-Registry oder via sysctl unter Linux erzwungen. Wenn Auto-Tuning deaktiviert ist, kann sich die Window Size nicht mehr dynamisch an die RTT anpassen.

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 oder eine dedizierte Leitung gebucht wurde. Das Muster ist identisch: Die Bandbreite ist da, aber die Latenz zur nächsten Azure-Region beträgt je nach Standort 10–25 ms, zu US-Regionen schnell 80–120 ms. Ist TCP Window Scaling auf einem der beteiligten Server deaktiviert oder wird es durch ein zwischengeschaltetes Security-Gateway geblockt, greift wieder das harte 64-KB-Limit – und deine teure Cloud-Anbindung liefert nur einen Bruchteil der möglichen Performance.

Besonders tückisch: In Azure und AWS laufen oft Windows Server-Images, die von einem Vorgänger-Admin mit statischen TCP-Parametern „optimiert” wurden. Solche Einstellungen überleben Migrationsprojekte problemlos und vergiften die Performance still und leise.

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 ungewollt manipuliert werden können. Viele SD-WAN-Appliances terminieren TCP-Sessions oder proxyen den Traffic – und nicht alle Implementierungen reichen TCP-Optionen wie Window Scaling korrekt durch. Das Ergebnis: 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 nur eines: ein Wireshark-Capture auf beiden Seiten des SD-WAN-Tunnels. Wenn das Window-Scale-Flag auf der einen Seite gesetzt ist und auf der anderen fehlt, hast du deinen Täter – und weißt, wo du mit dem Vendor sprechen musst.

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 des Drei-Wege-Handshakes. Vergleiche die SYN-Pakete am Sender mit denen, die am Empfänger ankommen.
2. Firewall-Regeln prüfen: Wenn senderseitig das Window-Scale-Flag (WS) gesetzt ist, es beim Empfänger aber fehlt, hast du den Täter. Prüfe das „TCP Options Handling” auf allen Firewalls und Load Balancern entlang der Route. Stelle sicher, dass RFC 1323/7323-Optionen transparent durchgereicht werden.
3. Betriebssystem-Tuning zurücksetzen: Verlass dich auf die modernen OS-Mechanismen. Prüfe unter Windows mit netsh interface tcp show global, ob das „Receive Window Auto-Tuning Level” auf normal steht. Falls es auf disabled steht: Ändere es! Unter Linux prüfst du net.ipv4.tcp_window_scaling = 1.
4. Paketverluste aufspüren: Wenn du viele TCP Retransmissions siehst, prüfe die Interfaces deiner Switches und Router auf Fehler (FCS Errors, Drops, Microburst-Probleme). Das Netzwerk muss sauber laufen, damit TCP sauber skalieren kann.

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 der limitierten TCP Window Size, das wie eine unsichtbare Handbremse wirkt. Durch den gezielten Einsatz von Wireshark kannst du diese Mechanismen sichtbar machen, blockierende Security-Gateways identifizieren und Konfigurationsfehler beheben. Ein sauberes Netzwerkanalyse-Setup erspart dir wochenlange Rätselraten und Fingerzeig-Spielchen zwischen den IT-Abteilungen.

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 – wenn du eine professionelle Analyse deines Netzwerks oder Unterstützung bei der Wireshark-Auswertung benötigst, stehe ich und mein Team dir gerne als erfahrene IT-Consultants zur Seite. Sprich uns an und lass uns gemeinsam in deine Pakete schauen!

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

Was ist das TCP Window?

Das TCP Window ist der verfügbare Speicherplatz (Empfangspuffer), den ein Empfänger dem Sender in einem Netzwerk-Paket mitteilt. Es gibt an, wie viele Daten der Sender unbestätigt – also ohne auf ein Acknowledgment zu warten – verschicken darf. Je größer dieser Puffer, desto mehr Daten können gleichzeitig „unterwegs” sein, was die Geschwindigkeit auf Strecken mit hoher Latenz maßgeblich beeinflusst.

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

Das liegt meistens am Bandwidth-Delay Product (BDP). Wenn du eine Verbindung mit hoher Latenz (z. B. 50 ms) hast, müssen Sender und Empfänger in der Lage sein, große Datenmengen unbestätigt zu übertragen. Wenn die TCP Window Size künstlich begrenzt ist – z. B. weil eine Firewall die TCP-Option „Window Scaling” blockiert –, sinkt dein Durchsatz physikalisch bedingt auf wenige Megabit pro Sekunde, egal wie groß deine Leitung ist.

Was bedeutet „TCP Zero Window” in Wireshark?

Die Meldung „TCP Zero Window” bedeutet, dass der Empfangspuffer des Zielsystems komplett voll ist (0 Bytes freier Speicher). Das Zielsystem sendet diese Nachricht aktiv an den Sender: „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-Server überlastet ist – durch hohe CPU-Auslastung, langsame Storage oder eine blockierte Anwendung.

Wie erkenne ich Paketverluste in Wireshark?

Paketverluste erkennst du in Wireshark an TCP Retransmissions (Neuübertragungen) oder „Dup ACKs” (Duplicate Acknowledgements). Diese Fehler zeigen, dass Pakete auf dem Weg verloren gegangen sind und der TCP-Algorithmus das Congestion-Verhalten eingeleitet hat – was die Geschwindigkeit drosselt und zu spürbaren Performance-Einbrüchen führt.

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 lösen das automatisch über TCP Auto-Tuning: Windows passt die Window Size dynamisch an, Linux über den Cubic- oder BBR-Algorithmus. Die beste Empfehlung lautet daher: Lass das Betriebssystem seinen Job machen und stelle sicher, dass nichts – weder Firewalls noch manuelle Registry-Einträge – das Auto-Tuning blockiert.