Ridimensionamento della finestra TCP e analisi PCAP del throughput: debug della finestra di ricezione, della finestra zero, della finestra piena e del trasferimento lento

La lentezza del throughput TCP non è sempre sinonimo di perdita di pacchetti. Può essere la pressione della finestra di ricezione, il ridimensionamento della finestra mancante, i buffer del socket di piccole dimensioni, il ritardo di lettura dell'applicazione, il buffering del proxy, i vincoli VPN o la mancata corrispondenza del prodotto con ritardo di larghezza di banda. Gli utenti cercano "TCP window scaling pcap", "TCP zero window", "TCP window full", "slow download packet capture", "receive window limiting throughput" e "bandwidth delay product TCP analysis" quando i test di velocità sono negativi ma le ritrasmissioni non spiegano il rallentamento.

PCAP Surgery è utile perché i problemi di throughput richiedono il mantenimento delle esatte opzioni di handshake, delle finestre pubblicizzate, dei tempi di ACK, dei burst di payload, delle pause e degli aggiornamenti delle finestre.

Cosa fa il ridimensionamento della finestra TCP

Il campo della finestra TCP ha dimensioni limitate. Il ridimensionamento della finestra consente finestre di ricezione più grandi negoziando un fattore di scala durante lo scambio SYN. Se il ridimensionamento della finestra è mancante, disabilitato, rimosso da un dispositivo o interpretato erroneamente, il throughput può essere limitato sui collegamenti ad alta latenza.

Ciò è particolarmente importante quando la latenza è significativa:

• Trasferimenti WAN.
• Collegamenti VPN.
• Reti satellitari o cellulari.
• Traffico cloud tra regioni.
• Replica di backup a lunga distanza.
• Copia file remota.
• Download HTTP di grandi dimensioni.

Su una LAN locale, una piccola finestra di ricezione potrebbe comunque apparire veloce. Attraverso un percorso ad alta latenza, può diventare il collo di bottiglia.

Prodotto di ritardo della larghezza di banda

Il prodotto di ritardo della larghezza di banda descrive la quantità di dati che devono essere in volo per riempire il percorso. Una connessione con larghezza di banda elevata e tempo di andata e ritorno elevato richiede una finestra più ampia.

Se la finestra di ricezione è troppo piccola, il mittente deve fermarsi e attendere gli ACK invece di mantenere la pipe piena.

Prove di cattura dei pacchetti:

• Il mittente trasmette fino al limite della finestra pubblicizzata.
• Il ricevitore risponde lentamente o pubblicizza una piccola finestra.
• Il throughput forma raffiche e pause.
• Le ritrasmissioni sono basse, ma la velocità è ancora scarsa.
• I pacchetti di aggiornamento delle finestre vengono visualizzati dopo che l'applicazione ha letto i dati.

Si tratta di un collo di bottiglia sul lato ricezione o di controllo del flusso, non di una perdita classica.

Finestra Zero

TCP Zero Window significa che il ricevitore non ha segnalato buffer di ricezione disponibile. Il mittente non può continuare a inviare i dati dell'applicazione finché non arriva un aggiornamento della finestra.

Cause comuni:

• La ricezione dell'applicazione non viene letta abbastanza velocemente.
• Il server è sovraccarico.
• Il client è in pausa o bloccato sul disco.
• I buffer proxy sono pieni.
• Lo stack TLS è sottoposto a contropressione.
• Il client del database o il ricevitore di file è lento.
• La cattura del pacchetto viene effettuata vicino al ricevitore e mostra la pressione locale.

Zero Window non è automaticamente un guasto di rete. Spesso indica la pressione delle applicazioni o delle risorse dell'host.

Finestra piena

"Finestra piena" di solito significa che il mittente ha riempito la finestra pubblicizzata del destinatario. Potrebbe accadere prima di Zero Window. Il mittente è pronto a inviare di più, ma il controllo del flusso lo impedisce.

Cercare:

