Liest das empfangende Programm den Socket nicht rechtzeitig und läuft der Puffer voll, stellt der Sender die Übertragung ein und schickt nur noch Zero-Window-Probes. Die Leitung ist in Ordnung.
Warum Socket wird nicht gelesen, weil Frames auf dem Client hängen oder ein Server-Thread blockiert ist → Folge Receive Window fällt auf 0, der Sender stellt die Übertragung ein und schickt nur Probes (in immer größeren Abständen) → Auf dem Bildschirm Freeze, dann Zeitraffer. Im Paketmitschnitt ist „ZeroWindow“ zu sehen, Verluste gibt es keine
Im Paketmitschnitt zuerst die Seite prüfen, die ZeroWindow gesendet hat (die Seite, die den Socket nicht liest), Netzwerkempfang in einem eigenen Thread fortlaufend lesen, Empfangspuffer angemessen dimensionieren. Client: Ursachen hängender Frames wie Laden oder GC beheben. Server: Ursachen dafür beheben, dass der Thread blockiert, der den Socket liest.
Aufgaben Infrastrukturteam
TcpExtTCPToZeroWindowAdv in nstat auf dem Server (wie oft der Server ein Receive Window von 0 gemeldet hat) ins Monitoring aufnehmen (steigt der Wert, liegt es am Server, dann an die Server-Entwicklung weitergeben), Paketmitschnitte vom Server bereitstellen.
Im Graphen
Lücke, dann alles auf einmal · Empfangsvolumen pro Verbindung, Zero-Window-Ereignisse
Wo nachsehen
Im Paketmitschnitt mit dem Wireshark-Filter tcp.analysis.zero_window die Seite finden, die ein Window von 0 gemeldet hat. In nstat auf dem Server TcpExtTCPToZeroWindowAdv (Server meldet Window 0) und TcpExtTCPWinProbe (Probe auf das Window 0 der Gegenseite gesendet) getrennt betrachten und Recv-Q der Server-Sockets prüfen (in ss die Bytes, die das Programm noch nicht gelesen hat)
Spricht dafür
Während des Stillstands keine Retransmissions, nur Zero Windows und Probes. Steigen TcpExtTCPToZeroWindowAdv auf dem Server oder Recv-Q der Server-Sockets, liest der Server nicht rechtzeitig, steigt TcpExtTCPWinProbe, liest der Client nicht rechtzeitig
Spricht dagegen
Kein Zero Window im Mitschnitt, dieselben Daten werden erneut gesendet: Ursache bei Verlust oder unnötiger Retransmission
SNMP counterLinux kernel TcpExtTCPToZeroWindowAdv: wie oft das Receive Window von einem Wert ungleich 0 auf 0 gemeldet wurde
net/ipv4/proc.cLinux kernel In nstat angezeigte Zählernamen TCPToZeroWindowAdv und TCPWinProbe
net/ipv4/tcp_output.cLinux kernel TCPWinProbe: steigt mit jeder Probe (tcp_send_probe0), die bei einem Receive Window von 0 auf der Gegenseite gesendet wird
net/ipv4/tcp_diag.cLinux kernel Recv-Q in ss ist bei Verbindungen die Zahl empfangener Bytes, die das Programm noch nicht gelesen hat
Verwandte Ursachen
Gleiche Schicht: Grundursachen von TCP-Retransmissions