Okno zerowe TCP przez proxy: zidentyfikuj odbiorcę

Ślad pakietów mówi TCP ZeroWindow. Zanim zmienisz ustawienie jądra, zidentyfikuj punkt końcowy, który ogłasza zero.

Ten punkt końcowy opisuje swoją pojemność odbiorczą na tym połączeniu TCP. Nie ogłasza, ile szerokości pasma ma całe proxy. Sonda okna zerowego pozwala nadawcy sprawdzić, czy ogłoszona pojemność się zmieniła; same sondy nie dowodzą utraty pakietów ani uszkodzonego proxy.

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

To osobne rozmowy TCP. Załóżmy, że przeglądarka przestaje czytać dużą odpowiedź i ogłasza zero na A. Proxy może w końcu przestać opróżniać B, gdy jego własne bufory się zapełnią. Późniejsze okno zerowe na B może być skutkiem wolnego klienta, a nie pierwotnym problemem.

Sytuacja odwrotna jest możliwa podczas wysyłania. Jeśli aplikacja docelowa przestaje zużywać dane, jej okno na B może się zamknąć. Ciśnienie może wtedy wędrować z powrotem do klienta przez bufory proxy.

Uporządkuj obserwacje

1. Zapisz punkty końcowe połączenia i kierunek dotkniętego transferu danych.
2. Zidentyfikuj, który punkt końcowy pierwszy ogłosił kurczące się lub zerowe okno odbiorcze.
3. Sprawdź, czy jego aplikacja czytała, była wstrzymana na innej operacji lub ograniczona zasobami.
4. Porównaj czas na drugim połączeniu proxy, zanim przypiszesz pierwotną przyczynę.

Etykiety analizy okien w Wiresharku to użyteczne interpretacje przechwycenia, a nie polecenie zwiększenia każdego bufora odbiorczego. Skalowanie okna też trzeba interpretować z uwzględnieniem negocjacji połączenia.

Wypróbowanie innego punktu końcowego z listy proxy i zobaczenie, że transfer wraca, to użyteczny dowód, że ścieżka się zmieniła. Samo w sobie nie dowodzi jednak, że implementacja TCP któregoś systemu była wadliwa. Trzymaj wyjaśnienie powiązane z procesem odbierającym i połączeniem, w którym zaczęło się oczekiwanie.