Les données sont transférées sur le réseau et sur Internet à l'aide du Protocole TCP / IP. Le protocole TCP / IP n’est pas parfait, mais il est plus facile à mettre en œuvre que d’autres protocoles théorisés pour la communication de données… tels que le modèle ISO OSI. Comme pour toute chose technique, TCP / IP a aussi quelques défauts et Syndrome idiot de la fenêtre est une création de l’un de ces défauts. Pour comprendre ce qu'est le syndrome de Silly Window ou SWS, vous devez d'abord comprendre le mécanisme sous-jacent de la communication de données dans TCP / IP.
Syndrome idiot de la fenêtre
Comprendre la fenêtre et sa taille
Lorsque deux points communiquent sous TCP / IP, cela implique un mécanisme d’accusé de réception. Ce mécanisme de reconnaissance est ce qui cause le syndrome de Silly Window, comme expliqué plus loin. Les points peuvent faire référence à deux ordinateurs, client et serveur, etc.
SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data. The result can be a stable pattern of sending tiny data segments, even though both sender and receiver have a large total buffer space for the connection, says MSDN.
Lorsqu'un ordinateur, dit 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 de la mémoire tampon réservée à ce fil de communication. Il s’agit généralement du nombre d’octets libérés pour la communication.
Ainsi, lorsque B indique que 100B est disponible pour le message suivant, 100B est la fenêtre du syndrome de Silly Window. C'est la taille de la mémoire tampon. Avec son propre défaut, le mécanisme TCP / IP peut réduire la taille de la mémoire tampon pour chaque communication / donnée provenant de A. Cela signifie que chaque fois que A envoie un message, B suppose que la taille de la mémoire tampon est réduite et envoie un nombre plus petit. Ainsi, la taille de la fenêtre reste réduite et, à un moment donné, la communication s’arrête car B envoie 0B comme taille de fenêtre.
Comment fonctionne le syndrome de la fenêtre idiote
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 en indiquant que 500B est disponible pour la fenêtre, car le deuxième paquet doit encore être reçu. A suppose que 500B correspond à la taille de la fenêtre et envoie deux paquets de 250B en conséquence. Tandis qu’en B, 500B est utilisé et 500 vient d’être reçu, il enverra 0B selon la disponibilité. À ce stade, A supposera qu'aucune fenêtre n'est disponible bien qu'il puisse arriver que la mémoire tampon soit vide car le processeur y a utilisé les données. A enverra quand même 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, B envoyant un accusé de réception chaque fois qu’il reçoit un paquet de A. Cette taille est généralement inférieure à 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 assez grand pour couvrir la taille de la mémoire tampon sur B à la fois. Mais cela nécessiterait des mécanismes supplémentaires et donc le syndrome de Silly Window. 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 idiote (SWS)
Il existe un algorithme simple à mettre en œuvre pour se débarrasser de SWS. À la réception du paquet initial, B envoie la moitié de l’espace réellement disponible à la fenêtre. Cela fera A envoyer des paquets plus petits. Par conséquent, lorsque les paquets deviennent trop petits, B envoie alors la taille totale de la mémoire tampon afin que A puisse recommencer à envoyer des octets de données plus importants.
En d'autres termes, si 1000B est disponible, B envoie 500B comme accusé de réception. En conséquence, A envoie 250 paquets x 2 paquets. Pour cela, A reçoit 100B comme accusé de réception. Quand il reçoit un paquet 50B, B envoie 1000B - 50B à A. Cela rend la conversation complète à nouveau opérationnelle. Cela pourrait entraîner un peu de retard dans le traitement, mais évitera le syndrome de Silly Window et l’arrêt de la conversation.
En résumé, SWS est basé sur la taille de la mémoire tampon disponible sur le destinataire et la taille supposée calculée par l'expéditeur. Pour éviter SWS, un délai est introduit et une taille de fenêtre volontairement 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 se répète jusqu'à la fin de la communication.
Bien que j'aie pu utiliser les mots window et buffer de manière interchangeable. Je ne parle pas 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.
