Fenêtre nulle TCP à travers un proxy : identifier le récepteur
Localisez le contrôle de flux TCP du côté client ou serveur d'un proxy avant d'attribuer un téléchargement bloqué à la mise à l'échelle de fenêtre ou à la taille du tampon.
Une capture de paquets indique TCP ZeroWindow. Avant de modifier un paramètre du noyau, identifiez l'extrémité qui annonce le zéro.
Cette extrémité décrit sa capacité de réception sur cette connexion TCP. Elle n'annonce pas la bande passante disponible pour le proxy entier. Une sonde de fenêtre nulle permet à l'émetteur de savoir si cette capacité annoncée a changé ; les sondes seules n'établissent ni une perte de paquets ni un proxy défaillant.
browser <-- TCP A --> proxy <-- TCP B --> website
Ce sont deux conversations TCP distinctes. Supposez que le navigateur cesse de lire une grande réponse et annonce zéro sur A. Le proxy peut finir par ne plus vider B à mesure que ses propres tampons se remplissent. Une fenêtre nulle ultérieure sur B peut être une conséquence du client lent plutôt que le problème d'origine.
La situation inverse est possible lors d'un envoi. Si l'application de destination cesse de consommer les données, sa fenêtre sur B peut se fermer. La pression peut alors remonter vers le client par les tampons du proxy.
Ordonnez les observations
- Notez les extrémités de la connexion et le sens du transfert concerné.
- Identifiez quelle extrémité a annoncé la première une fenêtre de réception qui rétrécit ou tombe à zéro.
- Vérifiez si son application lisait, était en pause sur une autre opération ou limitée par les ressources.
- Comparez la chronologie sur l'autre connexion du proxy avant d'attribuer la cause d'origine.
Les libellés d'analyse de fenêtre de Wireshark sont des interprétations utiles de la capture, non une consigne d'augmenter tous les tampons de réception. La mise à l'échelle de fenêtre doit elle aussi être interprétée au regard de la négociation de la connexion.
Essayer une autre extrémité depuis une liste de proxys et voir le transfert repartir est une preuve utile que le chemin a changé. Cela ne prouve pas, en soi, que l'implémentation TCP d'un système d'exploitation était défectueuse. Gardez l'explication liée au processus récepteur et à la connexion où l'attente a commencé.