Ich brauche eigentlich nur Hilfe beim Verständnis des folgenden Bildes, werde aber den Hintergrund für den Kontext erläutern.
Wir haben eine App, die so konfiguriert ist, dass sie einen Proxy auf Port 8080 verwendet und Internetzugang erfordert. Zu zufälligen Zeiten im Laufe des Tages kann die App keine Verbindung herstellen und stürzt einfach ab. Wir versuchen, die Ursache herauszufinden. Wir haben FW- und Proxy-URL-Regeln ausgeschlossen (es stößt immer auf dieselbe URL, wenn es funktioniert und trotzdem fehlschlägt). Ich denke, das Problem ist netzwerkbezogen oder hat mit der Leistung des Proxys selbst zu tun. Um der Sache auf den Grund zu gehen, habe ich Netzwerkaufzeichnungen gemacht, wenn es passiert.
Wenn Sie sich das folgende Bild ansehen, sehen Sie einen Ausschnitt, aus dem die IP-Details entfernt wurden. Die erste Zeile mit der Quelle „42“ ist der Client-Computer, der eine TLS-Anforderung über den Proxy (IP 35) auf Port 8080 stellt. HINWEIS: Normalerweise funktioniert es und fordert dieselbe URL/IP an, aber dies ist einer der Fälle, in denen es fehlgeschlagen ist. Das untere Fenster enthält die Details der ersten grünen Zeile.
Der hervorgehobene Teil „Nächste Sequenznummer“ entspricht der ACK des letzten zurückgegebenen Pakets von 35 (vorletzte Zeile). Dies ist im Wesentlichen die Antwort von 35 an den Client, dass er alle an ihn gesendeten Daten empfangen hat (das heißt, das Gerät ist aktiv, da es den Empfang der Daten bestätigt (d. h. es liegen keine FW- oder Netzwerkprobleme vor)). Beachten Sie jedoch, dass es keine Daten zurücksendet. Unmittelbar danach gibt der Client ein TCP RST aus. Hier ist meine Interpretation, aber ich hätte gerne, dass jemand das überprüft, da meine TCP-Kenntnisse etwas eingerostet sind.
Der Client sendet eine Art Anfrage an den Proxy, aber aus irgendeinem Grund antwortet der Proxy nicht (auf der Anwendungsebene). Da der Proxy mit TCP-ACKs antwortet, bedeutet dies, dass auf der Netzwerkebene alles in Ordnung ist. Dies würde bedeuten, dass der Proxy die Verbindung trennt, wenn die Daten über den Netzwerkstapel an den Proxy selbst weitergeleitet werden. Warum das so ist, weiß ich noch nicht, aber ich suche nach einer Klarstellung, damit ich mit dem Proxy-Team sprechen und ihnen sagen kann, dass sie dies untersuchen müssen (sie glauben nicht, dass es der Proxy ist).
Ein weiterer Beweis, der meinen Fall stützt, ist, dass die ersten 4 Zeilen, die Sie im Bild vor dem RST sehen, viele Male wiederholt werden. Dies bedeutet wiederum, dass der Client seine Anfrage erneut sendet, aber nie eine Antwort erhält. Und dann gibt er schließlich auf und führt einen Reset aus.
Offenbar sitzt vor dem Proxy ein Load Balancer, und der Proxy besteht eigentlich aus mehreren Maschinen. Ich habe das Gefühl, dass es bei einem davon im Backend ein Problem gibt und der Load Balancer den Knoten nicht aus dem Pool entfernt und die Daten daher möglicherweise an ein schwarzes Loch sendet.
Ich möchte eine zweite Meinung hören: Sieht die Zusammenfassung oben auf Grundlage der Aufnahme richtig aus?
Antwort1
Unmittelbar danach sendet der Client ein TCP RST
Nicht sofort. Der RST wird vom Client 30 Sekunden nach dem Senden der letzten ACK vom Server gesendet.
... die ersten 4 Zeilen, die Sie im Bild vor dem RST sehen, werden viele Male wiederholt
Dies sind nicht dieselben Zeilen. Sie haben einen anderen Wert für ACK.
Meine Interpretation hier ist, dass der Client eine Anfrage mit einer größeren Nutzlast sendet (daher die mehrfachen ACKs vom Server, um dies zu bestätigen) und dann erwartet, dass der Proxy die Antwort zurücksendet. Nach 30 Sekunden ohne Antwort gibt der Client auf und schließt die Verbindung mit RST.
Es ist nicht klar, warum der Proxy keine Antwort sendet. Es könnte ein Problem des Proxys sein. Es könnte aber auch ein Problem des Upstream-Servers sein und der Server gibt das Problem einfach an den Client weiter.
Beachten Sie jedoch, dass die Interpretation falsch sein kann. Es wird nicht viel Kontext und Paketerfassung bereitgestellt, es handelt sich also eher um eine fundierte Vermutung.