Fereastra zero TCP printr-un proxy: identificați receptorul

O urmărire de pachete arată TCP ZeroWindow. Înainte de a modifica o setare a nucleului, identificați capătul care anunță zero.

Acel capăt își descrie capacitatea de recepție pe acea conexiune TCP. Nu anunță câtă lățime de bandă are întregul proxy. O sondă de fereastră zero îi permite expeditorului să afle dacă capacitatea anunțată s-a schimbat; sondele singure nu dovedesc pierderea de pachete sau un proxy defect.

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

Sunt conversații TCP separate. Să presupunem că browserul nu mai citește un răspuns mare și anunță zero pe A. Proxy-ul poate în cele din urmă să nu mai golească B pe măsură ce bufferele proprii se umplu. O fereastră zero ulterioară pe B poate fi o consecință a clientului lent, nu problema inițială.

Situația inversă este posibilă în timpul unei încărcări. Dacă aplicația de destinație nu mai consumă date, fereastra ei pe B se poate închide. Presiunea poate călători apoi înapoi spre client prin bufferele proxy-ului.

Puneți observațiile în ordine

1. Notați capetele conexiunii și direcția transferului afectat.
2. Identificați care capăt a anunțat primul o fereastră de recepție care se micșorează sau este zero.
3. Verificați dacă aplicația sa citea, era oprită la altă operațiune sau limitată de resurse.
4. Comparați momentul pe cealaltă conexiune a proxy-ului înainte de a stabili cauza inițială.

Etichetele de analiză a ferestrelor din Wireshark sunt interpretări utile ale capturii, nu o instrucțiune de a mări fiecare buffer de recepție. Nici scalarea ferestrei nu trebuie interpretată fără a ține cont de negocierea conexiunii.

Încercarea altui capăt dintr-o listă de proxy-uri și vederea recuperării transferului este o dovadă utilă că traseul s-a schimbat. Totuși, singură, nu dovedește că implementarea TCP a unui sistem de operare era defectă. Legați explicația de procesul care recepționează și de conexiunea în care a început așteptarea.