Nous avons un serveur d'applications qui ont été observés d'en-têtes avec la taille de la fenêtre TCP 0 à des moments où le réseau avait une congestion (sur le site d'un client).
Nous aimerions savoir s'il s'agit d'Indy ou de la couche Windows sous-jacente responsable de l'ajustement de la taille de la fenêtre TCP de la valeur nominale 64k dans l'adaptation au débit disponible.
Et nous pourrions agir sur elle devenir 0 (rien ne reçoit l'envoi, les utilisateurs attendent => pas de bien).
Ainsi, toutes les informations, le lien, le pointeur du code Indy sont les bienvenus ...
Disclaimer: Je ne suis pas un spécialiste du réseau. S'il vous plaît garder la réponse compréhensible pour la moyenne de moi ;-)
Remarque: c'est Indy9 / D2007 sur Windows Server 2003 SP2.
Plus Détails de Gory:
Les cas de fenêtre Zero TCP se produisent sur le niveau moyen parlant au serveur DB.
Cela se produit aux mêmes moments lorsque les utilisateurs finaux se plaignent de ralentissements de l'application client (c'est ce qui a déclenché l'enquête du réseau).
2 grands problèmes de réseau causant des goulots d'étranglement ont été identifiés.
La fenêtre Zero TCP s'est produite lorsqu'il y avait une congestion réseau, mais peut ou non être causée par elle.
Nous voulons savoir quand cela se produisait et avoir un moyen de faire quelque chose (se connecter au moins) dans notre code.
Où crochet (en indy?) Pour savoir quand cette condition se produit?
3 Réponses :
Un en-tête TCP avec une taille de fenêtre de zéro indique que les tampons du récepteur sont pleins. Ceci est une condition normale pour un écrivain plus rapide que le lecteur.
En lisant votre description, ce n'est pas clair si cela est inattendu. Qu'est-ce qui vous a fait ouvrir un analyseur de protocole?
Quelques-uns ici ou il n'y aurait pas sembler d'un problème, mais quand c'est arrivé, il y avait 40 dans la même seconde. L'enquête a été déclenchée lorsque les utilisateurs finaux se sont plaints de ralentissements notables dans l'application client. 2 questions majeures ont été identifiées au niveau du réseau qui causeraient des goulots d'étranglement. Mais la fenêtre Zero TCP peut être causée par ces conditions et de toute façon, nous aimerions être conscientes quand cela se produirait et que cela se produise au moins de connecter certaines informations.
La taille de la fenêtre dans l'en-tête TCP est Noramlly définie par le logiciel de pile TCP pour refléter la taille de l'espace tampon disponible. Si votre serveur envoie des paquets avec une fenêtre définie sur zéro, il est probablement parce que le client envoie des données plus rapidement que l'application exécutée sur le serveur, et les tampons associés à la connexion TCP sont maintenant pleins.
Ceci est une opération parfaitement normale pour le protocole TCP si le client envoie des données plus rapidement que le serveur ne peut le lire. Le client doit s'abstenir d'envoyer des données jusqu'à ce que le serveur envoie une taille de fenêtre non nulle (il n'y a aucun point, car il serait jeté quand même).
Cela peut ne pas refléter un problème grave entre le client et le serveur, mais si la condition persiste, cela signifie probablement que l'application exécutée sur le serveur a cessé de lire les données reçues (une fois qu'il commence à lire, cela libère un espace tampon pour TCP et la pile TCP enverra une nouvelle taille de fenêtre non nulle).
La question principale est qui définit la taille de la fenêtre sur 0 et où? Mise à jour de la question ...
La pile TCP (dans ce cas, une partie de Windows Server) définit la taille de la fenêtre à zéro, mais cela le fait parce que l'application exécutée sur le serveur (Indy?) Ne lisait pas les données.
Il est donc possible que si le niveau moyen ne puisse pas livrer à l'application client en raison d'un obstacle au réseau, il cesse de lire les données provenant du serveur DB qui permet ensuite de définir la taille de la fenêtre TCP sur 0 ... et tout le monde attend que les choses vont mieux. À droite?
@Stephen C. Steel: Indy est la bibliothèque de communication (TCP, IP, HTTP ...) à venir avec Delphi.
@Francois Depuis c'est le serveur envoi de paquets TCP avec une taille de fenêtre zéro, il s'agit de l'application Server qui ne doit pas lire aussi rapidement que le client envoie (pas l'inverse). Quant pourquoi le serveur ne lit pas, je ne peux pas vous aider là-bas - cela dépend des détails sur votre application serveur, et je ne suis pas familier avec elle.
@Stephen C. Steel Merci pour toutes les explications.
Depuis que vous pourriez être intéressé par une solution à votre problème aussi:
Si vous avez un contrôle sur ce qui fonctionne sur le côté serveur (celui qui envoie les messages de taille de la fenêtre 0): Avez-vous envisagé d'utiliser SetSockopt () avec SO_RCVBUF pour augmenter de manière significative la taille du tampon de réception de votre prise?
dans Indy, SetSockopt () est une méthode de TidsocketHandle. Vous devez l'appliquer à tous les objets TidsocketHandle associés à votre prise. Et dans Indy 9, ceux-ci sont situés à travers des fixations de propriété dans votre TidTcSserver.
Je suggère d'abord à utiliser getockopt () avec SO_RCVBUF pour voir ce que le système d'exploitation vous donne en tant que taille de tampon par défaut. Ensuite, augmentez considérablement cela, peut être par des essais successifs, doubler la taille à chaque fois.
Vous voudrez peut-être aussi re-exécuter un appel Goockopt () après votre setSockopt () pour assurer que votre setSockopt a été réellement effectué: il existe généralement une limite supérieure que la mise en œuvre de la prise se déroule sur la taille des tampons. Et dans ce cas, il existe généralement un moyen dépendant du système d'exploitation de déplacer cette valeur de plafond. Mais ce sont des cas plutôt extrêmes, et vous n'êtes pas trop susceptible d'avoir besoin de cela.
Si vous n'avez pas de contrôle sur le code source sur le côté qui obtient débordement, vérifiez simplement si le logiciel s'exécutant là-bas expose un paramètre pour modifier cette taille de tampon.
bonne chance!
Merci pour cette pièce très précieuse