URL: https://linuxfr.org/forums/general-general/posts/pertinence-de-la-compression-pour-un-vpn Title: Pertinence de la compression pour un VPN Authors: Thomas Debesse Date: 2011年04月15日T12:45:14+02:00 Tags: Score: 2 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](http://netjack.sourceforge.net/) entre deux serveurs [jackd](http://jackaudio.org/), ce flux est compressé avec le codec « ultra basse latence » [CELT](http://www.celt-codec.org/) du projet [Xiph.org](http://www.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](http://openvpn.net/index.php/open-source.html). D'habitude pour mes VPN j'active l'option `comp-lzo` que le man vante comme « ultra fast » et « real-time ». Le projet [LZO](http://www.oberhumer.com/opensource/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 ?