Il faut aussi savoir que dans le protocole TCP, il n'est pas indispensable d'envoyer un ACK pour chaque paquet entrant. Si on reçoit un deuxième paquet avant d'avoir envoyé le ACK du premier, on peut envoyer le ACK du deuxième seulement, on est sûr d'être bon car chaque paquet contient un numéro de séquence.
Pratique
En pratique, j'ai un petit serveur TCP/IP programmé en C qui ne fait que bloquer sur recv, à qui j'envoie (localement) 200 Ko par un wget --post-file. En utilisant tcpdump sur l'interface lo je vois que le client envoie des paquets qui font 8244 octets souvent, 16436 parfois, les ACK du serveur font eux 52 octets et il en transmet pour environ 70% des paquets.
En moyenne haute, pourcentage de 0,5%.
Comme je suppute que la fenêtre de transmission max soit moins élevée dans le cas d'une connexion distante, j'essaie de regarder sur un simple wget sur un site distant, à travers une ligne DSL 512/512 : j'obtiens 1500 octets dans un sens pour 52 octets dans l'autre.
Ça donne 3,4%.
On est encore loin des 10% annoncés, même si on s'en rapproche. Par contre, on peut se demander si avec une meilleure ligne, la fenêtre n'a pas tendance à augmenter au-delà de 1500 octets, et autoriser donc un 2048/128 sans soucis.
Un dernier point : ça m'étonnerait que les providers soient suffisamment débiles pour offrir du 2048/128 qui soit théoriquement jamais atteignable. Enfin, sauf peut-être en UDP, et il paraît que les jeux en réseau l'utilisent pour la performance, d'ailleurs.
# Des chiffres
Posté par gc . En réponse au journal ADSL: du 2048 Kbits en non-degroupé, question. Évalué à 7.
Théorie
Il semble que la taille max d'un paquet IP soit 65,535 octets et la taille d'un simple ACK TCP soit de 40 octets.
http://www.rhyshaden.com/ipdgram.htm(...)
http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/packet-deco(...)
Ce qui donnerait un pourcentage de 0,06%.
Il faut aussi savoir que dans le protocole TCP, il n'est pas indispensable d'envoyer un ACK pour chaque paquet entrant. Si on reçoit un deuxième paquet avant d'avoir envoyé le ACK du premier, on peut envoyer le ACK du deuxième seulement, on est sûr d'être bon car chaque paquet contient un numéro de séquence.
Pratique
En pratique, j'ai un petit serveur TCP/IP programmé en C qui ne fait que bloquer sur recv, à qui j'envoie (localement) 200 Ko par un wget --post-file. En utilisant tcpdump sur l'interface lo je vois que le client envoie des paquets qui font 8244 octets souvent, 16436 parfois, les ACK du serveur font eux 52 octets et il en transmet pour environ 70% des paquets.
En moyenne haute, pourcentage de 0,5%.
Comme je suppute que la fenêtre de transmission max soit moins élevée dans le cas d'une connexion distante, j'essaie de regarder sur un simple wget sur un site distant, à travers une ligne DSL 512/512 : j'obtiens 1500 octets dans un sens pour 52 octets dans l'autre.
Ça donne 3,4%.
On est encore loin des 10% annoncés, même si on s'en rapproche. Par contre, on peut se demander si avec une meilleure ligne, la fenêtre n'a pas tendance à augmenter au-delà de 1500 octets, et autoriser donc un 2048/128 sans soucis.
Un dernier point : ça m'étonnerait que les providers soient suffisamment débiles pour offrir du 2048/128 qui soit théoriquement jamais atteignable. Enfin, sauf peut-être en UDP, et il paraît que les jeux en réseau l'utilisent pour la performance, d'ailleurs.