Snimka paketa pokazuje TCP ZeroWindow. Prije nego promijenite postavku kernela, prepoznajte krajnju točku koja oglašava nulu.

Ta krajnja točka opisuje svoj kapacitet primanja na toj TCP vezi. Ne oglašava koliko propusnosti ima cijeli proxy. Sonda nultog prozora omogućuje pošiljatelju da otkrije je li se oglašeni kapacitet promijenio; same sonde ne dokazuju gubitak paketa ni pokvaren proxy.

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

To su odvojeni TCP razgovori. Pretpostavimo da preglednik prestane čitati veliki odgovor i oglašava nulu na A. Proxy može naposljetku prestati prazniti B kako se njegovi međuspremnici pune. Kasniji nulti prozor na B može biti posljedica sporog klijenta, a ne izvorni problem.

Obrnuta je situacija moguća tijekom prijenosa prema poslužitelju. Ako odredišna aplikacija prestane trošiti podatke, njezin se prozor na B može zatvoriti. Pritisak tada može putovati natrag prema klijentu kroz međuspremnike proxyja.

Poredajte opažanja

  1. Zabilježite krajnje točke veze i smjer pogođenog prijenosa podataka.
  2. Prepoznajte koja je krajnja točka prva oglašavala prozor primanja koji se smanjuje ili je nula.
  3. Provjerite je li njezina aplikacija čitala, zastala na drugoj radnji ili bila ograničena resursima.
  4. Usporedite vrijeme na drugoj vezi proxyja prije nego dodijelite izvorni uzrok.

Oznake analize prozora u Wiresharku korisna su tumačenja snimke, a ne uputa da povećate svaki međuspremnik primanja. Skaliranje prozora također treba tumačiti s obzirom na pregovaranje veze.

Isprobavanje druge krajnje točke s popisa proxyja i opažanje da se prijenos oporavlja koristan je dokaz da se put promijenio. Samo po sebi ne dokazuje da je TCP implementacija nekog operacijskog sustava bila neispravna. Držite objašnjenje vezano uz proces primanja i vezu u kojoj je čekanje počelo.

Povezani članci