• [^] # Re: trucs & machins...

    Posté par . 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 :

    net.ipv4.tcp_workaround_signed_windows = 1
    net.ipv4.tcp_base_mss = 1056
    net.ipv4.tcp_tso_win_divisor = 1
    net.ipv4.tcp_window_scaling = 1
    

    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

    02:01:04.822588 IP 192.168.1.13.59108 > 89.84.127.54.50837: Flags [.], ack 24167556, win 32767, options [nop,nop,TS val 7889144 ecr 656051175], length 0
    02:01:04.822592 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24167556:24168600, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
    02:01:04.822598 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24168600:24169644, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
    02:01:04.822603 IP 192.168.1.13.59108 > 89.84.127.54.50837: Flags [.], ack 24169644, win 32767, options [nop,nop,TS val 7889144 ecr 656051175], length 0
    02:01:04.822613 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24169644:24170688, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
    02:01:04.822617 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24170688:24171732, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
    02:01:04.822623 IP 192.168.1.13.59108 > 89.84.127.54.50837: Flags [.], ack 24171732, win 32767, options [nop,nop,TS val 7889145 ecr 656051175], length 0
    02:01:04.822624 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24171732:24172776, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
    02:01:04.822916 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24172776:24173820, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
    02:01:04.822952 IP 192.168.1.13.59108 > 89.84.127.54.50837: Flags [.], ack 24173820, win 32767, options [nop,nop,TS val 7889145 ecr 656051175], length 0
    02:01:04.822957 IP 89.84.127.54.50837 > 192.168.1.13.59108: Flags [.], seq 24173820:24174864, ack 1, win 14480, options [nop,nop,TS val 656051175 ecr 7889130], length 1044
    

    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 :

    net.ipv4.tcp_workaround_signed_windows = 1
    net.ipv4.tcp_tso_win_divisor = 1
    net.ipv4.tcp_base_mss = 1056
    
    ifconfig enp15s0 mtu 1096
    

    debilt-test6

    Mes deux cents.
    (j'me coucherai moins con ce soir)