Phenquestions
Les données sont transférées sur le réseau et Internet à l'aide du Protocole TCP/IP. Le TCP/IP n'est pas parfait mais est plus facile à mettre en œuvre par rapport à d'autres protocoles théorisés pour la communication de données… comme le modèle ISO OSI. Comme pour toute chose technique, TCP/IP a aussi quelques défauts et Syndrome de la fenêtre stupide est une création de l'un de ces défauts. Pour comprendre ce qu'est le Silly Window Syndrome ou SWS, vous devez d'abord comprendre le mécanisme sous-jacent de la communication de données dans TCP/IP.
Syndrome de la fenêtre stupide
Comprendre la fenêtre et sa taille
Lorsque deux points communiquent sous TCP/IP, il s'agit d'un mécanisme d'acquittement. Ce mécanisme de reconnaissance est ce qui cause le syndrome de la fenêtre stupide, comme expliqué plus loin. Les points peuvent faire référence à deux ordinateurs, client et serveur, etc.
SWS est causé par le fait que le récepteur avance le bord droit de la fenêtre chaque fois qu'il dispose d'un nouvel espace tampon disponible pour recevoir des données et par l'expéditeur utilisant n'importe quelle fenêtre incrémentielle, quelle que soit sa taille, pour envoyer plus de données. Le résultat peut être un modèle stable d'envoi de segments de données minuscules, même si l'expéditeur et le destinataire disposent d'un grand espace tampon total pour la connexion, selon MSDN.
Lorsqu'un ordinateur, disons A, envoie un paquet de données à un autre ordinateur B, ce dernier doit accuser réception et répondre qu'il a reçu le paquet de données. En plus de l'accusé de réception, il doit également envoyer la taille du tampon mis à part pour ce fil de communication. C'est généralement le nombre d'octets libérés pour la communication.
Ainsi, lorsque B dit que 100B est disponible pour le prochain message, le 100B est la fenêtre du Silly Window Syndrome. C'est-à-dire qu'il s'agit de la taille du tampon. Avec sa propre faille, le mécanisme TCP/IP peut réduire la taille de la mémoire tampon pour chaque communication/données provenant d'un. C'est-à-dire que chaque fois que A envoie un message, B suppose que la taille de la mémoire tampon est réduite et envoie un plus petit nombre. Ainsi, la taille de la fenêtre continue à être réduite et à un moment donné, la communication s'arrête lorsque B envoie 0B comme taille de fenêtre.
Comment fonctionne le syndrome de la fenêtre stupide
Selon l'exemple ci-dessus de A et B, si B envoie 1000B comme taille de fenêtre, A le divisera en deux 500B et enverra deux paquets de 500B. À la réception du premier paquet, B enverra un accusé de réception indiquant que 500B est disponible pour la fenêtre car le deuxième paquet n'a pas encore été reçu. A suppose que 500B est la taille de la fenêtre et envoie par conséquent deux paquets de 250B. Alors qu'à B, 500B est utilisé et 500 est juste reçu, il enverra 0B comme disponible. À ce stade, A supposera qu'aucune fenêtre n'est disponible bien qu'il puisse arriver que le tampon soit vide car le processeur y a utilisé les données. A enverra toujours un paquet plus petit pour voir si une fenêtre est disponible. Si le contenu du tampon en B n'est pas encore supprimé, il recevra toujours 0 comme réponse/accusé de réception.
Ainsi, la taille de la fenêtre continue de diminuer car B envoie un accusé de réception chaque fois qu'il reçoit un paquet de A. Cette taille est généralement plus petite que l'accusé de réception précédent car B reçoit des paquets de données par parties. Il n'y aurait aucun problème si A pouvait envoyer un paquet suffisamment gros pour couvrir la taille du tampon sur B à la fois. Mais cela nécessiterait des mécanismes supplémentaires et donc le syndrome de la fenêtre stupide. La communication s'arrête après que A a reçu 0 deux ou trois fois.
Comment prévenir le syndrome de la fenêtre stupide (SWS)
Il existe un algorithme simple à implémenter pour se débarrasser des SWS. A la réception du paquet initial, B envoie la moitié de l'espace réellement disponible en tant que fenêtre. Cela fera A envoyer des paquets plus petits. Par conséquent, lorsque les paquets deviennent trop petits, B envoie la taille totale du tampon afin que A puisse recommencer à envoyer des octets de données plus gros.
En d'autres termes, si 1000B est disponible, B envoie 500B comme accusé de réception. En conséquence, A envoie 250B x 2 paquets. Pour cela, A reçoit 100B comme accusé de réception. Lorsqu'il reçoit un paquet 50B, B envoie 1000B - 50B à A. Cela rend toute la conversation à nouveau opérationnelle. Cela pourrait induire un peu de retard dans le traitement, mais empêchera le syndrome de la fenêtre stupide de se produire et d'arrêter toute la conversation.
Pour résumer, SWS est basé sur la taille du tampon disponible sur le destinataire et la taille supposée calculée par l'expéditeur. Pour empêcher le SWS, un délai est introduit et une taille de fenêtre délibérément plus petite est réciproque jusqu'à ce que la taille du paquet devienne trop petite. Ensuite, le destinataire divulgue la taille de la fenêtre réellement disponible. L'ensemble du processus continue de se répéter jusqu'à ce que la communication soit terminée.
Bien que j'ai peut-être utilisé les mots fenêtre et tampon de manière interchangeable. Je ne veux pas dire de différence entre eux. Dans les études SWS, le tampon est la fenêtre.
Si vous avez besoin de plus d'informations, une explication détaillée est disponible ici sur tcpipguide.com.
