Je comprends que la mise en œuvre de la pile TCP dans Windows et Linux est différente. Windows utilise un algorithme de contrôle de congestion appelé TCP Reno tandis que Linux utilise Cubic.
Comment les 2 protocoles se comparent-ils lorsqu'ils coexistent sur le même réseau? Est-il vrai de dire que Cubic (Linux) est plus agressif et pourrait finir par obtenir une part de bande passante plus élevée?
Notez que l'algorithme de contrôle de congestion n'affecte que le trafic en amont et donc uniquement la bande passante en amont.
Cela étant dit, Cubic est en fait plus agressif, en particulier pour les réseaux avec un produit à retard de bande passante élevé. Il y a même une règle intégrée dans l'implémentation Linux afin de ne jamais utiliser un taux d'envoi plus petit que reno dans la même situation:
L'algorithme cubique Linux comprend également du code qui garantit que l'algorithme cubique est au moins aussi agressif que TCP standard
- Leith, Shorten, McCullagh, Évaluation expérimentale de Cubic-TCP
Ainsi, lorsque vous téléchargez vos mises à jour Windows tout en regardant des vidéos Youtube, votre trafic Youtube peut affamer votre trafic Microsoft, et vous ne pouvez rien y faire.
Premièrement, ce que vous dites n'est pas factuellement correct:
Tous ces algorithmes sont auto-réglables en fonction de la bande passante réseau disponible, de la latence, de la mémoire disponible, etc. Ils ont également de nombreux paramètres de configuration qui vous permettent de les régler manuellement.
Donc, vous ne pouvez pas vraiment comparer les uns aux autres, sans regarder la topologie de réseau spécifique exacte, le matériel et les logiciels utilisés, etc. Ce n'est pas comme si l'un était meilleur que l'autre, ou utiliserait une plus grande part de la bande passante disponible. Il est vrai que CUBIC est moins agressif que BIC, mais dans la pratique, d'autres considérations sont souvent plus importantes que la saveur de l'algorithme de congestion TCP utilisé.
À moins que vous n'essayiez de vous adapter à un scénario de réseau très étroit et inhabituel, ces algorithmes fonctionnent tous suffisamment bien et équitablement prêts à l'emploi.