TCP-nullvindauge gjennom ein proxy: identifiser mottakaren

Eit pakkespor seier TCP ZeroWindow. Før du endrar ei kjerneinnstilling, må du identifisere endepunktet som kunngjer nullen.

Det endepunktet skildrar mottakskapasiteten sin på den TCP-tilkoplinga. Det kunngjer ikkje kor mykje bandbreidd heile proxyen har. Ei nullvindaugesond lèt sendaren oppdage om den kunngjorde kapasiteten er endra; sønder åleine provar ikkje pakketap eller ein defekt proxy.

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

Dette er separate TCP-samtalar. Føreset at nettlesaren sluttar å lese eit stort svar og kunngjer null på A. Proxyen kan etter kvart slutte å tøme B medan eigne buffer fyllest. Eit seinare nullvindauge på B kan vere ei følgje av den trege klienten, ikkje det opphavlege problemet.

Den motsette situasjonen er mogleg under ein opplasting. Viss målapplikasjonen sluttar å bruke data, kan vindauget hans på B lukkast. Trykket kan då vandre tilbake mot klienten gjennom buffera til proxyen.

Set observasjonane i rekkjefølgje

1. Skriv ned endepunkta til tilkoplinga og retninga på dataoverføringa som er råka.
2. Finn ut kva endepunkt som først kunngjorde eit minkande eller null mottaksvindauge.
3. Sjekk om applikasjonen las, stoppa på ein annan operasjon eller var avgrensa av ressursar.
4. Samanlikn tidspunktet på den andre tilkoplinga til proxyen før du peikar på den opphavlege årsaka.

Vindaugeanalysemerka i Wireshark er nyttige tolkingar av opptaket, ikkje ei pålegg om å auke kvar mottaksbuffer. Vindusskalering må òg tolkast med tilkoplinga sine forhandlingar i tankane.

Å prøve eit anna endepunkt frå ei proxyliste og sjå at overføringa kjem seg, er nyttig prov på at vegen er endra. Det provar likevel ikkje i seg sjølv at TCP-implementasjonen til eit operativsystem var defekt. Hald forklaringa knytt til mottaksprosessen og tilkoplinga der ventinga byrja.