TCP-nullvindu gjennom en proxy: identifiser mottakeren

Et pakkespor sier TCP ZeroWindow. Før du endrer en kjerninnstilling, må du identifisere endepunktet som annonserer nullen.

Det endepunktet beskriver sin mottakskapasitet på den TCP-forbindelsen. Det annonserer ikke hvor mye båndbredde hele proxyen har. En nullvindusprobe lar avsenderen oppdage om den annonserte kapasiteten er endret; prober alene beviser ikke pakketap eller en defekt proxy.

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

Dette er separate TCP-samtaler. Anta at nettleseren slutter å lese et stort svar og annonserer null på A. Proxyen kan etter hvert slutte å tømme B mens dens egne buffere fylles. Et senere nullvindu på B kan være en følge av den trege klienten, ikke det opprinnelige problemet.

Den motsatte situasjonen er mulig under en opplasting. Hvis destinasjonsapplikasjonen slutter å forbruke data, kan vinduet dens på B lukkes. Trykket kan da vandre tilbake mot klienten gjennom proxyens buffere.

Sett observasjonene i rekkefølge

1. Noter forbindelsens endepunkter og retningen på dataoverføringen som er rammet.
2. Identifiser hvilket endepunkt som først annonserte et krympende eller null mottaksvindu.
3. Sjekk om applikasjonen leste, stoppet på en annen operasjon eller var begrenset av ressurser.
4. Sammenlign tidspunktet på proxyens andre forbindelse før du peker på den opprinnelige årsaken.

Wiresharks vindusanalysemerker er nyttige tolkninger av opptaket, ikke en instruks om å øke hver mottaksbuffer. Vindusskalering må også tolkes med forbindelsens forhandling i tankene.

Å prøve et annet endepunkt fra en proxyliste og se at overføringen kommer seg, er nyttig bevis for at veien er endret. Det beviser ikke i seg selv at TCP-implementasjonen til et operativsystem var defekt. Hold forklaringen knyttet til mottaksprosessen og forbindelsen der ventingen begynte.