Mise à l'échelle de la fenêtre TCP et analyse PCAP du débit : fenêtre de réception, fenêtre nulle, fenêtre pleine et débogage de transfert lent
Comment analyser la mise à l'échelle de la fenêtre TCP, les limites de la fenêtre de réception, la fenêtre nulle, les événements de fenêtre pleine, le débit lent, le produit de retard de bande passante et les preuves de capture de paquets.
Un débit TCP lent n’est pas toujours synonyme de perte de paquets. Il peut s'agir d'une pression sur la fenêtre de réception, d'une mise à l'échelle manquante de la fenêtre, de petits tampons de socket, d'un retard de lecture d'application, d'une mise en mémoire tampon proxy, de contraintes VPN ou d'une inadéquation de produit de délai de bande passante. Les utilisateurs recherchent « pcap de mise à l'échelle de la fenêtre TCP », « fenêtre TCP zéro », « fenêtre TCP pleine », « capture de paquets de téléchargement lent », « débit limitant la fenêtre de réception » et « analyse TCP du produit de retard de bande passante » lorsque les tests de vitesse sont mauvais mais que les retransmissions n'expliquent pas le ralentissement.
La chirurgie PCAP est utile car les problèmes de débit nécessitent de préserver les options exactes de prise de contact, les fenêtres annoncées, la synchronisation ACK, les rafales de charge utile, les pauses et les mises à jour des fenêtres.
Que fait la mise à l'échelle de la fenêtre TCP
Le champ de la fenêtre TCP est limité en taille. La mise à l'échelle de la fenêtre permet des fenêtres de réception plus grandes en négociant un facteur d'échelle lors de l'échange SYN. Si la mise à l'échelle de la fenêtre est manquante, désactivée, supprimée par un périphérique ou mal interprétée, le débit peut être limité sur les liaisons à latence élevée.
Cela est particulièrement important lorsque la latence est importante :
- Transferts WAN.
- Liens VPN.
- Réseaux satellite ou cellulaire.
- Trafic cloud interrégional.
- Réplication de sauvegarde longue distance.
- Copie de fichiers à distance.
- Téléchargements HTTP volumineux.
Sur un réseau local, une petite fenêtre de réception peut encore paraître rapide. Sur un chemin à latence élevée, cela peut devenir un goulot d'étranglement.
Produit de retard de bande passante
Le produit de délai de bande passante décrit la quantité de données qui doivent être en vol pour remplir le chemin. Une connexion avec une bande passante élevée et un temps d’aller-retour élevé nécessite une fenêtre plus grande.
Si la fenêtre de réception est trop petite, l'expéditeur doit s'arrêter et attendre les ACK au lieu de garder le canal plein.
Preuve de capture de paquets :
- L'expéditeur transmet jusqu'à la limite de fenêtre annoncée.
- Le récepteur acquiert lentement ou annonce une petite fenêtre.
- Le débit forme des rafales et des pauses.
- Les retransmissions sont faibles, mais la vitesse reste médiocre.
- Les paquets de mise à jour de la fenêtre apparaissent après que l'application ait lu les données.
Il s’agit d’un goulot d’étranglement côté réception ou de contrôle de flux, et non d’une perte classique.
Fenêtre zéro
TCP Zero Window signifie que le récepteur n'a annoncé aucun tampon de réception disponible. L'expéditeur ne peut pas continuer à envoyer des données d'application jusqu'à ce qu'une mise à jour de la fenêtre arrive.
Causes courantes :
- La demande de réception ne lit pas assez vite.
- Le serveur est surchargé.
- Le client est en pause ou bloqué sur le disque.
- Les tampons proxy sont pleins.
- La pile TLS est sous pression.
- Le client de base de données ou le récepteur de fichiers est lent.
- La capture de paquets est effectuée à proximité du récepteur et montre la pression locale.
Zero Window n’est pas automatiquement un défaut du réseau. Cela indique souvent une pression sur les applications ou les ressources de l’hôte.
Fenêtre pleine
« Fenêtre pleine » signifie généralement que l'expéditeur a rempli la fenêtre annoncée par le destinataire. Cela peut arriver avant Zero Window. L'expéditeur est prêt à envoyer davantage, mais le contrôle de flux l'en empêche.
Rechercher:
- Longues séries de données jusqu'au bord de la fenêtre.
- Aucune perte de paquets autour du stand.
- ACK qui n’avancent pas suffisamment la fenêtre.
- L'expéditeur fait une pause en attendant.
- Mises à jour de la fenêtre suivies d'une autre rafale.
Ce modèle est particulièrement important pour les cas de support de « téléchargement lent » et de « téléchargement lent ».
Option d'échelle manquante
La mise à l’échelle de la fenêtre doit être négociée lors de la poignée de main. Si un côté n’inclut pas l’option de mise à l’échelle de la fenêtre dans SYN ou SYN-ACK, la connexion ne pourra pas utiliser la mise à l’échelle ultérieurement.
Preuve:
- Options de synchronisation.
- Options SYN-ACK.
- Valeur d'échelle de la fenêtre.
- Fenêtre de réception initiale.
- Fenêtre mise à l'échelle efficace.
- Comportement de Middlebox qui supprime les options.
Si la capture démarre après la poignée de main, le facteur d'échelle peut être inconnu. C'est pourquoi les traces de support doivent inclure la négociation TCP complète.
L'emplacement de capture est important
L'analyse de la fenêtre dépend de l'endroit où la capture a été prise. Une capture près de l'expéditeur peut afficher un timing différent d'une capture près du récepteur. NAT, VPN, proxys et équilibreurs de charge peuvent également diviser les connexions.
Questions :
- Le pcap a-t-il été capturé sur le client, le serveur, le pare-feu ou le proxy ?
- S'agit-il d'une connexion TCP de bout en bout ou de deux connexions côté proxy ?
- Les numéros de séquence sont-ils traduits ?
- Les ACK sont-ils retardés par le récepteur ou par le réseau ?
- Le proxy annonce-t-il une fenêtre différente de celle du point de terminaison final ?
PCAP Surgery permet de découper et de comparer les conversations sans perdre les options de poignée de main.
Évitez les fausses conclusions sur la perte de paquets
Les tableaux de bord de débit accusent souvent la perte de paquets. Mais si les retransmissions sont rares et que l’expéditeur fait des pauses répétées à la fenêtre de réception, le véritable goulot d’étranglement est le contrôle du flux.
Signes indiquant que la perte n’est pas la cause principale :
- Peu de retransmissions.
- Pas de tempête ACK en double.
- Cycles de mise à jour réguliers des fenêtres.
- L'expéditeur s'arrête exactement à la fenêtre annoncée.
- La réponse de la couche application est lente à consommer des données.
L'article doit cibler des recherches telles que « TCP lent sans perte de paquets », car ces utilisateurs ont besoin d'un chemin de diagnostic différent.
Liste de contrôle de débogage
Utilisez ce flux de travail :
- Conservez les paquets SYN et SYN-ACK.
- Options d’échelle de fenêtre d’enregistrement.
- Calculez la fenêtre de réception effective.
- Identifiez les paquets sans fenêtre et avec mise à jour de fenêtre.
- Identifiez les périodes de fenêtre pleine.
- Mesurez le RTT.
- Comparez les octets en vol avec le produit de délai de bande passante.
- Vérifiez le taux de retransmission séparément.
- Notez l’emplacement de capture.
- Préservez l’intervalle lent et la poignée de main ensemble.
Diagnostic final
La mise à l'échelle de la fenêtre TCP et les problèmes de fenêtre de réception créent des transferts lents sans perte évidente de paquets. La preuve réside dans les options de prise de contact, les fenêtres de réception annoncées, les événements sans fenêtre, les mises à jour des fenêtres, le RTT et le comportement de pause de l'expéditeur.
PCAP Surgery permet de conserver les paquets qui prouvent si le goulot d'étranglement est dû à une perte de réseau, à une pression dans la mémoire tampon de réception, à une mise à l'échelle manquante de la fenêtre, à un comportement de proxy ou à une application qui ne lit pas assez vite.