à quoi ca sert udp ?
je ne vois pas l'utilité d'avoir un protocole "non sécurisé" (c'est ca
?) où on n'est pas sur que tous les paquets arrivent à destination
ps : il parait que udp est utilisé par ssh, c'est vrai ?
--
In a world without walls and fences, who needs windows and gates ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine
On Fri, 23 Apr 2004 22:16:30 +0200, Thomas wrote:
à quoi ca sert udp ? je ne vois pas l'utilité d'avoir un protocole "non sécurisé" (c'est ca ?) où on n'est pas sur que tous les paquets arrivent à destination
Bonjour,
C'est utile pour le streaming, les jeux en réseaux ou la voix over ip ! Ca permet notamment d'éviter qu'une queue d'informations obsolète se forme.
ps : il parait que udp est utilisé par ssh, c'est vrai ? Clairement TCP comme appli.
On ne parle pas de sécurité pour différencier ces deux protocoles mais plutôt d'un mode connecté (TCP) et d'un mode non connecté (UDP).
à quoi ca sert udp ?
je ne vois pas l'utilité d'avoir un protocole "non sécurisé" (c'est ca
?) où on n'est pas sur que tous les paquets arrivent à destination
Bonjour,
C'est utile pour le streaming, les jeux en réseaux ou la voix over ip ! Ca
permet notamment d'éviter qu'une queue d'informations obsolète se forme.
ps : il parait que udp est utilisé par ssh, c'est vrai ?
Clairement TCP comme appli.
On ne parle pas de sécurité pour différencier ces deux protocoles mais
plutôt d'un mode connecté (TCP) et d'un mode non connecté (UDP).
à quoi ca sert udp ? je ne vois pas l'utilité d'avoir un protocole "non sécurisé" (c'est ca ?) où on n'est pas sur que tous les paquets arrivent à destination
Bonjour,
C'est utile pour le streaming, les jeux en réseaux ou la voix over ip ! Ca permet notamment d'éviter qu'une queue d'informations obsolète se forme.
ps : il parait que udp est utilisé par ssh, c'est vrai ? Clairement TCP comme appli.
On ne parle pas de sécurité pour différencier ces deux protocoles mais plutôt d'un mode connecté (TCP) et d'un mode non connecté (UDP).
Ça sert à envoyer des paquets pour des flux qui ne craignent pas la perte de paquet.
Exemple : - les requêtes et réponses de DNS n'ont pas besoin de s'assurer que tout est bien arrivé car si celui qui a émis la requête ne reçoit pas de réponse il va recommencer tout seul et le serveur qui répond n'a pas beoin de savoir si elle est bien arrivée (cela encombre inutilement le réseau) car si elle n'est pas arrivée une autre requête sera transmise ; et le taux d'erreur étant faible le débit est quasiment divisé par deux pour ce protocole, idem pour le DHCP.
- le streaming est un peu du même genre sauf qu'il y a reconstruction de data. Mais si un paquet arrive trop en retard il est abandonné et de plus le streaming peut être en temps réel (Voice Over IP) il est donc impossible de retransmettre un paquet qui n'est pas arriver si on veut conserver une transmission en temps réel, ou tout du moins la plus proche possible du temps réel qui soit (délai de transmission et de compression) il est donc inutile de rajouter une couche qui s'assure que les paquets arrivent à destination. De plus si tous ceux qui suivent une retransmission en temps réel d'un broadcast renvoyaient des paquets d'acquièssement cela encombrerait inutilement le réseau et le serveur qui émet.
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Thomas <fantome.forums.deContes@iFrance.com> wrote:
à quoi ca sert udp ?
Ça sert à envoyer des paquets pour des flux qui ne craignent pas la
perte de paquet.
Exemple :
- les requêtes et réponses de DNS n'ont pas besoin de s'assurer que tout
est bien arrivé car si celui qui a émis la requête ne reçoit pas de
réponse il va recommencer tout seul et le serveur qui répond n'a pas
beoin de savoir si elle est bien arrivée (cela encombre inutilement le
réseau) car si elle n'est pas arrivée une autre requête sera transmise ;
et le taux d'erreur étant faible le débit est quasiment divisé par deux
pour ce protocole, idem pour le DHCP.
- le streaming est un peu du même genre sauf qu'il y a reconstruction de
data. Mais si un paquet arrive trop en retard il est abandonné et de
plus le streaming peut être en temps réel (Voice Over IP) il est donc
impossible de retransmettre un paquet qui n'est pas arriver si on veut
conserver une transmission en temps réel, ou tout du moins la plus
proche possible du temps réel qui soit (délai de transmission et de
compression) il est donc inutile de rajouter une couche qui s'assure que
les paquets arrivent à destination. De plus si tous ceux qui suivent une
retransmission en temps réel d'un broadcast renvoyaient des paquets
d'acquièssement cela encombrerait inutilement le réseau et le serveur
qui émet.
--
Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Ça sert à envoyer des paquets pour des flux qui ne craignent pas la perte de paquet.
Exemple : - les requêtes et réponses de DNS n'ont pas besoin de s'assurer que tout est bien arrivé car si celui qui a émis la requête ne reçoit pas de réponse il va recommencer tout seul et le serveur qui répond n'a pas beoin de savoir si elle est bien arrivée (cela encombre inutilement le réseau) car si elle n'est pas arrivée une autre requête sera transmise ; et le taux d'erreur étant faible le débit est quasiment divisé par deux pour ce protocole, idem pour le DHCP.
- le streaming est un peu du même genre sauf qu'il y a reconstruction de data. Mais si un paquet arrive trop en retard il est abandonné et de plus le streaming peut être en temps réel (Voice Over IP) il est donc impossible de retransmettre un paquet qui n'est pas arriver si on veut conserver une transmission en temps réel, ou tout du moins la plus proche possible du temps réel qui soit (délai de transmission et de compression) il est donc inutile de rajouter une couche qui s'assure que les paquets arrivent à destination. De plus si tous ceux qui suivent une retransmission en temps réel d'un broadcast renvoyaient des paquets d'acquièssement cela encombrerait inutilement le réseau et le serveur qui émet.
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Thomas
merci à vous 2 pour ces explications qui m'ont l'air tres completes :-))
-- In a world without walls and fences, who needs windows and gates ?
merci à vous 2 pour ces explications qui m'ont l'air tres completes :-))
--
In a world without walls and fences, who needs windows and gates ?
merci à vous 2 pour ces explications qui m'ont l'air tres completes :-))
-- In a world without walls and fences, who needs windows and gates ?
Thomas
In article (Dans l'article) <192np8ee71kfa$, Antoine wrote (écrivait) :
On Fri, 23 Apr 2004 22:16:30 +0200, Thomas wrote:
à quoi ca sert udp ? je ne vois pas l'utilité d'avoir un protocole "non sécurisé" (c'est ca ?) où on n'est pas sur que tous les paquets arrivent à destination
Bonjour,
C'est utile pour le streaming, les jeux en réseaux ou la voix over ip ! Ca permet notamment d'éviter qu'une queue d'informations obsolète se forme.
ps : il parait que udp est utilisé par ssh, c'est vrai ? Clairement TCP comme appli.
merci :-)
je remarque une chose bizarre :
pour le vpn, dans le mode d'emploi de mon routeur, c'est indiqué :
pourquoi IPSec est en udp ??? parce que pour moi, le vpn c'est clairement TCP aussi comme appli, nan ??
-- "In a world without walls and fences, who needs windows and gates ?" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article)
<192np8ee71kfa$.1aavs1pn0lios.dlg@40tude.net>,
Antoine <thoNOPUBane@altern.org> wrote (écrivait) :
On Fri, 23 Apr 2004 22:16:30 +0200, Thomas wrote:
à quoi ca sert udp ?
je ne vois pas l'utilité d'avoir un protocole "non sécurisé" (c'est ca
?) où on n'est pas sur que tous les paquets arrivent à destination
Bonjour,
C'est utile pour le streaming, les jeux en réseaux ou la voix over ip ! Ca
permet notamment d'éviter qu'une queue d'informations obsolète se forme.
ps : il parait que udp est utilisé par ssh, c'est vrai ?
Clairement TCP comme appli.
merci :-)
je remarque une chose bizarre :
pour le vpn,
dans le mode d'emploi de mon routeur, c'est indiqué :
In article (Dans l'article) <192np8ee71kfa$, Antoine wrote (écrivait) :
On Fri, 23 Apr 2004 22:16:30 +0200, Thomas wrote:
à quoi ca sert udp ? je ne vois pas l'utilité d'avoir un protocole "non sécurisé" (c'est ca ?) où on n'est pas sur que tous les paquets arrivent à destination
Bonjour,
C'est utile pour le streaming, les jeux en réseaux ou la voix over ip ! Ca permet notamment d'éviter qu'une queue d'informations obsolète se forme.
ps : il parait que udp est utilisé par ssh, c'est vrai ? Clairement TCP comme appli.
merci :-)
je remarque une chose bizarre :
pour le vpn, dans le mode d'emploi de mon routeur, c'est indiqué :
pourquoi IPSec est en udp ??? parce que pour moi, le vpn c'est clairement TCP aussi comme appli, nan ??
Je ne trouve pas. Tous les protocoles à transporter dans un VPN n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à commencer par IP lui-même, UDP ou PPP.
Thomas wrote:
pour le vpn,
dans le mode d'emploi de mon routeur, c'est indiqué :
Mode PPTP : protocole TCP/Port 1723
PPTP a deux composantes. Il manque le protocole GRE (protocole IP 47).
pourquoi IPSec est en udp ???
parce que pour moi, le vpn c'est clairement TCP aussi comme appli, nan ??
Je ne trouve pas. Tous les protocoles à transporter dans un VPN n'ont
pas besoin de la fiabilité (et de la lourdeur) de TCP, à commencer par
IP lui-même, UDP ou PPP.
pourquoi IPSec est en udp ??? parce que pour moi, le vpn c'est clairement TCP aussi comme appli, nan ??
Je ne trouve pas. Tous les protocoles à transporter dans un VPN n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à commencer par IP lui-même, UDP ou PPP.
Thomas
In article (Dans l'article) , "Annie D." wrote (écrivait) :
Thomas wrote:
pour le vpn, dans le mode d'emploi de mon routeur, c'est indiqué :
Mode PPTP : protocole TCP/Port 1723
PPTP a deux composantes. Il manque le protocole GRE (protocole IP 47).
ah bon, ils se sont encore trompés ! ils avaient deja ecrit udp pour ssh
pourquoi IPSec est en udp ??? parce que pour moi, le vpn c'est clairement TCP aussi comme appli, nan ??
Je ne trouve pas. Tous les protocoles à transporter dans un VPN n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à commencer par IP lui-même, UDP ou PPP.
ah ok, donc en fait ceux qui en ont besoin utilisent tcp sur la 2 eme couche ip :-) ce que ne pouvait pas faire ssh :-)
-- "In a world without walls and fences, who needs windows and gates ?" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) <40D619EF.A6E781D6@free.fr>,
"Annie D." <annie.demur@free.fr> wrote (écrivait) :
Thomas wrote:
pour le vpn,
dans le mode d'emploi de mon routeur, c'est indiqué :
Mode PPTP : protocole TCP/Port 1723
PPTP a deux composantes. Il manque le protocole GRE (protocole IP 47).
ah bon, ils se sont encore trompés !
ils avaient deja ecrit udp pour ssh
pourquoi IPSec est en udp ???
parce que pour moi, le vpn c'est clairement TCP aussi comme appli, nan ??
Je ne trouve pas. Tous les protocoles à transporter dans un VPN n'ont
pas besoin de la fiabilité (et de la lourdeur) de TCP, à commencer par
IP lui-même, UDP ou PPP.
ah ok, donc en fait ceux qui en ont besoin utilisent tcp sur la 2 eme
couche ip :-)
ce que ne pouvait pas faire ssh :-)
--
"In a world without walls and fences, who needs windows and gates ?"
"petit Free qui devient grand, gêne les requins blancs"
ah bon, ils se sont encore trompés ! ils avaient deja ecrit udp pour ssh
pourquoi IPSec est en udp ??? parce que pour moi, le vpn c'est clairement TCP aussi comme appli, nan ??
Je ne trouve pas. Tous les protocoles à transporter dans un VPN n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à commencer par IP lui-même, UDP ou PPP.
ah ok, donc en fait ceux qui en ont besoin utilisent tcp sur la 2 eme couche ip :-) ce que ne pouvait pas faire ssh :-)
-- "In a world without walls and fences, who needs windows and gates ?" "petit Free qui devient grand, gêne les requins blancs"
Eric Masson
"Annie" == Annie D writes:
'Lut,
Annie> Je ne trouve pas. Tous les protocoles à transporter dans un VPN Annie> n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à Annie> commencer par IP lui-même, UDP ou PPP.
Tu as surtout le fait que si tu encapsules une session tcp dans une deuxième session tcp, tu vas commencer à remarquer des problèmes de gestion de taille de fenêtre conflictuelles entre la session externe et la session encapsulée si le lien que tu utilises subit des fluctuations de débit.
La plupart des protocoles autres qu'ipsec utilisés pour monter des vpn utilisent udp comme transport.
Eric Masson
-- Je propose que chacun de nous expose le problème (et dénoncent les fufeurs, cf liste des votants, ceux qui ont voté NNO sont les fufeurs) à son FAI. -+- Rocou In GNU - Comment tu écris Kommandantur ? -+-
"Annie" == Annie D <annie.demur@free.fr> writes:
'Lut,
Annie> Je ne trouve pas. Tous les protocoles à transporter dans un VPN
Annie> n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à
Annie> commencer par IP lui-même, UDP ou PPP.
Tu as surtout le fait que si tu encapsules une session tcp dans une
deuxième session tcp, tu vas commencer à remarquer des problèmes de
gestion de taille de fenêtre conflictuelles entre la session externe et
la session encapsulée si le lien que tu utilises subit des fluctuations
de débit.
La plupart des protocoles autres qu'ipsec utilisés pour monter des
vpn utilisent udp comme transport.
Eric Masson
--
Je propose que chacun de nous expose le problème (et dénoncent les
fufeurs, cf liste des votants, ceux qui ont voté NNO sont les fufeurs)
à son FAI.
-+- Rocou In GNU - Comment tu écris Kommandantur ? -+-
Annie> Je ne trouve pas. Tous les protocoles à transporter dans un VPN Annie> n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à Annie> commencer par IP lui-même, UDP ou PPP.
Tu as surtout le fait que si tu encapsules une session tcp dans une deuxième session tcp, tu vas commencer à remarquer des problèmes de gestion de taille de fenêtre conflictuelles entre la session externe et la session encapsulée si le lien que tu utilises subit des fluctuations de débit.
La plupart des protocoles autres qu'ipsec utilisés pour monter des vpn utilisent udp comme transport.
Eric Masson
-- Je propose que chacun de nous expose le problème (et dénoncent les fufeurs, cf liste des votants, ceux qui ont voté NNO sont les fufeurs) à son FAI. -+- Rocou In GNU - Comment tu écris Kommandantur ? -+-
Thomas
In article (Dans l'article) , Eric Masson wrote (écrivait) :
"Annie" == Annie D writes:
'Lut,
Annie> Je ne trouve pas. Tous les protocoles à transporter dans un VPN Annie> n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à Annie> commencer par IP lui-même, UDP ou PPP.
Tu as surtout le fait que si tu encapsules une session tcp dans une deuxième session tcp, tu vas commencer à remarquer des problèmes de gestion de taille de fenêtre conflictuelles entre la session externe et la session encapsulée si le lien que tu utilises subit des fluctuations de débit.
La plupart des protocoles autres qu'ipsec utilisés pour monter des vpn utilisent udp comme transport.
ok, je crois comprendre :-)
donc le vpn en general est en udp parce que l'ip est un protocole non connecté, ainsi si un protocole qui utilise le vpn a besoin de tcp, il l'utilise au dessus du vpn, le vpn n'en a besoin en aucun cas pour lui
alors que si on fait passer une connexion tcp par ssh, lui ne fait pas passer de paquets ip, mais directement les données, qui doivent donc etre transmises de facon fiable, donc il a besoin de tcp
j'ai bon ? :-)
merci à tous :-)
-- "In a world without walls and fences, who needs windows and gates ?" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article)
<861xk9rrg4.fsf@srvbsdnanssv.interne.kisoft-services.com>,
Eric Masson <emss@free.fr> wrote (écrivait) :
"Annie" == Annie D <annie.demur@free.fr> writes:
'Lut,
Annie> Je ne trouve pas. Tous les protocoles à transporter dans un VPN
Annie> n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à
Annie> commencer par IP lui-même, UDP ou PPP.
Tu as surtout le fait que si tu encapsules une session tcp dans une
deuxième session tcp, tu vas commencer à remarquer des problèmes de
gestion de taille de fenêtre conflictuelles entre la session externe et
la session encapsulée si le lien que tu utilises subit des fluctuations
de débit.
La plupart des protocoles autres qu'ipsec utilisés pour monter des
vpn utilisent udp comme transport.
ok, je crois comprendre :-)
donc le vpn en general est en udp parce que l'ip est un protocole non
connecté,
ainsi si un protocole qui utilise le vpn a besoin de tcp, il l'utilise
au dessus du vpn, le vpn n'en a besoin en aucun cas pour lui
alors que si on fait passer une connexion tcp par ssh, lui ne fait pas
passer de paquets ip, mais directement les données, qui doivent donc
etre transmises de facon fiable,
donc il a besoin de tcp
j'ai bon ? :-)
merci à tous :-)
--
"In a world without walls and fences, who needs windows and gates ?"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) , Eric Masson wrote (écrivait) :
"Annie" == Annie D writes:
'Lut,
Annie> Je ne trouve pas. Tous les protocoles à transporter dans un VPN Annie> n'ont pas besoin de la fiabilité (et de la lourdeur) de TCP, à Annie> commencer par IP lui-même, UDP ou PPP.
Tu as surtout le fait que si tu encapsules une session tcp dans une deuxième session tcp, tu vas commencer à remarquer des problèmes de gestion de taille de fenêtre conflictuelles entre la session externe et la session encapsulée si le lien que tu utilises subit des fluctuations de débit.
La plupart des protocoles autres qu'ipsec utilisés pour monter des vpn utilisent udp comme transport.
ok, je crois comprendre :-)
donc le vpn en general est en udp parce que l'ip est un protocole non connecté, ainsi si un protocole qui utilise le vpn a besoin de tcp, il l'utilise au dessus du vpn, le vpn n'en a besoin en aucun cas pour lui
alors que si on fait passer une connexion tcp par ssh, lui ne fait pas passer de paquets ip, mais directement les données, qui doivent donc etre transmises de facon fiable, donc il a besoin de tcp
j'ai bon ? :-)
merci à tous :-)
-- "In a world without walls and fences, who needs windows and gates ?" "petit Free qui devient grand, gêne les requins blancs"
