Pourquoi ? On force la division minimale de paquet à 1 (3 par défaut & gso c'est le mal ). Puis on colle une base pour mss à la valeur voulue (1096 donc, pour toi : Ici, sur la Fibre, j'ai une perte de débit en forçant la mtu et le mss comme cela, forcément : c'est juste pour ton exemple) enfin on s"assure que les wmem & rmem sont correctement positionnées, genre 4096 16384 4194304 (et puis on ajoute le workaround pour considérer que l'autre bout est tout cassé et qu'il traite mal la fenêtre). Je continue d'utiliser CUBIC pour les apps non privilégiées, et la plupart des autres paramètres tcp sont restés par défaut (ce qui ne le sont pas n'entrent pas en ligne de compte ici). Enfin, on fixe la mtu avec ip/ifconfig/sysconfig à 1096. Un tit coup de sysctl -w .net.ipv4.route_flush=1 & de sysctl -f /etc/sysctl.conf. La Nimage :
Le paramètre essentiel est de commencer avec le retrait des options de la carte réseau. Lorsque cette dernière se charge de la fragmentation alors le noyau va segmenter tes ko en paquets (de 1460 octets par exemple).
Tandisque si on laisse faire la carte réseau, le noyau va envoyer un gros paquet, et c'est la carte qui va segmenter.
Donc on ne peux pas faire joujou avec ces valeurs sans au préalable désactiver ces fonctions de la carte : il faut laisser faire le noyau.
En continuant sur le ton du début de commentaire, c'est un comportement de looser, de windows et autres TOE joyeusetés qui ont essayé de rentrer dans le noyau : retirer cette possibilité au noyau sous le fallacieux prétexte que "ip c'est touchy", alors on colle toute la pile ip dans le firmware de la carte rzo... Non mais ils sont FOUS. Donc, on commence par retirer un maximum de possibilités à la carte réseau, et on va laisser le noyau gérer cela à la place, hein
Là où ça devient rigolo, c'est qu'avec TCPDUMP tu ne verra pas la même chose, si tu le lances sur le même serveur. Si tu laisses faire la carte, tu verra un gros paquet. Si tu laisses faire le noyau tu verra les paquets fragmentés. Mais pourtant, même en voyant un seul gros paquet, c'est bien des fragments qui seront envoyés sur le réseau.
Il te faut envoyer tes paquets de tests avec ton application cible. Et aucune autre, au cas les autres feraient bien les choses, c'est souvent le cas sur gnu/linux : tu dois ajuster ces paramètres en fonction de ton application, par touche si besoin. Et sans te fier à un autre type d'envoi pour ces réglages, et en ayant un tcpdump à l'autre bout. Ce sont les deux conditions essentielles. Enfin, il y a perte de débit mais tu t'en fous puisque cette machine ne sert qu'à cette app là.
[^] # Re: trucs & machins...
Posté par bubar🦥 . En réponse au message [RESEAU] Fragmentations de paquets tcp. Évalué à 3. Dernière modification le 02 novembre 2013 à 02:53.
Alors j'pense (bien humblement) que tu devrais essayer ceci :
Pourquoi ? On force la division minimale de paquet à 1 (3 par défaut & gso c'est le mal ). Puis on colle une base pour mss à la valeur voulue (1096 donc, pour toi : Ici, sur la Fibre, j'ai une perte de débit en forçant la mtu et le mss comme cela, forcément : c'est juste pour ton exemple) enfin on s"assure que les wmem & rmem sont correctement positionnées, genre 4096 16384 4194304 (et puis on ajoute le workaround pour considérer que l'autre bout est tout cassé et qu'il traite mal la fenêtre). Je continue d'utiliser CUBIC pour les apps non privilégiées, et la plupart des autres paramètres tcp sont restés par défaut (ce qui ne le sont pas n'entrent pas en ligne de compte ici). Enfin, on fixe la mtu avec ip/ifconfig/sysconfig à 1096. Un tit coup de sysctl -w .net.ipv4.route_flush=1 & de sysctl -f /etc/sysctl.conf. La Nimage :
Et je vois la vie en 1044
1044
1044
1044
LOL
Le paramètre essentiel est de commencer avec le retrait des options de la carte réseau. Lorsque cette dernière se charge de la fragmentation alors le noyau va segmenter tes ko en paquets (de 1460 octets par exemple).
Tandisque si on laisse faire la carte réseau, le noyau va envoyer un gros paquet, et c'est la carte qui va segmenter.
Donc on ne peux pas faire joujou avec ces valeurs sans au préalable désactiver ces fonctions de la carte : il faut laisser faire le noyau.
En continuant sur le ton du début de commentaire, c'est un comportement de looser, de windows et autres TOE joyeusetés qui ont essayé de rentrer dans le noyau : retirer cette possibilité au noyau sous le fallacieux prétexte que "ip c'est touchy", alors on colle toute la pile ip dans le firmware de la carte rzo... Non mais ils sont FOUS. Donc, on commence par retirer un maximum de possibilités à la carte réseau, et on va laisser le noyau gérer cela à la place, hein
Là où ça devient rigolo, c'est qu'avec TCPDUMP tu ne verra pas la même chose, si tu le lances sur le même serveur. Si tu laisses faire la carte, tu verra un gros paquet. Si tu laisses faire le noyau tu verra les paquets fragmentés. Mais pourtant, même en voyant un seul gros paquet, c'est bien des fragments qui seront envoyés sur le réseau.
Il te faut envoyer tes paquets de tests avec ton application cible. Et aucune autre, au cas les autres feraient bien les choses, c'est souvent le cas sur gnu/linux : tu dois ajuster ces paramètres en fonction de ton application, par touche si besoin. Et sans te fier à un autre type d'envoi pour ces réglages, et en ayant un tcpdump à l'autre bout. Ce sont les deux conditions essentielles. Enfin, il y a perte de débit mais tu t'en fous puisque cette machine ne sert qu'à cette app là.
En résumé pour ton besoin :
debilt-test6
Mes deux cents.
(j'me coucherai moins con ce soir)