Finestra zero TCP attraverso un proxy: identificare il ricevente
Individuate il controllo di flusso TCP sul lato client o server di un proxy prima di attribuire un download bloccato alla scalatura della finestra o alla dimensione del buffer.
Una cattura di pacchetti dice TCP ZeroWindow. Prima di cambiare un'impostazione del kernel, identificate l'estremità che annuncia lo zero.
Quell'estremità descrive la propria capacità di ricezione su quella connessione TCP. Non annuncia quanta larghezza di banda abbia l'intero proxy. Una sonda di finestra zero consente al mittente di scoprire se la capacità annunciata è cambiata; le sonde da sole non dimostrano perdita di pacchetti né un proxy guasto.
browser <-- TCP A --> proxy <-- TCP B --> website
Sono conversazioni TCP separate. Supponiamo che il browser smetta di leggere una risposta grande e annunci zero su A. Il proxy può alla fine smettere di svuotare B man mano che i suoi buffer si riempiono. Una finestra zero successiva su B può essere una conseguenza del client lento, non il problema originale.
La situazione inversa è possibile durante un caricamento. Se l'applicazione di destinazione smette di consumare dati, la sua finestra su B può chiudersi. La pressione può allora risalire verso il client attraverso i buffer del proxy.
Mettete in ordine le osservazioni
- Annotate gli estremi della connessione e la direzione del trasferimento interessato.
- Identificate quale estremità ha annunciato per prima una finestra di ricezione che si restringe o è zero.
- Verificate se la sua applicazione stava leggendo, era in pausa su un'altra operazione o limitata dalle risorse.
- Confrontate la tempistica sull'altra connessione del proxy prima di attribuire la causa originale.
Le etichette di analisi delle finestre di Wireshark sono interpretazioni utili della cattura, non un'istruzione ad aumentare ogni buffer di ricezione. Anche la scalatura della finestra va interpretata tenendo conto della negoziazione della connessione.
Provare un'altra estremità da un elenco di proxy e vedere il trasferimento riprendersi è una prova utile che il percorso è cambiato. Da sola, però, non dimostra che l'implementazione TCP di un sistema operativo fosse difettosa. Tenete la spiegazione legata al processo ricevente e alla connessione in cui è iniziata l'attesa.