Les protocoles

Résumé

Protocole

Un protocole est une série d'étapes à suivre pour permettre une communication harmonieuse entre plusieurs ordinateurs ou périphériques reliés en réseau.

VoiP

La voix sur IP, ou « VoIP » pour Voice over IP, est une technique qui permet de communiquer par la voix (ou via des flux multimedia : audio ou vidéo) sur des réseaux compatibles IP, qu'il s'agisse de réseaux privés ou d'Internet, filaire (câble/ADSL/optique) ou non.

RTSP

Le RTSP ou real time streaming protocol est un protocole de communication. Il permet de contrôler un serveur média à distance, avec des fonctionnalités typiques telles que « lecture » et « pause ».

Bit Torrent

Protocole de partage en ligne basé sur la structure de réseau peer-to-peer. Ce dernier fonctionne de manière à ce que les clients s'échangent les paquets de données qu'ils n'ont pas afin de terminer le téléchargement de leur fichier (image, texte, audio).

VoiP

Voice over IP

Comme vous le savez, la grande majorité d’entre vous - pour ne pas dire tout le monde – utilisent des services de communication via le réseau Internet. Je parle plus précisément de la communication vocale. Ces services, tels que Skype et autres,fonctionne grâce à une technologie particulière. Cette technologie en question est celle de la voix sur IP. Elle porte le nom de « VoIP » pour désigner « Voice over IP » qui signifie en français « ‘transport de’ voix sur IP ». Il y a peu, l’émergence d’une telle technologie marquait un tourant dans le monde de la communication. En effet, la convergence vers le modèle du Triple Play (voix, données et vidéo) fait partie des enjeux principaux des acteurs de la télécommunication aujourd’hui. Il devenait clair que dans le sillage de cette avancée technologique, les opérateurs ou entreprises et autres devaient , pour bénéficier de l’avantage du transport unique sur IP, introduire de nouveaux services voix et vidéo. Je me permet de vous rappeler qu’à l’époque, le seul moyen de communication sur le marché était en majeure partie la téléphonie, ce qui ne représente que le transport de voix. Ainsi, c’est en 1996 que vit le jour la toute première version du VoIP apellée H323 : il s’agit d’un standard issu de l’organisation ITU-T, qui a maintenant donné suite à de nombreuses évolutions. Les premières technologies de VoIP imaginées étaient propriétaires et donc très différentes les unes des autres. Pourtant, un système qui est censé mettre des gens et des systèmes en relation exige une certaine dose de standardisation. C'est pourquoi sont apparus des protocoles standards, comme le H323 ou le SIP.



Fonctionnement

Le transport de la voix sur IP est relativement complexe. La première étape est la numérisation du signal acoustique. C'est le codage : la voix provoque une superposition de signaux sinusoïdaux, qui sont analogiques. Pour l'envoyer sur un réseau numérique, il va falloir convertir ce signal analogique en un signal numérique. Suite au processus de numérisation, la voix sera réprésenté sour le format PCM (Pulse Code Modulation - modulation par impulsion et codage). Une fois convertie, la voix numérisée doit être compressée grâce à un codec (Codeur/Décodeur) pour l'insérer dans un paquet IP. De manière générale, le signal numérique obtenu par numérisation de la voix est découpé en paquets qui sont transmis sur un réseau IP vers une application qui se chargera de la transformation invers. Pour transmettre les paquets, on utilise RTP, Real-time Transport Protocol , standardisé en 1996. C’est un protocole adapté aux applications présentant des propriétés de temps réel. Il permet ainsi de reconstituer la base de temps des flux (horodatage des paquets), de détecter les pertes de paquets et en informer la source, et d'identifier le contenu des données pour leurs associer un transport sécurisé. En revanche, ce n'est pas "la solution" qui permettrait d'obtenir des transmissions temps réel sur IP. En effet, il ne procure pas de fiabilisation des échanges (pas de retransmission automatique, pas de régulation automatique du débit) ni de garantie dans le délai de livraison. Bien qu'autonome, RTP peut être complété par RTCP, Real time Transport Control Protocol. Ce dernier apporte un retour d'informations sur la transmission et sur les éléments destinataires. Ce protocole de contrôle permet de renvoyer à la source des informations sur les récepteurs et ainsi lui permettre, par exemple, d'adapter un type de codage ou encore de modifier le débit des données.



Gateway – Gatekeeper

Avant de passer aux standards VoIP, je dois parler d’un des éléments clefs d’un réseau VoIP : la « passerelle » ou « gateway » et leurs « gatekeeper » associés. Les Gateways sont des ordinateurs qui fournissent une interface où se fait la convergence entre les réseaux téléphoniques commutés (RTC) et les réseaux basés sur la commutation de paquets TCP/IP.Pour rappel, le mot  « commutation » définit le lien entre correspondants sur le réseau.

