TCP keep-alive wird nach dem TCP-Zero-Window eingebunden und schließt die Verbindung fälschlicherweise
Dieses Muster passiert sehr häufig zwischen zwei RHEL 6-Boxen, die Daten über eine TCP-Verbindung übertragen. Der Client gibt ein TCP Window Full aus, 0.2 Sekunden später sendet der Client TCP Keepalives, auf die der Server mit ähnlich aussehenden Antworten reagiert. Der Client ist jedoch nicht zufrieden damit und sendet weiter TCP-Keepalives, bis es schließlich die Verbindung mit einem RST fast 9s später schließt.
Dies ist trotz der RHEL-Boxen, die die Standard-TCP-Keepalive-Konfiguration haben
%Vor%was erklärt, dass dies nur bis 2 Stunden Stille erfolgen soll. Liest ich meinen PCAP falsch (relevante Pakete auf Anfrage)?
Unten ist ein Wireshark-Screenshot des Musters, mit meinen eigenen Paketnoten in der Mitte.
M.
3 Antworten
Die Quell- und Ziel-IP-Adressen in den Paketen, die vom Client stammen, stimmen nicht mit den Ziel- und Quell-IP-Adressen in den Antwortpaketen überein, was anzeigt, dass sich zwischen den Feldern NAT befindet. Es ist auch wichtig zu verstehen, wo die Pakete erfasst wurden. Wahrscheinlich hilft eine Paketerfassung auf dem Client selbst, das Problem zu verstehen.
Beachten Sie, dass der Client TCP-Keepalive generieren kann, wenn er zwei Stunden oder länger kein Datenpaket empfängt. Gemäß RFC 1122 versucht der Client Keepalive, wenn er keine Keepalive-Response vom Peer erhält. Es wird schließlich nach einem fortlaufenden Wiederholungsversuch getrennt.
Die NAT-Geräte implementieren normalerweise Verbindungs-Caches, um den Status laufender Verbindungen aufrechtzuerhalten. Wenn die Größe der Verbindung das Limit erreicht, löschen die NAT-Geräte alte Verbindungen, um die neuen Verbindungen zu bedienen. Dies könnte auch zu einem solchen Szenario führen.
Die angegebene Paketerfassung zeigt an, dass eine hohe Wahrscheinlichkeit besteht, dass Pakete den Client nicht erreichen, daher ist es hilfreich, Pakete auf dem Client-Rechner zu erfassen.
Ich lese die Spur etwas anders: Der Sender sendet mehr Daten, als der Empfänger verarbeiten kann, und erhält eine Null-Antwort Der Sender sendet Window Probes (nicht Keepalives, es ist viel zu schnell dafür) und die Anwendung gibt nach 10 Sekunden ohne Fortschritt auf und schließt die Verbindung, das Zurücksetzen zeigt an, dass Daten im TCP-Sendepuffer anstehen. Wenn die Anwendung eine große Blockgröße verwendet, die in den Socket geschrieben wurde, konnte es für mehr als die 10 Sekunden, die in dem tcpdump gesehen werden, keinen Fortschritt gesehen haben.
Wenn dies eine gerade Verbindung ist (keine Proxies usw.), ist der wahrscheinlichste Grund, dass das Empfangen aufhört zu empfangen (oder langsamer ist als die Sender- und Datenübertragung)
Es sieht so aus, als hätte die Paketnummer 249522 die Anwendung auf 10.120.67.113 veranlasst, die Verbindung abzubrechen. Alle Fenster-Probes erhalten eine Null-Fenster-Antwort von 0,132 (ohne Nutzlast) und dann sendet 0,12 (unaufgefordert) Paket 249522 mit 63 Bytes (und zeigt immer noch 0 Fenster an). Das PSH-Flag schlägt vor, dass diese 63 Bytes die gesamten Daten sind, die von der App auf .132 geschrieben werden. Dann antwortet .113 in derselben Millisekunde mit einer RST. Ich kann mir keinen Grund vorstellen, warum der TCP-Stack sofort nach dem Empfang von Daten eine RST senden würde (Sequenznummern sind korrekt). Meiner Ansicht nach ist es fast sicher, dass die App auf .113 entschieden hat, basierend auf der 63-Byte-Nachricht, die von .132 gesendet wurde, aufzugeben.
Tags und Links tcp keep-alive