Protocole de bout en bout
onlytime
Messages postés
473
Statut
Membre
-
Smida_ahmed Messages postés 1 Statut Membre -
Smida_ahmed Messages postés 1 Statut Membre -
Bonjour à tous
En effectuant un ensemble de recherches...etc ,j'arrive toujours pas a comprendre qu'est ce qu'un protocole de bout en bout ,qui concerne que les couches 4,5,6,7 du modéles OSI alors que les 3 premiéres couches n'ont pas de protocoles de bout en bout
Merci
En effectuant un ensemble de recherches...etc ,j'arrive toujours pas a comprendre qu'est ce qu'un protocole de bout en bout ,qui concerne que les couches 4,5,6,7 du modéles OSI alors que les 3 premiéres couches n'ont pas de protocoles de bout en bout
Merci
A voir également:
- Protocole de bout en bout
- Tensiomètre bout du doigt application gratuite - Télécharger - Vie quotidienne
- Fonctionnement du protocole http - Guide
- Au bout de combien de temps les flammes snap disparaissent ✓ - Forum Snapchat
- Au bout de combien de temps on perd les flammes sur snap - Forum Snapchat
6 réponses
Bonjourno tout le monde,
Je ne pense pas que bout en bout signifie connecté.
UDP est un protocole bout en bout et est un protocole non connecté.
Bout en bout
Les processus pairs des couches transport de deux équipements connectés dialoguent l'un avec l'autre sans rien connaître du réseau. C'est au niveau IP que l'on se préoccupe de la fragmentation et du réassemblage des paquets.
cfr: http://www.linux-france.org/prj/inetdoc/articles/transmission.tcpip/transmission.tcpip.protocols.html
Pour le mode connecté c'est le principe d'établissement d'une liaison de communication avec un début et une fin par analogie au téléphone, bref plus d'info sur la toile, comme dhabs :)
Je ne pense pas que bout en bout signifie connecté.
UDP est un protocole bout en bout et est un protocole non connecté.
Bout en bout
Les processus pairs des couches transport de deux équipements connectés dialoguent l'un avec l'autre sans rien connaître du réseau. C'est au niveau IP que l'on se préoccupe de la fragmentation et du réassemblage des paquets.
cfr: http://www.linux-france.org/prj/inetdoc/articles/transmission.tcpip/transmission.tcpip.protocols.html
Pour le mode connecté c'est le principe d'établissement d'une liaison de communication avec un début et une fin par analogie au téléphone, bref plus d'info sur la toile, comme dhabs :)
"Connecté" serait plus appoprié que "bout en bout"
Ce n'est en rien systematique par rapport aux couches osi : UDP est un proto de couche 4 et ne fonctionne pas en mode connecté.
Le principe est de rendre un service en "communiquant" avec celui qui se trouve en face : on attend une reponse de sa part (ack par exemple) : cela permet par exemple de s'assurer que tout ce qui a été envoyé a été reçu ou de fournir du contrôle d'erreur. L'inconvenient est que ces protos sont plus lourds (plus complexes, plus d'information à vehiculer) et ne conviennent pas forcement à tous les besoins.
L'exemple classique pour imager cela est celui de la vo/ip : on ne va jamais reemettre un paquet s'il s'est perdu ;)
La voip fonctionne donc sur un mode non conecté.
Par contre, si je fais du FTP, il faut que tous les paquets soient bien reçus pour reconstituer mon fichier : mode connecté donc.
IP en couche 3 fonctionne effectivement mode non connecté ... mais un procole de routage comme BGP, par exemple, qui s'appuie sur IP fonctionne lui en mode connecté : bien souvent se sont les couches hautes qui sont de "bout en bout" : ça ne sert à rien de faire 2 fois la même chose : la couche basse est alors non conectée ....
Ce n'est en rien systematique par rapport aux couches osi : UDP est un proto de couche 4 et ne fonctionne pas en mode connecté.
Le principe est de rendre un service en "communiquant" avec celui qui se trouve en face : on attend une reponse de sa part (ack par exemple) : cela permet par exemple de s'assurer que tout ce qui a été envoyé a été reçu ou de fournir du contrôle d'erreur. L'inconvenient est que ces protos sont plus lourds (plus complexes, plus d'information à vehiculer) et ne conviennent pas forcement à tous les besoins.
L'exemple classique pour imager cela est celui de la vo/ip : on ne va jamais reemettre un paquet s'il s'est perdu ;)
La voip fonctionne donc sur un mode non conecté.
Par contre, si je fais du FTP, il faut que tous les paquets soient bien reçus pour reconstituer mon fichier : mode connecté donc.
IP en couche 3 fonctionne effectivement mode non connecté ... mais un procole de routage comme BGP, par exemple, qui s'appuie sur IP fonctionne lui en mode connecté : bien souvent se sont les couches hautes qui sont de "bout en bout" : ça ne sert à rien de faire 2 fois la même chose : la couche basse est alors non conectée ....
D'accord bout en bout==>connecté,alors une autre petite question sur internet on utilise les 2 modes ?
Bonjour,
Oui, on utilise les 2 et cela est également le cas la plupart du temps quel que soit le LAN : suivant l'applicatif que tu utilises, le mode connecté / non connecté va être utilisé.
Piur le savoir, il faut que tu te penches sur les protocoles.
Par exemple, si tu fais du ntp, snmp, dns tu vas faire de l'udp et donc du non connecté
Si tu fais du telnet, du ftp, du smtp, tu passes alors en tcp et donc en connecté.
Oui, on utilise les 2 et cela est également le cas la plupart du temps quel que soit le LAN : suivant l'applicatif que tu utilises, le mode connecté / non connecté va être utilisé.
Piur le savoir, il faut que tu te penches sur les protocoles.
Par exemple, si tu fais du ntp, snmp, dns tu vas faire de l'udp et donc du non connecté
Si tu fais du telnet, du ftp, du smtp, tu passes alors en tcp et donc en connecté.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Salut!!
merci pour votre aide,donc tout les protocoles sont prédefinis(integrés avec le Systéme d'exploitation réseau)par exemple quand j'utilise
le logiciel "filezilla" cela veut il dire que je vais activer le protocole FTP??donc travailler avec un mode connecté
autrement dit je peux basculer du mode connecté au mode non connecté sans effectuer des opération manuellement...
merci pour votre aide,donc tout les protocoles sont prédefinis(integrés avec le Systéme d'exploitation réseau)par exemple quand j'utilise
le logiciel "filezilla" cela veut il dire que je vais activer le protocole FTP??donc travailler avec un mode connecté
autrement dit je peux basculer du mode connecté au mode non connecté sans effectuer des opération manuellement...
Bonjour,
Je me pose une question sur cette notion de "bout en bout" ou "connecté" pour le protocole RTP.
Il est écrit ici :
https://www.commentcamarche.net/contents/535-les-protocoles-rtp-rtcp
que RTP est un protocole qui "offre un service de bout en bout" alors qu'il repose sur UDP.
Comment cela est-ce possible ? Est ce grâce à RTCP ?
Cordialement.
Je me pose une question sur cette notion de "bout en bout" ou "connecté" pour le protocole RTP.
Il est écrit ici :
https://www.commentcamarche.net/contents/535-les-protocoles-rtp-rtcp
que RTP est un protocole qui "offre un service de bout en bout" alors qu'il repose sur UDP.
Comment cela est-ce possible ? Est ce grâce à RTCP ?
Cordialement.
Bonjour,
A la base, les flux tps reels type voix video sont transmis via UDP : pas besoin d'un proto lourd type tcp puisque on ne va pas s'amuser à checker les paquets perdus et à les renvoyer : trop long par rapport aux exigences de délai qu'ont la voix et video.
C'est RTP qui se charge d'organiser les flux tps reels : même si on se "moque" des pertes de paquets, il faut tt de même faire en sorte que ceux arrives à destination soient traites dans le bon ordre, qu'il y ait synchronisation entre eux afin que le flux ne soit pas saccadé...etc, ...
RTP n'est pas un proto "connecté" au sens TCP du terme mais le fait qu'il dispose de numeros de sequences permet en autre de connaître les pertes eventuelles de paquets.
RTCP travaille en // de RTP : son rôle est plus d'organiser/controler l'envoi du flux par rapport aux différents demandeurs.
Note : aujourd'hui avec toutes les box permettant l'acces à la tv sur adsl, pour offrir une meilleur qualité de service, on voit apparaître des mecanismes qui viennent se superposer à la pile IP/UDP/RTP :on profite du fait que les flux sont buffurisés un certain temps par les setupbox pour traiter les pertes de sequences indiquées par RTP : les box, par l'intermediaire d'une couche logicielle additionnelle, redemandent les paquets manquant à des serveurs charges de conserves les flux : les paquets perdus sont alors renvoyé par ces serveurs ...!!
Le petit defaut du systeme est qu'il consomme de la bande passante supplémentaire et l'histoire tourne un peu au vinaigre quand les pertes sont systematiques (ligne dsl degradéé par exemple) : les paquets redemandes peuvent eux aussi être à leur tour perdu : effet boule de neige donc !!! (des securités doivent donc être misent en place pour ces cas de figure)
A la base, les flux tps reels type voix video sont transmis via UDP : pas besoin d'un proto lourd type tcp puisque on ne va pas s'amuser à checker les paquets perdus et à les renvoyer : trop long par rapport aux exigences de délai qu'ont la voix et video.
C'est RTP qui se charge d'organiser les flux tps reels : même si on se "moque" des pertes de paquets, il faut tt de même faire en sorte que ceux arrives à destination soient traites dans le bon ordre, qu'il y ait synchronisation entre eux afin que le flux ne soit pas saccadé...etc, ...
RTP n'est pas un proto "connecté" au sens TCP du terme mais le fait qu'il dispose de numeros de sequences permet en autre de connaître les pertes eventuelles de paquets.
RTCP travaille en // de RTP : son rôle est plus d'organiser/controler l'envoi du flux par rapport aux différents demandeurs.
Note : aujourd'hui avec toutes les box permettant l'acces à la tv sur adsl, pour offrir une meilleur qualité de service, on voit apparaître des mecanismes qui viennent se superposer à la pile IP/UDP/RTP :on profite du fait que les flux sont buffurisés un certain temps par les setupbox pour traiter les pertes de sequences indiquées par RTP : les box, par l'intermediaire d'une couche logicielle additionnelle, redemandent les paquets manquant à des serveurs charges de conserves les flux : les paquets perdus sont alors renvoyé par ces serveurs ...!!
Le petit defaut du systeme est qu'il consomme de la bande passante supplémentaire et l'histoire tourne un peu au vinaigre quand les pertes sont systematiques (ligne dsl degradéé par exemple) : les paquets redemandes peuvent eux aussi être à leur tour perdu : effet boule de neige donc !!! (des securités doivent donc être misent en place pour ces cas de figure)
Salut Nico, la différence entre un protocole connecté et un autre non-connecté est du fait que le premier demande que la source et la destination soient obligatoirement connecté pour pouvoir communiquer ce qui est en contradiction avec ce que vous venez de dire . Je me demande comment est-il possible qu'une communication VOIP repose sur un Protocole Comme UDP (même si ce dernier utilise RTP pour séquencer et ordonner les segment) pour se charger du transport de la voix ou de la video alors qu'il s'agit d'un protocole non-connecté . Merci de m'expliquer :-)
