TCP-Nullfenster durch einen Proxy: den Empfänger bestimmen

Bestimmen Sie die TCP-Flusskontrolle auf der Client- oder Serverseite eines Proxys, bevor Sie einen hängenden Download Fensterskalierung oder Puffergröße zuschreiben.

Ein Paketmitschnitt zeigt TCP ZeroWindow. Bevor Sie eine Kernel-Einstellung ändern, bestimmen Sie den Endpunkt, der die Null meldet.

Dieser Endpunkt beschreibt seine Empfangskapazität auf dieser TCP-Verbindung. Er kündigt nicht an, wie viel Bandbreite der gesamte Proxy hat. Eine Nullfenster-Sonde lässt den Sender erkennen, ob sich die angekündigte Kapazität geändert hat; Sonden allein belegen weder Paketverlust noch einen defekten Proxy.

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

Das sind getrennte TCP-Gespräche. Angenommen, der Browser hört auf, eine große Antwort zu lesen, und meldet auf A eine Null. Der Proxy kann schließlich aufhören, B abzuführen, während sich seine eigenen Puffer füllen. Ein späteres Nullfenster auf B kann eine Folge des langsamen Clients sein und nicht das ursprüngliche Problem.

Die umgekehrte Lage ist bei einem Upload möglich. Hört die Zielanwendung auf, Daten zu verbrauchen, kann sich ihr Fenster auf B schließen. Der Druck kann dann über die Puffer des Proxys zum Client zurückwandern.

Beobachtungen in eine Reihenfolge bringen

  1. Notieren Sie die Endpunkte der Verbindung und die Richtung der betroffenen Datenübertragung.
  2. Bestimmen Sie, welcher Endpunkt zuerst ein schrumpfendes oder nullbasiertes Empfangsfenster gemeldet hat.
  3. Prüfen Sie, ob seine Anwendung las, bei einer anderen Operation pausierte oder durch Ressourcen begrenzt war.
  4. Vergleichen Sie den Zeitverlauf auf der anderen Verbindung des Proxys, bevor Sie die ursprüngliche Ursache zuweisen.

Die Fensteranalyse-Bezeichnungen von Wireshark sind hilfreiche Deutungen des Mitschnitts, keine Anweisung, jeden Empfangspuffer zu vergrößern. Auch die Fensterskalierung muss mit Blick auf die Aushandlung der Verbindung gedeutet werden.

Einen anderen Endpunkt aus einer Proxy-Liste zu probieren und zu sehen, dass die Übertragung sich erholt, ist ein nützlicher Beleg dafür, dass sich der Pfad geändert hat. Für sich genommen beweist es nicht, dass die TCP-Implementierung eines Betriebssystems fehlerhaft war. Binden Sie die Erklärung an den empfangenden Prozess und an die Verbindung, in der das Warten begann.

Ähnliche Artikel