Trasování paketů hlásí TCP ZeroWindow. Než změníte nastavení jádra, určete koncový bod, který nulu oznamuje.

Tento koncový bod popisuje svou přijímací kapacitu na tomto TCP spojení. Neoznamuje, kolik šířky pásma má celý proxy. Sonda nulového okna umožní odesílateli zjistit, zda se oznámená kapacita změnila; samotné sondy neprokazují ztrátu paketů ani rozbitý proxy.

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

Jsou to oddělené TCP rozhovory. Předpokládejme, že prohlížeč přestane číst velkou odpověď a oznámí nulu na A. Proxy může nakonec přestat vypouštět B, jak se jeho buffery plní. Pozdější nulové okno na B může být následkem pomalého klienta, nikoli původním problémem.

Opačná situace je možná při nahrávání. Pokud cílová aplikace přestane spotřebovávat data, její okno na B se může zavřít. Tlak se pak může šířit zpět ke klientovi přes buffery proxy.

Seřaďte pozorování

  1. Zaznamenejte koncové body spojení a směr postiženého přenosu dat.
  2. Určete, který koncový bod jako první oznámil zmenšující se nebo nulové přijímací okno.
  3. Ověřte, zda jeho aplikace četla, byla pozastavena na jiné operaci, nebo omezena zdroji.
  4. Porovnejte časování na druhém spojení proxy, než přiřadíte původní příčinu.

Popisky analýzy oken ve Wiresharku jsou užitečné interpretace záznamu, ne pokyn zvětšit každý přijímací buffer. Škálování okna je také třeba vykládat s ohledem na vyjednávání spojení.

Vyzkoušet jiný koncový bod ze seznamu proxy a vidět, že se přenos obnoví, je užitečný důkaz, že se cesta změnila. Sám o sobě však nedokazuje, že implementace TCP některého operačního systému byla vadná. Držte vysvětlení spojené s přijímajícím procesem a spojením, kde čekání začalo.

Související články