Je ne suis pas d'accord sur le fait que "si vous n'avez pas de problème de nœud caché, la modification du seuil RTS n'améliorera pas les performances". L'utilisation de CTR / RTS réduit toujours les risques de collisions de données. Étant donné que chaque collision de données entraîne une corruption des données et nécessite donc de renvoyer les données, moins de collisions signifie moins de réexpédition de données et moins de réexpédition de données peut grandement améliorer vos performances WiFi; bien sûr seulement s'il y a une quantité notable de collisions dans votre réseau.
Pour expliquer les détails: Un nœud doit toujours attendre un certain temps et détecter le canal pour d'éventuelles transmissions avant d'en indiquer un propre. Seulement s'il ne détecte aucune transmission, il peut en démarrer une propre. Sans RTS / CTS, cette transmission est directement une transmission de données. Si maintenant deux nœuds ont la même idée et démarrent une transmission de données presque en même temps, ces transmissions entreront en collision. Le résultat est que ni l'une ni l'autre des transmissions ne se fait nulle part car toutes les données reçues seront corrompues pour tous les autres nœuds et l'AP.
Si RTS / CTS est utilisé, la transmission commence par l'envoi d'un paquet RTS par le nœud après la détection. Ce n'est que si cette demande RTS reçoit une réponse CTS qu'une transmission de données est lancée. Bien sûr, si deux nœuds veulent transmettre en même temps, leurs demandes RTS peuvent également entrer en collision avec le même effet négatif qu'aucun RTS n'est reçu du tout. La différence est que l'ensemble du réseau se rétablira beaucoup plus rapidement d'une collision RTS que d'une collision de données. Ainsi, une collision RTS est moins nuisible à l'ensemble des performances du réseau qu'une collision de données.
L'inconvénient est que RTS / CTS lui-même nécessite une certaine bande passante réseau et introduit de nouveaux temps de détection pendant lesquels aucune autre transmission de données ou transmission RTS / CTS ne peut avoir lieu. Pour aggraver les choses, bien sûr, RTS / CTS doit toujours être effectué en utilisant la vitesse la plus lente prise en charge par le réseau, sinon les nœuds ne prenant en charge que cette vitesse ne la verront pas. Donc, fondamentalement, vous pouvez dire que RTS / CTS réduit toujours le débit théorique de tout votre réseau, mais si votre réseau souffre de nombreuses collisions, soit par le problème de nœud caché (qui peut également être causé par des nœuds d'autres réseaux utilisant simplement le même comme votre réseau) ou parce que votre WiFi est encombré (car plus de nœuds augmentent les risques de collisions aléatoires), cela peut en fait augmenter le débit réel. Pas le nombre de nœuds cachés,
J'ai lu une étude (je mettrai à jour et ajouterai un lien ici une fois que j'aurai pu le retrouver), qui suggère qu'à moins que votre réseau soit vraiment petit (moins de peut-être 6 nœuds et ne couvrant qu'une petite zone) et non isolé des autres réseaux utilisant le même canal, en utilisant RTS / CTS a presque toujours un effet plutôt positif dans la pratique. Alors pourquoi la valeur seuil? Si l'envoi des données prendrait autant de temps qu'une prise de contact RTS / CTS, il y a peu de gain à utiliser RTS / CTS, car si le réseau doit se remettre d'une très petite collision de données ou d'une collision RTS ne fera pas beaucoup de différence. La meilleure récupération après les collisions RTS est due au fait que les paquets RTS sont très petits alors que les paquets de données ne le sont généralement pas. Mais pour les très petits paquets de données, RTS / CTS ajoute simplement une surcharge pour aucun gain pratique.
Et maintenant, vous savez également comment un seuil de fragmentation peut améliorer les performances du réseau. D'une part, il limite la taille des paquets envoyés et, comme expliqué ci-dessus, plus le paquet lors d'une collision est petit, plus le réseau s'en remettra rapidement. Et d'un autre côté, en cas de collision, seul le fragment affecté doit être renvoyé, pas le paquet entier. Cependant, chaque fragment envoyé a une surcharge qui lui est propre, donc plus il y a de fragments envoyés, plus la surcharge qui s'ajoutera et la surcharge est essentiellement une bande passante gaspillée qui aurait également pu être utilisée pour les transmissions de données.