J'ai un VPN qui ne sert qu'à une seule chose : transporter des données déjà compressées, et je me demande si la compression du VPN ne serait pas superflue, voire contre-productive.
les hypothèses
Plus précisément je transporte un flux audio avec netJack entre deux serveurs jackd, ce flux est compressé avec le codec « ultra basse latence » CELT du projet Xiph.org.
Je cherche à obtenir le délai le plus bas possible avec une contrainte temps réel : un paquet en retard est un paquet inutile. Mes deux serveurs jackd discutent entre eux via un tunnel OpenVPN.
D'habitude pour mes VPN j'active l'option comp-lzo que le man vante comme « ultra fast » et « real-time ». Le projet LZO dit que la compression est « pretty fast », et la décompression « very fast ».
le problème
De tels éloges sont décideur-compliant, sauf que « pretty fast » c'est toujours plus long que « pas du tout », et je me demande si je n'aurai pas moins de délai à transporter un flux VPN non compressé plutôt que compressé, quand bien même cette compression serait très rapide.
Ce que je transporte est déjà compressé, et je pense que les gars de CELT sont mieux à même de répondre à mon problème que ceux de LZO. Si mon VPN utilise LZO je prends le risque que la compression LZO perde du temps à compresser (ou échouer de compresser) quelque chose qui l'est déjà et mieux. Je prends aussi le risque que LZO ne parvenant pas à compresser, je subisse en plus un supplément de débit du à un quelconque overhead du format de compression, aussi minime soit-il. Bref, je crains un overhead de débit et de latence.
D'après le man d'OpenVPN, l'overhead de débit serait de seulement 1 octet : « may add up to 1 byte per packet for incompressible data », c'est pas énorme, et la compression serait « very fast ». Peut-être que mon interrogation relève de la tetracapillosectomie… Mais j'ai vraiment besoin d'un débit le plus maigre possible et d'une latence toute aussi faible et surtout stable.
Sachant que déjà mes liaisons physiques ne sont pas toujours très propres (j'en suis impuissant) et qu'il faut déjà supporter la latence du chiffrement, la compression d'un flux incompressible est-elle pertinente ?
cherche retour d'expérience
Y en a-t'il ici qui connaissent bien OpenVPN et qui sont capable de donner leur avis sur la pertinence de la compression, avis validé par l'expérience, et non des suppositions comme moi ?
comment être sur que je désactive/active comp-lzo
Pour activer lzo je doit mettre comp-lzo dans les deux fichiers de conf à chaque bout du tunnel, pour ne pas l'avoir il suffirait de ne pas le mettre ? Je crains que ce ne soit par défaut. Je trouve des questions sur le net de personnes qui cherchent à désactiver lzo et qui n'y arrivent pas… Alors j'ai un doute…
Quand je lance OpenVPN, il m'affiche une ligne du genre :
Fri Apr 15 12:32:30 2011 OpenVPN #.#.# ### [SSL] [LZO2] […] built on ## ## ####
Je vois explicitement affiché [LZO2], mais peut-être n'est ce que pour me dire que ma version d'OpenVPN a été compilée avec ce support, et non qu'il est exploité. Comment puis-je être certain que je n'utilise pas lzo ? Au moins pour faire des benchs ?
# compression de compression
Posté par fcartegnie . Évalué à 4.
T'es du genre à zipper tes mp3 toi, non ?
[^] # Re: compression de compression
Posté par Yao Kuramoto . Évalué à 1.
Si je me rappelle bien, la compression openvpn concerne toute la trame ip qui circule dans le tunnel et non pas uniquement la partie data de la-dite trame ip (à vérifier tout de même, il m'arrive de dire des bêtises aussi).
Donc oui il peut y avoir du gain à compresser un tunnel vpn qui véhicule un stream compressé.
Mais ce gain est faible et utile pour des connections du genre satellite, quand t'as un débit de 10kb/s et énormément de latence, du genre 2500ms.
Bon c'est vrai que j'ai testé sur du apache avec mod_deflate dans du openvpn avec com-lzo. Ce qui est un peux différent du cas que tu évoque, donc là il serait bon de faire des tests de débit avec et sans comp-lzo, et openvpn en mode tcp ou udp par exemple.
[^] # Re: compression de compression
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Pour rester dans l'analogie, il faudrait déjà que j'utilise le format zip et le format mp3, ce qui est synonyme d'implémentation « naïve ».
Et justement, ce que je veux éviter, c'est cette naïveté. Si j'utilisais des cliquodromes, j'aurai la compression activée par défaut dans OpenVPN, et dans netJack.
Si j'ai posté un question, c'est que justement je veux faire des choses réfléchies et pertinentes.
Comme l'a écrit Yao Kuramoto, ce n'est pas seulement mon flux netJack qui sera compressé par lzo, mais tout ce qu'il y a autour. Ici on est dans des optimisations de bout de chandelles (1 octet de perdu dans le pire des cas non compressibles !) avec des contraintes très serrées : transmettre du son en temps réel avec faible latence sur un réseau ip inamical.
Une problématique liée, par exemple, c'est qu'avec netJack je peux définir une redondance d'émission, par exemple envoyer n fois chaque paquet. Puisque « un paquet en retard est un paquet inutile », sur un réseau pourri (wifi perturbé, par exemple), j'espère avoir au moins 1 paquet sur n à l'arrivée en forçant la liaison pourrie.
Si je compresse netJack, il est possible qu'OpenVPN me compresse ma redondance, ce qui est contre productif !
Si je m'embête à envoyer n fois chaque paquet mais que finalement, sur le fil, il ne passe qu'une fois avec une entête « recopier n fois à l'arrivée », ça ne sert à rien. Si je triple mes paquets, mais que je les perds trois par trois, ça ne sert à rien.
Merci de ne pas me prendre pour plus bête que je ne suis.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: compression de compression
Posté par Pierre Carrier . Évalué à 2.
Si tu n'es pas bête, tu sais que personne ne pourra connaître la viabilité des deux choix mieux que toi... Fais tes benchmarks.
Si tu veux benchmarker ce qui se passerait si les choses empiraient sur ton lien (latence, pertes, corruption de paquets, etc.), tu utilises netem.
[^] # Re: compression de compression
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
merci pour netem, je ne connaissais pas (l'ignorance n'est pas la bêtise ;-).
+1 parce que même si, comme tu l'as dit, je suis le mieux placé pour répondre à mon problème… le tuyau que tu me file vas beaucoup m'aider (c'est ça que j'attends ;), merci. Typiquement je vais pouvoir comparer avec ou sans lzo dans des conditions reproductibles et comparables, et ça c'est précieux !
ce commentaire est sous licence cc by 4 et précédentes
# C'pas compliqué
Posté par Kerro . Évalué à 3.
1 - ifconfig tun0 # pour voir le nombre d'octets transmis/reçu
2 - envoyer des données pendant 5 minutes
3 - ifconfig tun0 4 - faire la même chose sans la compression, et comparer
Enorme avantage: ça va correspondre pile-poil à ton besoin.
La compression LZO avec OpenVPN fonctionne très bien. Testée par mes soins depuis des années. Mais clairement, pour faire passer essentiellement des flux déjà compressés, pas forcément utile, surtout que ça ajoute un peu de données.
[^] # Re: C'pas compliqué
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
merci pour le retour !
ce commentaire est sous licence cc by 4 et précédentes
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.