Analyse TCP Nagle et ACK PCAP retardé : latence des petits paquets, blocages de 40 ms et applications de requête/réponse lentes

Certaines applications TCP semblent lentes même sans perte de paquets, avec un processeur faible et une bande passante saine. La cause peut être l'interaction entre l'algorithme de Nagle et le comportement ACK retardé. Les utilisateurs recherchent « TCP Nagle retardé ACK pcap », « délai TCP de 40 ms », « latence des petits paquets », « capture de paquets TCP_NODELAY », « réponse lente à la demande TCP » et « pourquoi TCP attend-il avant d'envoyer de petits paquets » lorsqu'un protocole interactif se bloque sur de petites écritures.

La chirurgie PCAP est utile car ce problème est entièrement basé sur le timing. Vous devez conserver les horodatages des paquets, la taille des charges utiles, le timing ACK, la direction et les limites des messages d'application.

Ce que fait Nagle

L'algorithme de Nagle réduit la surcharge des petits paquets en retenant les petites écritures lorsqu'il y a déjà des données non reconnues en vol. Pour le transfert en masse, cela peut être efficace. Pour les protocoles de requête/réponse interactifs qui envoient de nombreux petits messages, cela peut introduire une latence visible.

Le modèle typique :

1. L'application envoie un petit segment.
2. Une autre petite écriture est prête.
3. L'expéditeur attend un ACK avant d'en envoyer davantage.
4. Le récepteur retarde l'ACK dans l'espoir de le récupérer.
5. Les deux parties attendent brièvement.

Ce retard peut ressembler à une mystérieuse pause d’application.

Ce que fait l'ACK retardé

L'ACK retardé permet au récepteur d'attendre avant d'accuser réception des données, souvent pour réduire le trafic ACK ou superposer les ACK sur les données de réponse. Il s'agit d'un comportement TCP normalement valide.

Le problème apparaît lorsque :

• L'expéditeur attend à cause de Nagle.
• Le récepteur attend en raison d’un ACK retardé.
• L'application attend le deuxième petit segment.
• Aucune partie n’envoie suffisamment de données pour interrompre immédiatement l’attente.

La capture des paquets montre un écart répété, souvent autour d'un petit délai fixe.

Symptômes courants

Les chercheurs décrivent souvent :

• "TCP n'a aucune perte de paquets mais l'application est lente."
• "Chaque demande a un délai de 40 ms."
• "Les petites écritures sont lentes."
• "Désactivation de la latence fixe TCP_NODELAY."
• "Le protocole de base de données est lent sur VPN."
• "L'interface utilisateur à distance est lente avec de nombreux petits paquets."
• "Les appels RPC présentent des intervalles étranges."
• "La latence ne se produit que sous Linux sur Windows."

La cause première peut être liée aux options de socket, aux modèles d'écriture de l'application ou à la stratégie ACK du récepteur.

Preuve par paquets

Rechercher:

• Petites charges utiles TCP.
• Un côté envoie moins de MSS.
• Le deuxième message d'application est retardé.
• ACK arrive après un intervalle fixe de type minuterie.
• Aucune retransmission n'a lieu.
• La fenêtre n'est pas pleine.
• Le RTT est inférieur au décrochage observé.
• Le débit n’est pas le principal goulot d’étranglement.

Cela différencie Nagle/ACK retardé de la perte, de la congestion, du délai DNS, de la négociation TLS et du temps de traitement du serveur.

Protocoles de requête/réponse

Les protocoles interactifs sont particulièrement sensibles :

• Requêtes de base de données.
• Cadrage RPC.
• Protocoles de type Telnet.
• Protocoles de contrôle industriel personnalisés.
• Canaux de contrôle du bureau à distance.
• Passerelles de trading financier.
• Bibliothèques clientes HTTP bavardes.
• Protocoles de commande orientés ligne.

Si une application envoie des en-têtes, des champs de longueur et des fragments de corps sous forme de petites écritures distinctes, la trace des paquets peut révéler une latence évitable.

TCP_NODELAY et traitement par lots d'applications

La désactivation de Nagle avec TCP_NODELAY peut réduire la latence de certaines applications interactives. Mais ce n’est pas toujours la meilleure solution.

Les options incluent :

• Activez TCP_NODELAY pour les petits messages sensibles à la latence.
• Lot de petites écritures dans une seule application.
• Vider uniquement les trames de protocole complètes.
• Évitez les modèles d'écriture-écriture-lecture avec de petits segments.
• Ajustez le comportement ACK retardé si la plate-forme le permet.
• Gardez Nagle activé pour les transferts groupés.

Le pcap devrait guider la décision.

Faux diagnostics

Ce problème est souvent diagnostiqué à tort comme :

• Perte de paquets.
• CPU du serveur lent.
• Frais généraux TLS.
• Latence Wi-Fi.
• Encombrement du VPN.
• Retard DNS.
• Problème MTU.

Cela peut être réel dans d'autres cas, mais si la trace montre des écarts cohérents entre petits paquets sans retransmissions, l'interaction envoi TCP/ACK mérite attention.

Exigences de capture

Pour une analyse utile, conservez :

• Prise de contact TCP.
• Première demande lente.
• Tailles de charge utile.
• Horodatage des paquets en haute résolution.
• Paquets ACK uniquement.
• Direction de chaque segment.
• Horodatages du journal des applications, si disponibles.
• Connaissance des options de prise si disponible.

Ne coupez pas les petits espaces vides. Ils en sont la preuve.

Liste de contrôle de débogage

Utilisez ce flux de travail :

1. Identifiez les écarts de latence répétés.
2. Mesurez la durée de l’écart.
3. Vérifiez si les charges utiles sont petites.
4. Vérifiez si l'expéditeur dispose de données non reconnues.
5. Vérifiez le timing ACK.
6. Confirmer qu'aucune retransmission explique l'écart.
7. Comparez avec RTT.
8. Testez le traitement par lots d'écriture de l'application.
9. Testez TCP_NODELAY le cas échéant.
10. Conserver avant/après les pcaps.

Diagnostic final

Les problèmes TCP Nagle et ACK retardé sont des problèmes de synchronisation et de petites écritures, et non des problèmes de bande passante. Les preuves importantes sont les segments minuscules, le délai ACK, le comportement d’attente de l’expéditeur et les écarts de latence fixes répétés.

PCAP Surgery aide à préserver et à comparer la synchronisation des paquets nécessaire pour prouver si une application de requête/réponse lente est bloquée par le comportement des petits paquets TCP.