L’étape du Gateway est donc une partie essentielle de l'architecture du réseau de téléphonie IP. Le Gatekeeper quant à lui est l'élément qui fournit de l'intelligence au Gateway. Le Gatekeeper est le compagnon logiciel deu Gateway. Il faut donc voir cette étape constittuée de deux parties complémentaires : Le Gateway étant le matériel, et le Gatekeeper étant le logiciel. Hardware et Software.

La Gateway fournit la possibilité d'établir une connexion entre un terminal analogique et un terminal multimédia (un PC en général). Il n’offre donc pas de grands services. C’est pourquoi c’est le Gatekeeper qui marque la différence entre deux Gateway, au même titre que deux PC identiques « physiquemen »t seront distingués par le logiciel qu’ils contiennent.

Un Gatekeeper propose deux services principaux : la gestion des permission et la résolution d'adresses. Il est aussi responsable de la sécurité. Quand un client veut émettre un appel, il doit le faire au travers du gatekeeper. C'est alors que celui-ci fournit une résolution d'adresse du client de destination.



Standards VoIP

H.323

H.323 regroupe un ensemble de protocoles de communication de la voix, de l'image et de données sur IP. C'est un protocole développé par l'UIT-T qui le définit comme : « Systèmes de communication multimédia en mode paquet ». H.323 ressemble davantage à une association de plusieurs protocoles différents et qui peuvent être regroupés en trois catégories : la signalisation, la négociation de codec, et le transport de l'information. Les messages de signalisation sont ceux que l’on envoie pour demander d’être mis en relation avec une autre personne, ou qui indiquent que la ligne est occupée, que le téléphone sonne… Cela comprend aussi les messages que l’on envoie pour signaler que tel téléphone est connecté au réseau et peut être joint de telle manière. Les protocoles utilisés pour la signalisation sont le RAS et le Q.931. La négociation est utilisée pour se mettre d’accord sur la façon de coder les informations qu’on va s’échanger. Il est important que les téléphones (ou systèmes) parlent un langage commun s’ils veulent se comprendre. Il serait aussi préférable, s’ils ont plusieurs alternatives de langages qu’ils utilisent le plus adapté. Il peut s’agir du codec le moins gourmand en bande passante ou de celui qui offre la meilleure qualité. Le protocole utilisé pour la négociation de codec est le H.245 Le transport de l’information s’appuie sur le protocole RTP qui transporte la voix, la vidéo ou les données numérisées par les codecs. On peut aussi utiliser les messages RTCP pour faire du contrôle de qualité, voire demander de renégocier les codecs si, par exemple, la bande passante diminue.

SIP

Session Initiation Protocol (SIP) est un protocole standard ouvert de gestion de sessions souvent utilisé dans les télécommunications multimédia (son, image, etc.) Il est depuis 2007 le plus courant pour la téléphonie par internet (la VoIP). SIP n'est pas seulement destiné à la VoIP mais aussi à de nombreuses autres applications telles que la visiophonie, la messagerie instantanée, la réalité virtuelle ou même les jeux vidéo en ligne. SIP est un protocole de la couche application (et non de la couche session comme son nom pourrait le laisser croire), normalisé et standardisé par l'IETF, qui a été conçu pour établir, modifier et terminer des sessions multimédia. Il se charge de l'authentification et de la localisation des multiples participants. Il se charge également de la négociation sur les types de média utilisables par les différents participants. SIP ne transporte pas les données échangées durant la session comme la voix ou la vidéo.

Etant indépendant de la transmission des données, tout type de protocoles peut être utilisé pour cet échange. Cependant le protocole RTP assure le plus souvent les sessions audio et vidéo. SIP remplace progressivement H.323. SIP partage de nombreuses similitudes avec le protocole HTTP comme le codage en ASCII et les codes de réponse.

