TCP-nulvindue gennem en proxy: identificér modtageren

Et pakkespor siger TCP ZeroWindow. Før du ændrer en kernelindstilling, skal du identificere det endepunkt, der annoncerer nullet.

Det endepunkt beskriver sin modtagelseskapacitet på den TCP-forbindelse. Det annoncerer ikke, hvor meget båndbredde hele proxyen har. En nulvinduesprobe lader afsenderen opdage, om den annoncerede kapacitet er ændret; prober alene godtgør ikke pakketab eller en defekt proxy.

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

Det er separate TCP-samtaler. Antag, at browseren holder op med at læse et stort svar og annoncerer nul på A. Proxyen kan efterhånden holde op med at tømme B, i takt med at dens egne buffere fyldes. Et senere nulvindue på B kan være en følge af den langsomme klient snarere end det oprindelige problem.

Den modsatte situation er mulig under en upload. Hvis destinationsapplikationen holder op med at forbruge data, kan dens vindue på B lukke. Trykket kan derefter vandre tilbage mod klienten gennem proxyens buffere.

Sæt observationerne i rækkefølge

1. Notér forbindelsens endepunkter og retningen af den berørte dataoverførsel.
2. Identificér, hvilket endepunkt der først annoncerede et skrumpende eller nul modtagelsesvindue.
3. Kontrollér, om dens applikation læste, var sat på pause ved en anden operation eller begrænset af ressourcer.
4. Sammenlign timingen på proxyens anden forbindelse, før du udpeger den oprindelige årsag.

Wiresharks vinduesanalysemærkater er nyttige fortolkninger af optagelsen, ikke en instruks om at øge hver modtagelsesbuffer. Vindueskalering skal også fortolkes med forbindelsens forhandling in mente.

At prøve et andet endepunkt fra en proxyliste og se overførslen komme sig er nyttigt bevis for, at vejen ændrede sig. Det beviser ikke i sig selv, at en bestemt operativsystems TCP-implementering var defekt. Hold forklaringen knyttet til modtageprocessen og den forbindelse, hvor ventetiden begyndte.