| View previous topic :: View next topic |
| Author |
Message |
loopx
Advocate
Joined: 01 Apr 2005
Posts: 2787
Location: Belgium / Liège
|
 Posted: Wed Oct 07, 2009 7:38 am Post subject: [OpenVPN] UDP plus lent que TCP ??? |
 |
|
Bonjour,
Suite à mon poste précédent sur les VPN, j'ai passé celui-ci en UDP. En regardant les graphs dans cacti, je m'apperçois que j'ai perdu de la vitesse  le TCP était plus rapide ? Est-ce normal ??? C'est peut être ma ligne, j'attend encore pour en être sûr, mais ca à l'air de moins bien fonctionner  .
Quand je regarde la connexion qui traverse le deuxième vpn UDP ( A => B => C ; entre B et C, ca à toujours été en UDP, mais entre A et B, c'est passé de TCP en UDP) et ben, la vitesse est un peu plus faible. Genre, 45Ko/s et maintenant, 40Ko/s
Est-ce normal ? Y a t'il des valeurs spécifique intéressante pour tuner openvpn ?
EDIT: en fait, entre B et C (liaison qui était déjà en UDP), le transfert à diminué de quelques Ko/s (allais, 5) et je constate que les envoie sont presque 2x plus important :
down : 45Ko/s => 40Ko/s
up : 1Ko/s => 1,9Ko/s
Il me semblait pourtant que l'UDP était plus "légé" et donc, l'up devrait être moins utilié ??????? Etrange non ?
Quelqu'un pour m'aider à comprendre ce qu'il se passe ?
EDIT2:
| Quote: | Actually, in some applications TCP is actually faster ( gives better throughput ) than UDP.
This is the case when doing lots of small writes relative to the MTU size. For example, I read an experiment in which a stream of 300 byte packets was being sent over Ethernet ( 1500 byte MTU ) and TCP was 50% faster than UDP.
The reason is because TCP will try and buffer the data and fill a full network segment thus making more efficient use of the available bandwidth.
UDP on the other hand puts the packet on the wire immediately thus congesting the network with lots of small packets.
You probably shouldn't use UDP unless you have a very specific reason for doing so. Especially since you can give TCP the same sort of latency as UDP by disabling the Nagle algorithm ( for example if you're transmitting real-time sensor data and you're not worried about congesting the network with lot's of small packets ). |
_________________
Mon MediaWiki perso : http://pix-mania.dyndns.org |
|
| Back to top |
|
 |
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Wed Oct 07, 2009 9:52 am Post subject: |
|
|
Sur un LAN tu auras tout intérêt à utiliser UDP, par sur un WAN. (NFS a suivi ce chemin d'ailleurs: partant d'abord de l'UDP il a proposé ensuite le TCP)
Bien configuré (window size, delay, etc...) le TCP est nettement plus intéressant sur un WAN que l'UDP.
[edit]Ce que dit le mec dans ton edit, là sur un LAN par contre je suis perplexe. en UDP tes 300 octets sur un MTU à 1500... tu les envois en 1 paquet, tout comme en TCP d'ailleurs à ceci près que TCP va demander un accusé de réception pour chaque paquet... donc je vois vraiment pas comment il arrive à être plus rapide qu'en UDP. Amha il a pas du tout comprendre de la manip. (à mon avis il envois pas des paquets de 300 octets, il fait des write() à 300 octets ce qui est différent: UDP va envoyer direct les 300 octets, TCP lui va bufferiser tant que possible, au final là ouais TCP peut s'avérer plus rapide, et encore faut pas mal bidouiller ses options)
Ceci dit avec des lib telles qu'Enet (qui code en partie ce que fait TCP mais au dessus d'UDP), UDP se révèle être plus rapide que TCP donc ce qu'il dit là encore c'est un peu bidon. À l'entendre UDP sert à rien...[/edit] |
|
| Back to top |
|
|
loopx
Advocate
Joined: 01 Apr 2005
Posts: 2787
Location: Belgium / Liège
|
| Posted: Wed Oct 07, 2009 12:07 pm Post subject: |
|
|
je sais toujours pas si je dois prendre UDP ou TCP alors :s
De la doc pour tuner l'UDP/TCP serait la bienvenue 
_________________
Mon MediaWiki perso : http://pix-mania.dyndns.org |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Wed Oct 07, 2009 12:44 pm Post subject: |
|
|
| loopx wrote: | je sais toujours pas si je dois prendre UDP ou TCP alors :s
|
Si ton VPN est censé être accessible via internet y a pas à tortiller: TCP.
Quelque soit les 2 protocoles c'est dans le code que ça se tune.
Pour UDP y a pas grand chose à tuner. Pour TCP tu as des setsockopt() comme TCP_NODELAY qui reste le truc principale à utiliser en cas de recherches de performances.
Après tu peux jouer sur la couche IP via le setsockopt IP_TOS: IPTOS_LOWDELAY, IPTOS_THROUGHPUT etc... (pas testé sur UDP perso, je sais pas si ça affecte UDP autant que ça affecte TCP).
Sur un LAN en triturant TCP et IP comme il se doit il y a moyen d'être aussi rapide en TCP qu'en UDP (non bidouillé ni avec une lib par dessus)
Mattes un coup man 7 tcp et man 7 udp. Ainsi que la page de man setsockopt().
Après j'imagine que toutes ces tweaks ont leur désavantages, au détriment de la fiabilité des transfert etc...? |
|
| Back to top |
|
|
guilc
Bodhisattva
Joined: 15 Nov 2003
Posts: 3326
Location: Paris - France
|
| Posted: Wed Oct 07, 2009 3:14 pm Post subject: |
|
|
| kwenspc wrote: | | loopx wrote: | je sais toujours pas si je dois prendre UDP ou TCP alors :s
|
Si ton VPN est censé être accessible via internet y a pas à tortiller: TCP. |
Non, le VPN n'a pas a assurer la couche de fiabilité en mode connecté. Voir l'autre fil de loopx.
C'est le protocole qui transite au dessus du VPN qui assure ce rôle. LE VPN, c'est de la liaison, pas du transport !
UDP c'est même déjà overkill pour du VPN.
Maintenant, sur du WAN, si le débit baisse, ne pas oublier que le débit ADSL peut dépendre des phases de la lune, de la vitesse du vent et de la bonne humeur de la voisine, donc bon...
_________________
Merci de respecter les règles du forum.
Mon site perso : https://www.xwing.info
Mon PORTDIR_OVERLAY : https://gentoo.xwing.info ou layman -a xwing |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Wed Oct 07, 2009 3:48 pm Post subject: |
|
|
| guilc wrote: |
UDP c'est même déjà overkill pour du VPN.
|
là on parle pas de protocole genre L2TP donc d'ici là, vus ce que veut faire loopx: c'est soit UDP ou TCP. Sinon il peut toujours s'amuser avec ipsec... il y a 50 implémentations dont pas mal de projets qui petent tout tous les 5 du mois, même pas full compatibles entre elles malgré la norme etc ...
D'ailleurs, overkill... faut pas exagérer, bien codé un VPN over TCP ou UDP poutre suffisamment. Chais pas, j'imagine que loopx cherche pas à faire du streaming RT non? |
|
| Back to top |
|
|
loopx
Advocate
Joined: 01 Apr 2005
Posts: 2787
Location: Belgium / Liège
|
| Posted: Wed Oct 07, 2009 6:11 pm Post subject: |
|
|
| guilc wrote: | | kwenspc wrote: | | loopx wrote: | je sais toujours pas si je dois prendre UDP ou TCP alors :s
|
Si ton VPN est censé être accessible via internet y a pas à tortiller: TCP. |
Non, le VPN n'a pas a assurer la couche de fiabilité en mode connecté. Voir l'autre fil de loopx.
C'est le protocole qui transite au dessus du VPN qui assure ce rôle. LE VPN, c'est de la liaison, pas du transport !
UDP c'est même déjà overkill pour du VPN.
Maintenant, sur du WAN, si le débit baisse, ne pas oublier que le débit ADSL peut dépendre des phases de la lune, de la vitesse du vent et de la bonne humeur de la voisine, donc bon... |
J'aime bien ta théorie  j'ai openvpn donc ce sera soit tcp, soit udp. Le fait est que j'ai perdu 5Ko seconde!!!!!!!!!!!!! C'est éééééééééééééééééééééééééénorme  nan mais voilà, avec un tit upload de merde de belgiqueux, ben 5Ko, ca compte
Actuellement : tcp c'est pas top pour vpn, mais c'est pourtant celui qui est le plus rapide ; udp est le mieux théoriquement, mais c'est le moins rapide ..
Choix pas très évident ...
_________________
Mon MediaWiki perso : http://pix-mania.dyndns.org |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Wed Oct 07, 2009 8:13 pm Post subject: |
|
|
| loopx wrote: |
Actuellement : tcp c'est pas top pour vpn, mais c'est pourtant celui qui est le plus rapide ; udp est le mieux théoriquement, mais c'est le moins rapide ..
|
En "théorie" UDP est le mieux, mais seulement sur un réseau fiable si il est utilisé de manière brute (y la manière classe, cf plus bas). Alors bien sûr: TCP over UDP: tout ce qu'on a pas dans UDP, le protocole encapsulé (TCP donc) le gère. Ouais, mais avec les défaut du protocole sous-jacent.
Si tu veux, TCP s'adapte à la couche liaison sous-jacente, il travaille sa "fenêtre", combien de paquet (et quelle taille) il peut balancer, il discute avec le pair connecté distant etc... pas UDP.
Une application qui veut écrire autant de paquets UDP qu'elle peut... bah elle peut. Mais selon le contexte tu auras surement énormément de perte, de la corruption de donnée voir carrément de la congestion. Ce qui veut dire dans le cas de TCP over UDP: plus de travail pour TCP qui du coup doit redemander de renvoyer tel ou tel paquet mais toujours avec UDP en dessous qui joue au chien fou etc... Alors que TCP seul, aurait trouvé la meilleur combinaison pour éviter ce genre de problème.
Même sur un réseau fiable, UDP - mal utilisé - peut coller le boxon: on arrive à congestionner le réseau et hop.
Le fin mot de l'histoire: ton problème c'est pas UDP ou TCP... c'est OpenVPN 
Apparemment il utilise TRÈS mal UDP. Sinon tu aurais pas cette perte de bande passante: au mieux tu aurais un poil mieux voir beaucoup mieux qu'en TCP, au pire tu aurais la même chose. Je vois pas comment ça pourrait en être autrement. UDP bien utilisé, ça donne pas ce genre de soucis. Un UDP bien utilisé = on implémente un protocole basé sur UDP pour arriver à un bon compromis sur les avantages du TCP et de l'UDP et ça donne? Un protocole comme Enet par exemple, c'est à dire ça: http://enet.bespin.org/Features.html ça c'est la manière classe.
(Après t'as mal mal d'autres protocoles qui corrigent certains aspects d'UDP tout en tentant de garder de bonnes perfs: DCCP, SCTP...)
Avec OpenVPN tu vas devoir rester sur TCP. Dans le meilleur des mondes on aurait un truc comme laisse entendre guilc (ipsec, l2tp et autres: sur le papier c'est parfait pour les VPN), mais dans la réalité on doit faire avec des techniques de bidouilles
À propos de tes collègues qui t'ont cassés au taf (oui je suis tombé sur ton post sur le forum ubuntu... d'ailleurs personne t'as filés de bonnes réponses là bas ^^), ils ont donc rien pigés au film: si OpenVPN est moins performant avec UDP c'est pas UDP qui pue, c'est l'utilisation que fait OpenVPN d'UDP.
[edit] tiens un lien intéressant: http://www.frameip.com/nntp/comp-protocols-tcp-ip/29235-comp-protocols-tcp-ip-bad-udp-performance.htm [/edit] |
|
| Back to top |
|
|
loopx
Advocate
Joined: 01 Apr 2005
Posts: 2787
Location: Belgium / Liège
|
| Posted: Wed Oct 07, 2009 8:47 pm Post subject: |
|
|
kwenspc, tu marque un point pour TCP (et un bon gros point même ^^). Le fait que on utilise une "meilleur machine" pour la transmission du TCP d'origine, c'est pas si faux quand on y pense.
Mais, dans la théorie, c'est quand même l'UDP ; peut être y a t'il moyen de configurer OpenVPN en UDP avec d'autre valeur pour, par exemple, augmenter le buffer ?
Il faudrait que je regarde de ce coté la, sinon, bah ptet repasser au TCP ... Et niveau TCP, si j'ai plusieurs client sur ce VPN, ca gèrera aussi ? Qui est le plus succeptible de péter un cable ?
_________________
Mon MediaWiki perso : http://pix-mania.dyndns.org |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Thu Oct 08, 2009 5:32 am Post subject: |
|
|
| loopx wrote: |
Mais, dans la théorie, c'est quand même l'UDP ; peut être y a t'il moyen de configurer OpenVPN en UDP avec d'autre valeur pour, par exemple, augmenter le buffer ?
|
Si OpenVPN utilise UDP de manière brute, c'est à dire sans créer un protocole avancé par dessus qui lui permettent de gérer la bande passante, les congestions etc.... Amha y a rien à faire dans ce cas. L'UDP par défaut ne bufferise pas, ce serait à l'application de le faire.
Je viens de voir la page de man openvpn 2.1 http://www.openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html
Et en effet il y a des options pour ça: --sndbuf et --rcvbuf mais elles sont déjà par défaut au maximum.
Sinon tu as peut-être moyen de jouer sur des paramètres tel que: --mtu-test , --fragment max ou encore: --shaper
Cette dernière option te permet de fixer une bp maxi, ça pourrait peut-être aider à ce qu'OpenVPN ne balance pas ses paquets UDP à tire larigot.
Le mieux c'est que tu comprennes le rôles de ces options et que tu les testes une par une, avec des paramètres pertinents selon ton contexte. Vu ce que je vois OpenVPN doit pouvoir s'arranger en UDP mais il sait pas le faire tout seul.
| loopx wrote: |
Il faudrait que je regarde de ce coté la, sinon, bah ptet repasser au TCP ... Et niveau TCP, si j'ai plusieurs client sur ce VPN, ca gèrera aussi ? Qui est le plus succeptible de péter un cable ? |
TCP créant plus d'overhead, je dirais que si t'es en TCP avec de plus en plus de client tu verras ta bande passante plus vite descendre entre chaque client. Pour ce qui est de péter un câble (perte de paquets ou autre) là ce serait UDP, mais ça ça dépend de la qualité de la ligne (cf la citation de guilc sur les WAN) |
|
| Back to top |
|
|
guilc
Bodhisattva
Joined: 15 Nov 2003
Posts: 3326
Location: Paris - France
|
| Posted: Thu Oct 08, 2009 6:58 am Post subject: |
|
|
| kwenspc wrote: | | Cette dernière option te permet de fixer une bp maxi, ça pourrait peut-être aider à ce qu'OpenVPN ne balance pas ses paquets UDP à tire larigot. |
Non mais openvpn ne va pas balancer des paquets à tire larigot hein !
Il ne va envoyer de paquet que si l'appli qui transite dessus en envoie, il ne génère pas des paquets comme ça, pour le fun... Et l'appli qui transite dessus gère la congestion si elle en a besoin...
Je persiste mais : l'UDP de l'openvpn, ça ne joue le rôle que d'une bête encapsulation qui n'a pas besoin d'intelligence. Le but étant de faire circuler des paquets à destination d'un autre réseau sur un réseau donné (rajouter une couche avec un adressage différent + un chiffrement). Cela ne diminue en rien les propriétés des protocoles qui circulent dans le VPN.
'fin bon, après, vous faites comme vous voulez hein !
_________________
Merci de respecter les règles du forum.
Mon site perso : https://www.xwing.info
Mon PORTDIR_OVERLAY : https://gentoo.xwing.info ou layman -a xwing |
|
| Back to top |
|
|
kwenspc
Advocate
Joined: 21 Sep 2003
Posts: 4954
|
| Posted: Thu Oct 08, 2009 7:21 am Post subject: |
|
|
| guilc wrote: |
Je persiste mais : l'UDP de l'openvpn, ça ne joue le rôle que d'une bête encapsulation qui n'a pas besoin d'intelligence. Le but étant de faire circuler des paquets à destination d'un autre réseau sur un réseau donné (rajouter une couche avec un adressage différent + un chiffrement). Cela ne diminue en rien les propriétés des protocoles qui circulent dans le VPN. |
Ok, expliques moi pourquoi loopx voit alors une perte de bande passante dans son VPN quand il est en UDP? C'est *totalement* illogique, il devrait en gagner au moins un poil même (vu l'énorme différence d'overhead et le gain sur les paquet syn/ack dont on aurait plus besoin)!
Pour moi la seule et unique raison c'est qu'OpenVPN utilise mal UDP: il ne gère pas de throttling par défaut (d'où l'idée d'utiliser --shaper), dès qu'un paquet est lu du TUN/TAP il l'encapsule et l'envoi sans se poser la question si la ligne est prête pour ça. TCP arrive à corriger tant bien que mal le truc, mais comme il ne voit pas l'ensemble du contexte (lui ne discute qu'entre des devices TUN/TAP) il y a encore des aléas: d'où cette perte substantielle de BP (5Ko/s par rapport à du TCP over TCP c'est pas rien).
T'as une autre raison qui pourrait expliquer ça? |
|
| Back to top |
|
|
PabOu
Veteran
Joined: 11 Feb 2004
Posts: 1088
Location: Hélécine - Belgium
|
| Posted: Thu Oct 15, 2009 1:05 pm Post subject: |
|
|
| kwenspc wrote: | | T'as une autre raison qui pourrait expliquer ça? |
La priorité des paquets au niveau du réseau qui transporte le VPN. C'est pas rare de voir un FAI donner une plus faible priorité pour l'UDP que le TCP (je l'ai vu ici en Belgique)... C'est pour la même raison qu'il est conseillé de mettre le VPN sur des ports tels que 80 ou 443...
Edit : A part ça, je suis d'accord avec ta théorie, j'en étais venu à la même conclusion lors de mes tests il y a un certain temps.
_________________
Mangez du poulet ! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