• Lunghe quantità di dati fino al bordo della finestra.
• Nessuna perdita di pacchetti attorno allo stallo.
• ACK che non avanzano abbastanza nella finestra.
• Il mittente fa una pausa durante l'attesa.
• Aggiornamenti delle finestre seguiti da un'altra raffica.

Questo modello è particolarmente importante per i casi di supporto "caricamento lento" e "download lento".

Opzione scala mancante

Il ridimensionamento della finestra deve essere negoziato durante l'handshake. Se un lato non include l'opzione di ridimensionamento della finestra in SYN o SYN-ACK, la connessione non potrà utilizzare il ridimensionamento in seguito.

Prova:

• Opzioni SYN.
• Opzioni SYN-ACK.
• Valore della scala della finestra.
• Finestra di ricezione iniziale.
• Finestra in scala efficace.
• Comportamento del middlebox che rimuove le opzioni.

Se l'acquisizione inizia dopo l'handshake, il fattore di scala potrebbe essere sconosciuto. Questo è il motivo per cui le tracce di supporto dovrebbero includere l'handshake TCP completo.

La posizione di acquisizione è importante

L'analisi della finestra dipende da dove è stata eseguita l'acquisizione. Una cattura vicino al mittente può mostrare tempi diversi rispetto a una cattura vicino al destinatario. Anche NAT, VPN, proxy e bilanciatori del carico possono dividere le connessioni.

Domande:

• Il pcap è stato acquisito su client, server, firewall o proxy?
• Si tratta di una connessione TCP end-to-end o di due connessioni lato proxy?
• I numeri di sequenza vengono tradotti?
• Gli ACK vengono ritardati dal ricevitore o dalla rete?
• Il proxy pubblicizza una finestra diversa rispetto all'endpoint finale?

PCAP Surgery aiuta a tagliare e confrontare le conversazioni senza perdere le opzioni di stretta di mano.

Evitare false conclusioni sulla perdita di pacchetti

I dashboard del throughput spesso incolpano la perdita di pacchetti. Ma se le ritrasmissioni sono rare e il mittente si ferma ripetutamente nella finestra di ricezione, il vero collo di bottiglia è il controllo del flusso.

Segni che la perdita non è la causa principale:

• Poche ritrasmissioni.
• Nessuna tempesta di ACK duplicati.
• Cicli regolari di aggiornamento delle finestre.
• Il mittente si ferma esattamente nella finestra pubblicizzata.
• La risposta a livello di applicazione è lenta nel consumare dati.

L'articolo dovrebbe indirizzare ricerche come "TCP lento senza perdita di pacchetti" perché questi utenti necessitano di un percorso diagnostico diverso.

Elenco di controllo del debug

Utilizza questo flusso di lavoro:

1. Conservare i pacchetti SYN e SYN-ACK.
2. Registra le opzioni di scala della finestra.
3. Calcola la finestra di ricezione effettiva.
4. Identificare i pacchetti zero-window e window-update.
5. Identifica i periodi con finestre piene.
6. Misura RTT.
7. Confronta i byte in volo con il prodotto del ritardo della larghezza di banda.
8. Controllare separatamente la velocità di ritrasmissione.
9. Prendere nota della posizione di acquisizione.
10. Conserva insieme l'intervallo lento e la stretta di mano.

Diagnosi finale

I problemi di ridimensionamento della finestra TCP e della finestra di ricezione creano trasferimenti lenti senza evidenti perdite di pacchetti. Le prove sono le opzioni di handshake, le finestre di ricezione pubblicizzate, gli eventi a finestra zero, gli aggiornamenti delle finestre, l'RTT e il comportamento di pausa del mittente.

PCAP Surgery aiuta a conservare i pacchetti che dimostrano se il collo di bottiglia è la perdita di rete, la pressione del buffer di ricezione, il ridimensionamento delle finestre mancante, il comportamento del proxy o un'applicazione che non legge abbastanza velocemente.