rendre prioritaire les paquets TCP ack sortants.

Pourquoi ?

J'ai été assez surpris de vois qu'on pouvait dropper 90% des ack sortant sans véritable impact...  (enfin ca réduit un peu la Rwin car il y a des paquets acquittés que le serveur pense non acquittés.

Par contre rendre les flux IPTV et VoIP prioritaire, en download et en upload, ca c'est utile.

pour récupérer ton IP publique et que ça : http://ip.lafibre.info/

Pour le vpn (serveur en mode routage), c'est beaucoup plus simple de le mettre dans le routeur, car la gateway du réseau est le routeur.
Si tu relies 2 sites avec 2 subnets, c'est plus simple de configurer la table de routage du routeur a la place de la table de routage de toutes les machines du réseau.

L'autre solution plus simple consiste peut être a configurer openvpn en mode bridge ethernet...

Je ne suis pas sûr de comprendre ce que tu entends pas TCP ack sortant, encore moins pourquoi ils devraient être prioritaires.

Dans TCP, le récepteur prévient l'èmetteur qu'il a bien reçu les paquets en lui envoyant des packets TCP ACK(knowledge). Si tu perds un TCP ACK, l'èmetteur ré-èmet le paquet correspondant. En général, le débit baisse beaucoup. Donc, si tu ne les rends pas prioritaires (car peu nombreux) tu perds du débit en download dès que ton lien upload est occupé.

La freebox le fait d'office depuis pas mal d'années, çà change beaucoup la qualité du service.
Mais si tu upload pas, çà ne se voit pas. Le test est de simplement de downloader pendant que tu upload.

Dans TCP, le récepteur prévient l'èmetteur qu'il a bien reçu les paquets en lui envoyant des packets TCP ACK(knowledge).

Je connais, mais je ne vois pas ce que tu appelles donner la priorité aux paquets TCP ACK, ni même ce que tu appelles un paquet TCP ACK.

On parle bien de priorité entre différents paquets TCP?

En fait, le réel problème est que les routeurs adsl ont souvent un vilain défaut, ils mémorisent les paquets à èmettre pour en perdre le moins possible (jusqu'à plusieurs secondes).
Donc si le lien upload est occupé, on obtient des latences très élevées.
La solution pour éviter cela est de gérer la qualité de service, c'est à dire permettre à certains paquets d'en doubler d'autres. Mais pour pouvoir le faire correctement, il faut le faire à l'endroit ou çà bouchonne, donc dans le modem adsl. Sinon, le script limite de débit upload pour ne jamais remplir les fifos d'upload.

Je connais, mais je ne vois pas ce que tu appelles donner la priorité aux paquets TCP ACK, ni même ce que tu appelles un paquet TCP ACK.

Vu :
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:

tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10Je ne connaissais pas trop la commande tc et le manuel de "tc filter" manque à l'appel, mais si je ne me trompe pas, ça veut dire :
protocol ip : si le protocole est IPv4
match ip protocol 6 0xff : et que le protocole est TCP
match u8 0x05 0x0f at 0 : et que l'en-tête IP fait exactement 20 octets (taille minimum, aucune option IP)
match u16 0x0000 0xffc0 at 2 : et que la taille du paquet est < 0x40 = 64
match u8 0x10 0xff at 33 : et que les flags TCP sont ACK
flowid 1:10 : alors il est la classe 1:10 est utilisée :

tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
   burst 6k prio 1
Si j'ai bien compris ça donne la priorité aux paquets TCP d'une taille inférieure à 64 octets, c'est à dire ayant moins de 24 octets d'options TCP et de données utiles.

Sans ce buffer, on aurait de nombreuses pertes de paquets, TCP envoyant des paquets en nombre a des vitesse plus élevée que la liaison physique. Sur un accés 3G, les buffers sont petit et on est obligé de mettre une petite Rwin pour ne pas perdre de paquets.

Si tu envoies plus de données que la liaison ne le permet, tu vas perdre des paquets : il y a pas de miracle!

Si tu mets une ridiculement longue file d'attente pour stocker les paquets afin d'éviter les pertes, les pertes de paquets arriveront trop tard, et tu vas saturer ton lien 3G (ou autre) avec de vieux paquets qui sont considérés comme perdus par la couche transport fiable (TCP ou autre). Alors l'èmetteur va réèmettre les vieux paquets qu'il pense perdus, ce qui va encore plus saturer la file d'attente; quand les ACK des vieux paquets vont revenir, l'èmetteur ne saura pas si les premiers sont arrivés très lentement ou les derniers plus vite.

Penser qu'une longue file d'attente est une bonne chose c'est penser qu'une latence très élevée et très variable est une bonne chose. C'est ridicule, une latence élevée n'est pas une bonne chose et le jitter élevé une très mauvaises chose.

Le principe même d'un protocole de transport régulé (comme TCP) est d'arriver à perdre des paquets. Si tu ne perds pas de paquets c'est que tu n'as utilisé toute la capacité du lien.