Le client envoie des requêtes au serveur, qui lui renvoie une réponse. Les méthodes de base sont :

  • INVITE permet à un client de demander une nouvelle session,
  • ACK confirme l'établissement de la session,
  • CANCEL annule un INVITE en suspens,
  • BYE termine une session en cours,
  • OPTIONS permet de récupérer les capacités de gestion des usagers, sans ouvrir de session,
  • REGISTER permet de s'enregistrer auprès d'un serveur d'enregistrement.
  • Les codes de réponse sont similaires à HTTP :

  • 100 Trying,
  • 200 OK,
  • 404 Not Found.


  • RTSP

    Real Time Streaming Protocol

    Le RTSP ou real time streaming protocol est un protocole de communication. Il permet de contrôler un serveur média à distance, avec des fonctionnalités typiques telles que « lecture » et « pause ». Il appartient à la couche 7 du modèle OSI, donc à la couche application.



    Pour commencer il est bon de se demander qu'est-ce que le streaming ; le streaming consiste à découper les données en paquet dont la taille est adaptée à la bande passante entre le client et le serveur. Quand le client a reçu suffisamment de paquets (buffering en anglais), l'application cliente va commencer par jouer un paquet, tout en décompressant le suivant et en recevant le prochain. L'utilisateur profite donc du flux multimédia sans avoir à le télécharger en entier d'un seul coup. Il y a néanmoins un retard entre l'upload en direct du serveur et ce que voit l'utilisateur du à la bufferisation.



    Il faut néanmoins préciser que le RTSP ne fonctionne pas seul, en effet il se base sur d'autre protocole, comme le RTP et le RSVP (respectivement Real-time transport protocol et Resource reservation protocol). Le RTP est un protocole de communication permettant le transport de données soumise à des contraintes de temps réel, c'est donc ce protocole qui permet d'échanger les données entre le serveur et le client. Le RSVP est quant à lui un protocole qui sert à réserver des ressources, c'est un protocole qui permet d'allouer dynamiquement de la bande passante aux applications orientées réseaux. Pour faire une allégorie on peut dire que le RTP joue le rôle d'un serveur dans un restaurant, il apporte les plats à table, dans le bon ordre et au bon moment tandis que le RSVP joue le rôle du réceptionniste et prend note de votre réservation pour vous assurer une table libre dans le restaurant.



    Le RTSP joue un rôle de télécommande, en effet il a des fonctionnalités proche de celle-ci car il permet au client de pouvoir lire, mettre sur pause, rembobiner, faire une avance rapide ou même arrêter un média. RTSP peut contrôler et synchroniser plusieurs flux audio ou vidéo mais il faut bien comprendre qu'il ne fournit pas lui même les flux, c'est le rôle du RTP de les fournir.



    Comment fonctionne la diffusion en temps réel ?

    Pour fournir une production sur le serveur média on doit la coder en utilisant un codec (encoder / décoder). Le codec va permettre le codage pour les différents débits, c'est à dire qu'il code les fichiers différents avec le même flux de données en différente qualité. Les protocoles de transmissions choisissent ensuite le flux qui correspond le mieux au débit. C'est comme ça que lorsqu'on charge une vidéo ou un fichier audio en temps réel, ils sont automatiquement mis dans une qualité lisible en fonction du débit, par exemple si l'on dispose d'une faible connexion une vidéo YouTube sera lu en basse définition automatiquement. Un stream contient toujours plusieurs flux, un flux audio, un flux vidéo et parfois même un flux texte, ces différents flux peuvent être sur différentes machines et c'est aux protocoles de les synchroniser pour pouvoir les exploiter en même temps.



    Le RTSP possède plusieurs requêtes spécifiques, la première d'entre elle est la requête « option » qui permet au client de savoir qu'est-ce qu'il peut faire comme requête sur le serveur.

  • La requête « describe » donne au client une description du média qu'il regarde (le format d'enregistrement, la taille etc...) .
  • La requête « setup » permet de demander au serveur l'allocation des ressources et de commencer une session RTSP.
  • La requête « play » ordonne au serveur de lire le média.
  • La requête « pause » permet de mettre sur pause la lecture du média.
  • La requête « record » enregistre le média qui est streamé.
  • La requête « announce » est différente si elle est effectué par le client pour le serveur, ou par le serveur pour le client. Dans le premier cas elle affiche la description du média, dans le second elle met à jour les descriptions.
  • La requête « teardown » met fin à la session du stream.
  • La requête « redirect » informe le client qu'il doit se connecter à un autre serveur et le redirige vers celui-ci.


  • Un peu d'histoire concernant le RTSP ; Il a été développé par l'entreprise RealNetworks, Netscape et l'université de Columbia. Il a été standardisé en 1998 sous la RFC 2326.



    Pour conclure le RTSP est un protocole utilisé dans presque tous les logiciels de reproduction multimédia, comme YouTube, VLC, Skype, Spotify et bien d'autre. C'est donc un protocole que nous sommes amenés à utiliser chaque jour sans même le savoir. Il joue un rôle très important car on peut le comparer au HTTP. Ce qu'est le HTTP pour les pages Web, RTSP l'est pour les diffusions en temps réel. Il faut bien retenir que le RTSP ne s'occupe pas des transports des données. C'est pourquoi il envoie seulement des messages et non des paquets, ce protocole ne peut donc fonctionner seul mais c'est celui que l'on peut gérer le plus facilement étant donné qu'il permet à l'user de communiquer avec le serveur.

    Bit Torrent et P2P

    Le Bit Torrent et le Peer 2 Peer

    I) Le protocole Bit Torrent et le P2P.



    a) Définition

    Le protocole a été conçu en Avril 2001 puis mis en place à l'été 2002 par le programmeur Bram Cohen. Il est maintenu depuis 2004 par la société Bit Torrent Incorporation.

    Le protocole Bit Torrent est un protocole de transfert de données. Un protocole de transfert de données permet à deux terminaux de s'échanger des fichiers au travers d'un réseau. Le serveur est le terminal qui propose le fichier et le client est celui qui compte le télécharger. Le flux d'informations va généralement du serveur aux clients.

    Cependant le Bit Torrent est un protocole qui utilise le modèle de réseau « pair à pair » (« peer to peer » en anglais, majoritairement appelé de manière abrégée le « P2P »)



    b) Le P2P : nature et fonctionnement

    Il est beaucoup utilisé pour le partage de fichiers, la communication ou encore au calcul distribué (qui revient à répartir un calcul sur plusieurs microprocesseurs, ou plus généralement sur plusieurs unités centrales). Le P2P est un modèle de réseau proche du modèle client-serveur (un serveur pour plusieurs clients).

    Dans un modèle client-serveur, quand une information se trouve sur un nœud (poste connecté par un protocole réseau P2P), plus elle est demandée, moins elle est accessible. La nouvelle façon de procéder du protocole BitTorrent consiste à découper l'information en segments et à donner différents segments à quelques nœuds afin qu'ils se les échangent entre eux.

    Tout d'abord, un fichier sous forme de torrent est mis à disposition sur un réseau P2P depuis une application Web (du type BitTorrent, μTorrent, Azureus). Une fois qu'au moins un poste à demandé à recevoir le fichier, celui-ci est alors décomposé en petits « blocs » d'informations.

    Un serveur appelé tracker est dès lors chargé de lister l'ensemble des postes possédant un bloc minimum. Grâce au tracker, les différents blocs peuvent arriver aux ordinateurs dans n'importe quel ordre et depuis des sources multiples (le fichier est téléchargé quand tous les blocs sont parvenus à l'ordinateur). Ce qui veut dire que les données peuvent être transférées entre des postes directement connectés par TCP/IP sans transiteur central.

    Si des blocs corrompus apparaissent, ils sont automatiquement rejetés durant le transfert.

    Une loi permet de profiter pleinement du P2P: « Plus tu donnes, plus tu reçois ». En effet, un ratio d'échange (nombre de téléchargements / nombre de partages) est calculé par le réseau P2P. Cela veut dire que lorsqu'un individu partage régulièrement des fichiers sur une application Web avec un réseau peer-to-peer, il sera plus facile pour lui de recevoir les fichiers qu'il désire depuis cette même application.



    c) Quelques différences du BitTorrent face au P2P

    Contrairement au P2P, le BitTorrent n'utilise pas de tracker. Il n'y a donc pas de liste des postes dans la même salle de partage pour un même fichier.

    Aussi, la loi du P2P ne s'applique pas au BitTorrent. Il n'est donc pas nécessaire aux utilisateurs d'avoir déjà partagé un fichier pour en recevoir. Un utilisateur peut malgré ça rester connecté afin de laisser le fichier assez longtemps pour qu'il soit plus vite téléchargeable. Les utilisateurs ne sont pas obligés de le faire, mais les personnes civilisées situées parmi eux (seeders) le font. Ces personnes permettent de créer un cercle vertueux (≠ cercle vicieux). À l'inverse, les leechers (sangsues) téléchargent uniquement.



    II) Avantages et Inconvénients



    a) Avantages

    Le BitTorrent permet de distribuer de grandes quantités de données assez rapidement.

    Il est basé sur un hébergement Internet, ce qui ne créé aucune saturation de serveur.

    La validité des données est garantie : si le fichier est corrompu, c'est qu'il l'a été soit à l'origine, soit après le téléchargement (RAM défectueuse, par exemple) car quelconque bloc corrompu lors du partage en réseau P2P est immédiatement supprimé.

    L'efficacité du réseau est optimale en fonction du nombre de nœuds. Il y a donc une certaine instantanéité dans le téléchargement des données, ce qui en général ne provoque pas de file d'attente tant qu'au moins 2 personnes partagent le fichier).

    Le protocole de réseau BitTorrent est équipé d'un système QOS (Quality Of Service), qui agit sur le partage en permettant de transporter dans de bonnes conditions (délais, débit, disponibilité, ...).



    b) Inconvénients

    Le téléchargement en réseau BitTorrent provoque une hausse de la bande passante (détermine le débit binaire maximale d'un canal de communication informatique). Ce qui risque de doubler voire tripler la consommation de la connexion Internet à débit limité, en fonction évidemment du volume de données uploadées ou downloadées.

    Cela peut aussi causer par exemple la cessation directe d'un téléchargement HTTP/FTP. Pour éviter toute saturation, il est conseillé de configurer l'application afin qu'elle n'utilise que 80% de la borne passante.

    L'arrivée d'un nouveau nœud durant un téléchargement est très ralentissant.