TCP Zero Window via proxy: identifiera mottagaren

En paketdump visar TCP ZeroWindow. Innan du ändrar en kernelinställning behöver du avgöra vilken endpoint som annonserar nollvärdet.

Den endpointen beskriver sin mottagningskapacitet på just den TCP-anslutningen. Den säger inte hur mycket bandbredd hela proxyn har tillgänglig. En zero-window-probe låter avsändaren ta reda på om den annonserade kapaciteten har ändrats; själva proben bevisar varken paketförlust eller en trasig proxy.

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

Detta är två separata TCP-samtal. Anta att webbläsaren slutar läsa ett stort svar och annonserar noll på A. Proxyn kan till slut sluta hämta från B när dess egna buffertar fylls. Ett senare zero window på B kan vara en följd av den långsamma klienten snarare än grundproblemet.

Det motsatta kan inträffa vid en uppladdning. Om målapplikationen slutar konsumera data kan dess fönster på B stängas. Trycket kan då vandra tillbaka mot klienten genom proxyns buffertar.

Sätt observationerna i ordning

1. Notera anslutningens endpoints och riktningen för den påverkade dataöverföringen.
2. Avgör vilken endpoint som först annonserade ett krympande eller nollställt mottagningsfönster.
3. Kontrollera om dess applikation läste, stod stilla i en annan operation eller begränsades av resurser.
4. Jämför tidpunkterna på proxyns andra anslutning innan du utser den ursprungliga orsaken.

Wiresharks fönsteranalysetiketter är användbara tolkningar av dumpen, inte en instruktion att öka varje mottagningsbuffert. Även window scaling måste tolkas utifrån anslutningens förhandling.

Att prova en annan endpoint från en proxylista och se överföringen återhämta sig är ett användbart bevis på att vägen ändrades. Det bevisar i sig inte att ett operativsystems TCP-implementation var defekt. Håll förklaringen knuten till mottagarprocessen och den anslutning där väntan började.