Effectivement, c'est complètement faux. Voici une description d'un algo de gestion du débit TCP pour illustrer cela.
Au début d'une connexion TCP au contraire, la machine qui envoie les paquets commence tout doucement (le débit suit une exponentielle, donc c'est lent au début et ça accélère). C'est pour cela que TCP c'est pénible pour les petits transferts, car dans ce cas, on ne dépasse jamais la phase de démarrage lent.
À force d'augmenter le débit, on finit par saturer le lien (ou réveiller une règle de QoS), donc des paquets se perdent. Le débit est alors réduit (par exemple divisé par deux), puis on l'augmente peu à peu de nouveau (par exemple linéairement), jusqu'à la prochaine perte.
Il existe des variantes plus ou moins agressives, mais leur point commun, c'est qu'une perte d'un paquet entraîne toujours un ralentissement de l'émission (en plus de la ré-émission du paquet).
[^] # Re: QoS
Posté par Florian Hatat . En réponse au journal Free lance FreeWIFI un réseau "communautaire" comme NeufWIFI ou FON. Évalué à 6.
Au début d'une connexion TCP au contraire, la machine qui envoie les paquets commence tout doucement (le débit suit une exponentielle, donc c'est lent au début et ça accélère). C'est pour cela que TCP c'est pénible pour les petits transferts, car dans ce cas, on ne dépasse jamais la phase de démarrage lent.
À force d'augmenter le débit, on finit par saturer le lien (ou réveiller une règle de QoS), donc des paquets se perdent. Le débit est alors réduit (par exemple divisé par deux), puis on l'augmente peu à peu de nouveau (par exemple linéairement), jusqu'à la prochaine perte.
Il existe des variantes plus ou moins agressives, mais leur point commun, c'est qu'une perte d'un paquet entraîne toujours un ralentissement de l'émission (en plus de la ré-émission du paquet).