La meilleure description que j'ai jamais entendue qui donnait un sens à la méthode de limitation inhérente de TCP était hors d'un podcast Security Now récent . Pour citer Steve Gibson:
Donc, par accord universel, TCP étant ce protocole très intelligent, il fait ce qu'on appelle un «démarrage lent». Il est généralement autorisé à envoyer un certain nombre de paquets sans accusé de réception. Donc, l'idée étant, faisons bouger les choses ici. Et généralement, ce nombre est deux. Et donc quand TCP démarre, il peut envoyer deux paquets, l'un après l'autre. Sans que le premier soit reconnu, il enverra le second. Mais alors ça attend. Et puis la règle de limitation est que nous permettons au nombre de paquets non acquittés d'augmenter d'une unité pour chaque accusé de réception que nous recevons.
Alors réfléchissons à ça. Nous permettons d'augmenter le nombre de paquets non acquittés de un pour chaque accusé de réception que nous recevons. Nous envoyons donc d'abord deux paquets comme point de départ convenu. Ils sont reconnus. Nous avons donc notre première reconnaissance. Nous nous permettions d'en envoyer deux. Maintenant, avec la réception de ce premier accusé de réception, nous l'augmentons d'un à trois. Nous pouvons donc maintenant envoyer trois paquets supplémentaires sans autre accusé de réception. Lorsqu'un accusé de réception revient pour tout ce que nous avons envoyé auparavant, nous passons à quatre. C'est ce qu'on appelle la «fenêtre de congestion». Ce n'est pas une fenêtre qui est jamais envoyée sur la ligne, c'est-à-dire que ce n'est pas comme la fenêtre de réception, qui est 16 bits de l'en-tête TCP qui nous dit combien de données nous pouvons envoyer à l'avance. Celui-ci est - c'est une fenêtre. Il'
Si nous continuons d'augmenter le nombre de paquets non acquittés que nous sommes autorisés à envoyer d'un par chaque fois que nous recevons un accusé de réception, à un moment donné, nous allons atteindre une limite. Et la beauté de ce système est qu'il va, alors que nous commençons à envoyer des paquets plus rapidement que le lien le plus faible, littéralement le lien, entre les routeurs, à un moment donné, nous trouvons le point où le lien le plus faible se rompt. Il supprime les paquets que nous essayons d'envoyer parce que nous essayons de les envoyer trop rapidement. Les accusés de réception de l'autre extrémité s'arrêtent donc parce que les données ne passent plus.
Et ce que fait TCP, c'est s'il n'a pas reçu - et cela varie selon les stratégies. Au fil du temps, la stratégie, la stratégie réelle d'évitement de la congestion a beaucoup varié. Il y a des noms comme Tahoe et Reno, et tout un tas d'autres que vous verrez si vous faites des recherches sur Google et Wikipedia, qui précisent exactement quel est le comportement. Mais l'idée est que, lorsque l'expéditeur se rend compte que ses données ne passent plus parce qu'il manque des accusés de réception, il réduit rapidement son taux d'envoi. En règle générale, il le divise en deux. Ainsi, il la redimensionne considérablement, puis recommence à l'augmenter.
Donc, essentiellement, cela signifie que la perte de paquets est la fonction de signalisation pour «Nous ne pouvons pas envoyer les données plus rapidement» et que les expéditeurs TCP à chaque extrémité d'une connexion, partout sur Internet, sont toujours en quelque sorte - ils » essaie d'aller plus vite que la vitesse maximale disponible entre les deux points de terminaison, c'est-à-dire le lien le plus faible, où qu'il se trouve, et ils le poussent toujours à la limite. Donc, étant donné qu'il y a un point quelque part qui est plus faible que leur capacité à envoyer des paquets, ils vont le trouver parce qu'ils vont pomper les paquets. Tant qu'il y a des données à envoyer et qu'ils ont une connexion à large bande passante, l'expéditeur augmentera le taux d'envoi, c'est-à-dire le nombre de paquets en attente, les paquets autorisés à être présents à la volée en guise de remerciements. reviens, maintient agressivement ce nombre vers le haut jusqu'à ce qu'il le pousse trop loin. Ensuite, il recule beaucoup, puis recommence.
C'est donc ce qui se passe réellement entre les connexions TCP qui sont, comme, probablement, je ne sais pas quel pourcentage, mais le plus gros pourcentage du trafic sur Internet passe par des connexions TCP. Tous nos systèmes d'exploitation dans le noyau, dans la soi-disant pile TCP, ont ces compteurs. Et lorsque nous envoyons un fichier, lorsque nous téléchargeons un gros fichier ou que nous recevons une page Web, le serveur à l'autre bout fait la même chose. Il pousse, sur une base de connexion individuelle, autant de paquets qui n'ont pas encore été reconnus comme il peut, augmentant le taux de paquets jusqu'à ce qu'il atteigne le point où il commence à échouer ou à bégayer. Ensuite, il recule, pour permettre aux choses de récupérer, puis recommence à fonctionner.
Et donc cela finit par être une sorte de système d'auto-étranglement qui, compte tenu des contraintes, je veux dire, il semble vraiment un peu génial et grossier. "