Analisi TCP Nagle e ACK PCAP ritardato: latenza di pacchetti piccoli, stalli di 40 ms e app di richiesta/risposta lente

Alcune applicazioni TCP risultano lente anche senza perdita di pacchetti, CPU bassa e larghezza di banda sana. La causa può essere l'interazione tra l'algoritmo di Nagle e il comportamento ACK ritardato. Gli utenti cercano "TCP Nagle ritardato ACK pcap", "ritardo TCP di 40 ms", "latenza di pacchetti piccoli", "acquisizione di pacchetti TCP_NODELAY", "risposta lenta alla richiesta TCP" e "perché TCP attende prima di inviare pacchetti di piccole dimensioni" quando un protocollo interattivo si blocca su piccole scritture.

La chirurgia PCAP è utile perché questo problema è interamente basato sui tempi. È necessario preservare la data e l'ora dei pacchetti, le dimensioni del carico utile, i tempi di ACK, la direzione e i limiti dei messaggi dell'applicazione.

Cosa fa Nagle

L'algoritmo di Nagle riduce il sovraccarico dei piccoli pacchetti trattenendo piccole scritture quando ci sono già dati non riconosciuti in volo. Per il trasferimento in blocco, questo può essere efficiente. Per i protocolli di richiesta/risposta interattivi che inviano molti piccoli messaggi, può introdurre una latenza visibile.

Lo schema tipico:

1. L'applicazione invia un piccolo segmento.
2. Un'altra piccola scrittura è pronta.
3. Il mittente attende un ACK prima di inviarne altri.
4. Il ricevitore ritarda l'ACK sperando di trasportarlo sulle spalle.
5. Entrambe le parti aspettano brevemente.

Questo ritardo può sembrare una misteriosa pausa dell'applicazione.

Cosa fa l'ACK ritardato

L'ACK ritardato consente al ricevitore di attendere prima di riconoscere i dati, spesso per ridurre il traffico ACK o ACK piggyback sui dati di risposta. Questo è normalmente un comportamento TCP valido.

Il problema si presenta quando:

• Il mittente attende a causa di Nagle.
• Il ricevitore attende a causa di un ACK ritardato.
• L'applicazione attende il secondo piccolo segmento.
• Nessuna parte invia dati sufficienti per interrompere immediatamente l'attesa.

L'acquisizione del pacchetto mostra un intervallo ripetuto, spesso attorno a un piccolo ritardo fisso.

Sintomi comuni

Gli utenti spesso descrivono:

• "Il TCP non ha perdite di pacchetti ma l'app è lenta."
• "Ogni richiesta ha un ritardo di 40 ms."
• "Le scritture piccole sono lente."
• "Disattivazione della latenza fissa TCP_NODELAY."
• "Protocollo database lento su VPN."
• "IU remota lenta con molti pacchetti piccoli."
• "Le chiamate RPC presentano strane lacune."
• "La latenza si verifica solo da Linux a Windows."

La causa principale potrebbe essere rappresentata dalle opzioni socket, dai modelli di scrittura dell'applicazione o dalla politica ACK del ricevitore.

Prova del pacchetto

Cercare:

• Piccoli payload TCP.
• Un lato invia meno di MSS.
• Il secondo messaggio dell'applicazione è in ritardo.
• L'ACK arriva dopo un intervallo fisso simile a un timer.
• Non avviene alcuna ritrasmissione.
• La finestra non è piena.
• L'RTT è inferiore allo stallo osservato.
• La produttività non è il collo di bottiglia principale.

Ciò differenzia l'ACK Nagle/ritardato dalla perdita, dalla congestione, dal ritardo DNS, dalla negoziazione TLS e dal tempo di elaborazione del server.

Protocolli di richiesta/risposta

I protocolli interattivi sono particolarmente sensibili:

• Interrogazioni del database.
• Inquadratura RPC.
• Protocolli simili a Telnet.
• Protocolli di controllo industriale personalizzati.
• Canali di controllo del desktop remoto.
• Gateway di trading finanziario.
• Librerie client HTTP chiacchieroni.
• Protocolli di comando orientati alla linea.

Se un'applicazione invia intestazioni, campi di lunghezza e frammenti di corpo come piccole scritture separate, la traccia del pacchetto potrebbe rivelare una latenza evitabile.

TCP_NODELAY e batch di applicazioni

Disabilitare Nagle con TCP_NODELAY può ridurre la latenza per alcune applicazioni interattive. Ma non è sempre la soluzione migliore.

Le opzioni includono:

• Abilita "TCP_NODELAY" per piccoli messaggi sensibili alla latenza.
• Scritture batch di piccole dimensioni in un'unica scrittura dell'applicazione.
• Svuota solo i frame di protocollo completi.
• Evitare schemi di scrittura-scrittura-lettura con segmenti piccoli.
• Ottimizza il comportamento ACK ritardato se la piattaforma lo consente.
• Mantieni Nagle abilitato per i trasferimenti collettivi.

Il pcap dovrebbe guidare la decisione.

False diagnosi

Questo problema viene spesso diagnosticato erroneamente come:

• Perdita di pacchetti.
• CPU del server lenta.
• TLS in testa.
• Latenza Wi-Fi.
• Congestione della VPN.
• Ritardo DNS.
• Problema MTU.

Ciò potrebbe essere reale in altri casi, ma se la traccia mostra gap consistenti di piccoli pacchetti senza ritrasmissioni, l'interazione TCP send/ACK merita attenzione.

Requisiti di acquisizione

Per un'analisi utile conservare:

• Stretta di mano TCP.
• Prima richiesta lenta.
• Dimensioni del carico utile.
• Timestamp dei pacchetti ad alta risoluzione.
• Pacchetti solo ACK.
• Direzione di ciascun segmento.
• Timestamp del registro dell'applicazione, se disponibili.
• Conoscenza dell'opzione socket, se disponibile.

Non tagliare i piccoli spazi vuoti. Sono le prove.

Elenco di controllo del debug

Utilizza questo flusso di lavoro:

1. Identificare i gap di latenza ripetuti.
2. Misurare la durata del gap.
3. Controlla se i carichi utili sono piccoli.
4. Controlla se il mittente ha dati non riconosciuti.
5. Controlla i tempi di ACK.
6. La conferma che l'assenza di ritrasmissione spiega il divario.
7. Confronta con RTT.
8. Testare il batch di scrittura dell'applicazione.
9. Prova TCP_NODELAY se appropriato.
10. Conserva i pcap prima/dopo.

Diagnosi finale

I problemi di TCP Nagle e ACK ritardato sono problemi di temporizzazione e piccole scritture, non problemi di larghezza di banda. La prova importante sono i segmenti minuscoli, il ritardo ACK, il comportamento di attesa del mittente e i ripetuti intervalli di latenza fissi.

PCAP Surgery aiuta a preservare e confrontare la tempistica dei pacchetti necessaria per dimostrare se un'applicazione di richiesta/risposta lenta è bloccata dal comportamento dei pacchetti piccoli TCP.