IV / INTERNET

4-1 / Les structures

Le cas du développement du réseau mondial Internet est assez particulier car il a été
éclatant et parce qu’il n’y a pas d’autorité unique qui gère la totalité du réseau.
La complexité des structures était telle que, pour faciliter la coordination des groupes,
l’Internet Society a été créé (ISOC) en 1992. L’ISOC est une association sans but lucratif
(sans rendement) qui regroupe les professionnels de tous les horizons d’Internet.
Les structures d’Internet sont de deux types :
(1) celles qui ont la charge de la distribution des adresses et de l’information (figure 2,
partie gauche), et
(2) celles qui définissent la technologie (figure 2, partie droite).

Fig2. Les structures qui gèrent Internet.

Les adresses et les noms

INTERNIC (Internet Network Information Center) et la société Network Solutions
étaient chargés du contrôle des adresses au niveau mondial, déléguant leur pouvoir à
l’organisme Réseaux IP Européens (RIPE) pour l’Europe. RIPE déléguait ensuite
partiellement son pouvoir à des sociétés commerciales qui exploitent directement le réseau
Internet.
Des modifications sont intervenues afin de garantir une plus grande équité dans l’attribution
des adresses et des noms ; on pensait initialement que l’ITU pouvait s’investir dans cette
mission mais cette idée a été abandonnée au profit de l’ICANN (Internet Corporation for
Assigned Names and Numbers) qui officie comme le régulateur des organismes autorisés à
octroyer des noms de domaine.

En matière de domaines principaux (Top-Level Domain ou TLD, dite aussi extension),

les noms génériques sont limités à sept : .com (commerce), .mil (militaire), .int (international),

9
.gov (gouvernement), .org (organisation), .net (réseau) et .edu (éducation aux États-Unis).
Tous datent de la fin des années 1980.
Depuis, les suffixes désignant les pays (.dz par exemple pour l’Algérie) sont venus, au milieu
des années 1990, enrichir la nomenclature.
Actuellement de nouveaux suffixes existent proposés par l’ICANN: .aero, .biz,
.coop, .info, .museum, .name et .pro.

La technologie
La définition des standards en vigueur sur Internet s’effectue par des organismes
spécifiques. Le centre nerveux est l’Internet Engineering Task Force (IETF) organisme
bénévole qui canalise les développements, organisé en 8 secteurs de recherche.
Les résultats des travaux sont publiés sous la forme de Request For Comments (RFC).
Ces documents, disponibles gratuitement sur Internet (www.ietf.org), font l’objet de
discussion et certains deviennent des standards comme par exemple : RFC 791 (décrit IP)
après une procédure que contrôle l’Internet Architecture Board (IAB). Les travaux de
recherche sont effectués au sein de l’Internet Research Task Force (IRTF).
Enfin, l’Internet Assigned Number Authority (IANA) définit toutes les grandeurs
arbitraires (par exemple l’équivalent des préfixes téléphoniques pour Internet). Cette société
héberge aussi la base de données des Country Code Top Level Domains. On y trouve par
exemple des informations sur la gestion des noms de domaines nationaux comme .fr.
Ces groupes ne sont pas les seuls. Ainsi le World Wide Web Consortium (W3C)
effectue tout le travail relatif au Web. Dans certains cas, les résultats obtenus sont ensuite
présentés à l’IETF pour adoption. Ainsi, les normes HTML 4.0, XML ou HTTP/1.1 ont
d’abord été définies par le W3C, avant d’être soumises à l’IETF pour approbation.

Request For Comments. Le RFC (Request for Comments) est le document de base en
matière de normalisation pour Internet. L’ensemble des documents RFC est disponible
gratuitement sur Internet. Initialement, ces documents étaient soumis pour commentaire. Avec
le développement d’Internet, les structures ont été revues et, si le nom demeure, les textes des
RFCs sont des documents qui ont fait l’objet de débats préalables. À titre d’illustration, la
figure 3 reprend une partie de l’index des RFCs.

Fig3. Une partie de l’index des RFCs.

10
On remarquera que tous les RFCs ne sont pas des standards ; certains sont des propositions de
standard, d’autres des règles de bonne pratique, d’autres encore sont à caractère informel, …
Le statut d’un RFC est spécifié dans l’en-tête de chaque document. La figure 4 montre le
début de deux RFCs.

Fig4. En-têtes de deux RFCs.

4-2 / La vision d’Internet

Développer un standard international pour un produit complexe est un travail lourd et

long. Pour éviter la lenteur, les inventeurs d’Internet ont décidé de découper le travail en
douze domaines distincts pour lesquels il était possible de développer rapidement une
solution. On a donc vu apparaître très tôt des produits conformes aux premières spécifications.
Par la suite, ces spécifications ont été étendues et intégrées.

À la différence des organismes de normalisation, Internet a ainsi préféré encourager la

réalisation de produits, simples au départ, et canaliser les développements en procédant par
étapes successives plutôt que fournir des standards qui, une fois définis, devraient encore être
implémentés. La figure 5 schématise l’approche traditionnelle et l’approche d’Internet en
matière de normalisation. L’approche traditionnelle est plus lente car elle nécessite un long
temps de gestation avant l’implémentation de la norme. L’approche utilisée dans le cadre
d’Internet est plus rapide mais elle créée une série de normes intermédiaires qui entraîne
parfois une certaine confusion sur les marchés.

11
 Fig5. – Approche traditionnelle et approche d’Internet en matière de normalisation.

4-3 / Les protocoles

L’interactivité nécessite l’usage d’un réseau lorsque plusieurs acteurs interviennent.

Avec l’arrivée du réseau mondial Internet, les applications multimédia subissent une véritable
transformation.
Pourtant, les problèmes d’une communication sur un réseau sont multiples :
– Comment peut-on reconnaitre un correspondant ?
– Comment dialoguer avec lui ?
– Comment diffuser l’information à plusieurs correspondants ?
– y a t-il une hiérarchie des machines ?

La communication passe obligatoirement par la mise en réseau des terminaux. Cette dernière
nécessite alors l’établissement de conventions claires et non ambiguës, d’autant plus qu’on
assiste à un accroissement de l’interopérabilité des réseaux informatiques et des réseaux de
télécommunications.
Partant de ce concept, un modèle d’architecture pour les protocoles de communication a été
développé par l’ISO que l’on appelle Open System Interconnection Reference Model (OSI).

Les organismes de normalisation ont travaillé à définir des protocoles différents sur
l’Internet, certains sont très populaires d’autres absolument pas.
Certains protocoles prévoient l’envoi de paquets d’information, sans établissement préalable
d’un circuit ; C’est le cas notamment du protocole réseau utilisé pour l’Internet : le protocole
IP. Ou bien alors la transmission de données selon l’architecture OSI et celle utilisée sur
Internet de nos jours baptisée TCP/IP, du nom des deux principaux protocoles qui la
constituent.

12
Modèle de référence osi
Un des intérêts majeurs du modèle en couches est de séparer la notion de
communication, des problèmes liés à la technologie employée pour véhiculer les données.
Le modèle de référence développé par l’ISO comporte 7 couches ; à chaque couche est
associée une fonction bien précise, l’information traverse ces couches, chacune y apporte sa
particularité.
La figure 6 montre la communication entre deux ordinateurs à travers un réseau suivant le
modèle OSI.

Fig 6. - Structure générale du modèle OSI

Les trois couches inférieures sont liées au réseau ; elles concernent les mécanismes de
communications entre ordinateurs. Les trois couches supérieures gèrent les aspects propres
aux applications. Au centre, la couche transport sert de tampon entre les deux autres séries de
couches.
Par exemple, la couche transport permet la transmission de messages indépendants du réseau
au niveau de la couche session et s’appuie sur la couche réseau pour transmettre ses messages
à la couche transport d’un autre ordinateur. Concrètement donc, la couche masque
l’implémentation des couches inférieures de sorte que l’application soit indépendante du
réseau.
Chaque couche ne voit et ne sait communiquer qu’avec la couche qui la précède et celle qui la
suit.

La figure 7 reprend respectivement les fonctionnalités principales et services de l’ensemble

des couches.

13
Fig 7. - Résumé des principales fonctions du modèle OSI.

14
Le mode de fonctionnement des couches liées au réseau dépend du réseau physique auquel est
raccordé l’ordinateur.
 La couche réseau est responsable de l’établissement et de la libération d’une
connexion. Elle comprend des fonctionnalités comme le routage, aussi appelé
adressage, et parfois le contrôle du débit.
 Comme son nom l’indique, la couche liaison veille sur l’état de la connexion. Elle se
charge de la détection d’erreur et de la retransmission de messages si nécessaire. Elle
offre deux types de service :
1. Sans connexion permanente, connectionless en anglais. Ce type de connexion traite
chaque trame d’information comme une unité autonome transmise sans garantie
d’arriver à destination. De plus, une trame incorrecte à l’arrivée est simplement
ignorée. Le réseau Internet fonctionne suivant ce mode au niveau de la couche 3
(couche réseau). On peut y remédier par les couches des niveaux supérieurs ; ainsi, le
protocole TCP implémente un mécanisme de transmission avec accusé de réception.
2. Avec connexion permanente, connection oriented en anglais. Il s’agit d’un mode de
connexion, aussi appelé mode circuit, qui garantit une permanence dans le trajet utilisé pour la
transmission de l’information. Le circuit est affecté à la communication pour toute sa durée.
 Quant à la couche physique, elle concerne les interfaces entre l’équipement et le
réseau (La norme Ethernet interface avec un réseau local).

Dans le modèle OSI il n’y a pas de standard unique à chaque couche du modèle, la pratique a
conduit à des familles de standards par niveau.
Du niveau 7 de l’application, au niveau 4 du transport, l’information circule dans ce que l’on
appelle un “ message ”, au niveau 3 elle se nomme “ packet ”, puis “ frame ” au niveau 2 et
“signal ” au niveau 1.

4-3-1 / Protocole IP
La défense américaine a décidé de définir sa propre architecture. Cette architecture est
à la base du réseau mondial Internet.
L’architecture Internet, qui se présente sous la forme d’une pile de protocoles, est basée sur le
protocole IP (Internet Protocol) qui correspond au niveau 3 de l’architecture du modèle de
référence OSI, il est défini dans la RFC 791.

a) Comparaison TCP/IP — ISO

La suite de protocoles désignée par TCP/IP, est construite sur un modèle en couches moins
complet que la proposition de l’ISO. Quatre couches sont suffisantes pour définir
l’architecture de ce protocole. (voir figure 8)

4 Couche Application (Application layer).

3 Couche Transport (Transport layer).
2 Couche Internet (Internet layer).
1 Couche interface réseau (Network access layer).
0 Matériel (n’est pas une couche comprise dans le protocole).

15
 Fig 8. Comparaison TCP/IP et OSI

Une vue d’ensemble de l’architecture logicielle avec quelques protocoles d’applications de la

famille IP sont repris sur la figure suivante :

Fig 9. - Éléments de l’architecture TCP/IP.

Le protocole IP a pour but de transporter les paquets, appelés datagrammes, d’une

extrémité à l’autre du réseau. Ces derniers sont des octets issus de la couche de transport et
encapsulés à l’aide d’un en-tête IP avant d’être propagés vers la couche réseau (Ethernet par
exemple).

16
Quelques caractéristiques du protocole IP :

– IP est le support de travail des protocoles de la couche de transport, UDP, TCP et SCTP.
– IP ne donne aucune garantie quant au bon acheminement des données qu’il envoie. Il
n’entretient aucun dialogue avec une autre couche IP distante, on dit aussi qu’il délivre les
datagrammes “ au mieux ”.
– Chaque datagramme est géré indépendamment des autres datagrammes même au sein du
transfert des octets d’un même fichier. Cela signifie que les datagrammes peuvent être
mélangés, dupliqués, perdus ou altérés.
Ces problèmes ne sont pas détectés par IP et donc il ne peut en informer la couche de
transport.
– L’en-tête IP minimale fait 5 mots de 4 octets, soit 20 octets. S’il y a des options la taille
maximale peut atteindre 60 octets.

b) Structure de l’en-tête
L’en-tête d’un paquet IP est illustré à la figure 10.

Fig 10. -En-tête d’un paquet tel que défini par le protocole IP.

VERSION : 4 bits qui spécifient la version du Protocol IP. L’objet de ce champ est la
vérification que l’émetteur et le destinataire des datagrammes sont bien en phases avec la
même version ( IPv4 ou IPv6).

IHL : 4 bits qui donnent la longueur de l’en-tête en mots de 4 octets. La taille standard de
cette en-tête fait 5 mots, la taille maximale fait : (23 + 22 + 21 + 20) × 4 = 60 octets.

TOTAL LENGTH : Donne la taille du datagramme, en-tête plus données. La taille des
données est donc à calculer par soustraction de la taille de l’en-tête. 16 bits autorisent la
valeur 65535.

TYPE OF SERVICE : ce champ définit 4 bits utiles sur les huit (3 à 6). Ceux-ci indiquent au
routeur l’attitude à avoir vis à vis du datagramme (Minimiser le délai, Maximiser le débit,
Maximiser la qualité ou bien alors Service normal).

17
IDENTIFICATION, FLAGS et FRAGMENT OFFSET : Ces mots sont prévus pour
contrôler la fragmentation des datagrammes.

TTL “ Time To Live ” : 8 bits, 255 secondes maximum de temps de vie pour un datagramme
sur le net. Ce champ n’est qu’un compteur décrémenté d’une unité à chaque passage dans un
routeur.

PROTOCOL : 8 bits pour identifier le format et le contenu des données.

HEADER CHECKSUM : 16 bits pour s’assurer de l’intégrité de l’en-tête. Lors du calcul de

ce “ checksum ” ce champ est à 0. A la réception de chaque paquet, la couche calcule cette
valeur, si elle ne correspond pas à celle trouvée dans l’en-tête le datagramme est oublié (“
discard ”) sans message d’erreur.

SOURCE ADDRESS : Adresse IP de l’émetteur, à l’origine du datagramme.

DESTINATION ADDRESS : Adresse IP du destinataire du datagramme.

IP OPTIONS : 24 bits pour préciser des options de comportement des couches IP traversées
et destinatrices. Les options les plus courantes concernent :

– Des problèmes de sécurité

– Des enregistrements de routes
– Des enregistrements d’heure
– Des spécifications de route à suivre

PADDING : Remplissage pour aligner sur 32 bits.

4-3-2 / Protocole UDP

a) Utilisation
UDP est l’acronyme de “User Datagram Protocol”, il est défini dans la RFC 768. La
couche UDP ajoute un mécanisme qui permet l’identification du service (niveau
Application).
En effet, il est indispensable de faire un tri entre les diverses applications (services) :
plusieurs programmes de plusieurs utilisateurs peuvent utiliser simultanément la même
couche de transport et il ne doit pas y avoir de confusion entre eux.

L’idée est d’associer la destination à la fonction qu’elle remplie. Cette identification se fait à
l’aide d’un entier positif que l’on nomme port.
Pour communiquer avec un service distant il faut donc avoir connaissance de son numéro de
port, en plus de l’adresse IP de la machine elle-même.
La couche IP sépare les datagrammes SCTP, TCP et UDP grâce au champ protocol de son
en-tête, par la suite l’association du protocole de transport (TCP, UDP, …) et du numéro de
port identifie un service bien précis, ceci est montré sur la figure 11 suivante :

18
 Fig 11. Numéro de port comme numéro de service

b) Description de l’en-tête
Un paquet UDP est conçu pour être encapsulé dans un datagramme IP et permettre un
échange de données entre deux applications, sans échange préliminaire.

PROTOCOL = UDP

Fig12 . UDP encapsulé dans IP

– UDP apporte un mécanisme de gestion des ports, au dessus de la couche Internet.

– UDP est simplement une interface au dessus d’IP, ainsi l’émission des messages se
fait-elle sans garantie de bon acheminement. Plus généralement, tous les défauts d’IP
énoncés auparavant sont applicables à UDP.
Plus particulièrement, les paquets à destination d’une application UDP sont conservés
dans une pile de type FIFO. Si l’application destinatrice ne les “consomme” pas assez
rapidement, les plus anciens paquets risquent d’être écrasés par les plus récents. Un
risque supplémentaire (par rapport aux propriétés d’IP déjà connues) de perte de
données.
– UDP est aussi désigné comme un mode de transport “non connecté”, mode
datagramme, par opposition à TCP.

Parmi les utilisations les plus courantes d’UDP on peut citer le serveur de noms, base de
données répartie au niveau mondial, qui s’accommode très bien de ce mode de transport.

19
 c) structure de l’en-tête

Fig 13. Structure de l’en-tête UDP

UDP SOURCE PORT : Le numéro de port de l’émetteur du paquet. Ce champ est optionnel,
quand il est spécifié il indique le numéro de port que le destinataire doit employer pour sa
réponse. La valeur zéro (0) indique qu’il est inutilisé, le port 0 n’est donc pas celui d’un
service valide.

UDP DESTINATION PORT : Le numéro de port du destinataire du paquet.

MESSAGE LENGTH : C’est la longueur du paquet, donc comprenant l’en-tête et le message.

– La longueur minimale est 8
– La longueur maximale est 65 535 − H(IP). Le plus souvent (IP sans option) cette
taille maximale est donc de 65 515.
CHECKSUM : Le checksum est optionnel et toutes les implémentations ne l’utilisent pas.

4-3-3 / Protocole TCP

TCP est l’acronyme de “ Transmission Control Protocol ”, il est défini dans la RFC
793. Les données encapsulées dans un en-tête TCP sont des “ paquets TCP ”.

PROTOCOL = TCP

Fig 14 . TCP encapsulé dans IP

a) caractéristiques de TCP
Le protocole TCP regroupe les fonctionnalités de niveau 4 du modèle de référence. C’est
un protocole assez complexe qui possède de nombreuses options permettant de résoudre tous
les problèmes de perte de niveau inférieur.
Cinq points principaux caractérisent ce protocole :
1. TCP contient un mécanisme pour assurer le bon acheminement des données. Cette
possibilité est absolument indispensable dès lors que les applications doivent transmettre de
gros volumes de données et de façon fiable.
2. Le protocole TCP permet l’établissement d’un circuit virtuel entre les deux points
qui échangent de l’information. On dit aussi que TCP fonctionne en mode connecté (par
opposition à UDP qui est en mode non connecté ou encore mode datagramme).

20
Pour établir une connexion, un circuit virtuel, il faut avoir réunis les éléments suivants :
Le protocole : C’est TCP mais il y pourrait y avoir d’autres protocoles qui assurent le même
service. . .
IP locale : Adresse de la machine qui émet.
Port local Le numéro de port associé au processus.
IP distante : Adresse de la machine distante.
Port distant : Le numéro de port associé au service à atteindre. Il est obligatoire de le
connaître précisément.
L’ensemble de ces cinq éléments définit un circuit virtuel unique. Si l’un d’eux change il
s’agit d’une autre connexion.
3. TCP a la capacité de mémoriser des données :
– Aux deux extrémités du circuit virtuel, les applications s’envoient des volumes de données
absolument quelconques, allant de 0 octet à des centaines (ou plus) de Mo.
– A la réception, le protocole délivre les octets exactement comme ils ont été envoyés.
– Le protocole est libre de fragmenter le flux de données en paquets de tailles adaptées aux
réseaux traversés. Il lui incombe cependant d’effectuer le réassemblage et donc de stocker
temporairement les fragments avant de les présenter dans le bon ordre à l’application.
4. TCP est indépendant vis à vis des données transportées, c’est un flux d’octets non
structuré sur lequel il n’agit pas.
5. TCP simule une connexion en “ full duplex ”. Pour chacune des deux applications
en connexion par un circuit virtuel, l’opération qui consiste à lire des données peut s’effectuer
indépendamment de celle qui consiste à en écrire.
Le protocole autorise la clôture du flot dans une direction tandis que l’autre continue à être
active. Le circuit virtuel est rompu quand les deux parties ont clos le flux.

b) Description de l’en-tête
La figure suivante montre la structure d’un en-tête TCP. Sa taille normale est de 20 octets, à
moins que des options soient présentes.

Fig 15. Structure de l’en-tête TCP

TCP SOURCE PORT : Le numéro de port de l’application locale.

TCP DESTINATION PORT : Le numéro de port de l’application distante.

SEQUENCE NUMBER : C’est un nombre qui identifie la position des données à transmettre
par rapport au segment original. Au démarrage de chaque connexion, ce champ contient une
valeur non nulle et non facilement prévisible, c’est la séquence initiale ou ISN (Initial
Sequence Number).

21
TCP numérote chaque octet transmis en incrémentant ce nombre 32 bits non signé. Il repasse
à 0 après avoir atteint 232 − 1 (4 294 967 295). Pour le premier octet des données transmis ce
nombre est incrémenté de un, et ainsi de suite. . .

ACKNOWLEDGEMENT NUMBER : C’est un numéro qui identifie la position du dernier

octet reçu dans le flux entrant. Il doit s’accompagner du drapeau ACK.

OFF pour OFFSET : il s’agit d’un déplacement qui permet d’atteindre les données quand il
y a des options.

RESERVED : Six bits réservés pour un usage futur.

CODE : Six bits pour influer sur le comportement de TCP en caractérisant l’usage du
segment : tel que « Urgent : Flag URG», « réinitialisation de la connexion : Flag RST »,
« acquittement : Flag ACK » ou alors « l’émetteur du segment a fini d’émettre : Flag FIN», et
ceci en activant à chaque fois le flag concerné.

WINDOW : Le flux TCP est contrôlé de part et d’autre pour les octets compris dans une zone
bien délimitée et nommée “ fenêtre ”. La taille de celle-ci est définie par un entier non signé
de 16 bits, qui en limite donc théoriquement la taille à 65 535 octets.
Chaque partie annonce ainsi la taille de son buffer de réception, de telle sorte que l’´emetteur
n’envoie pas plus de données que le récepteur ne peut en accepter.

CHECKSUM : Un calcul qui porte sur la totalité du segment, en-tête et données.

URGENT POINTER : Ce champ n’est valide que si le drapeau URG est mis à 1. Ce pointeur
contient alors un offset à ajouter à la valeur de SEQUENCE NUMBER du segment en cours
pour délimiter la zone des données urgentes à transmettre à l’application.

OPTIONS C’est un paramétrage de TCP. Sa présence est détectée dés lors que l’OFFSET est
supérieur à 5.
Les options utilisées :
 mss (Maximum Segment Size) La taille maximale du segment 5 des données
applicatives que l’émetteur accepte de recevoir.
 timestamp pour calculer la durée d’un aller et retour (RTT ou “ round trip time
”).
 wscale Facteur d’échelle (“ shift ”) pour augmenter la taille de la fenêtre au
delà des 16 bits du champ WINDOW (> 65535). Quand cette valeur n’est pas
nulle, la taille de la fenêtre est de 65535×2shift. Par exemple si “ shift ” vaut 1 la
taille de la fenêtre est de 131072 octets soit encore 128 ko.
 nop Les options utilisent un nombre quelconque d’octets par contre les paquets
TCP sont toujours alignés sur une taille de mot de quatre octets ; à cet effet une
option “ No Operation ” ou nop, codée sur 1 seul octet, est prévue pour
compléter les mots.

PADDING : Remplissage pour se caler sur un mot de 32 bits.

DATA : Les données transportées. Cette partie est de longueur nulle à l’établissement de la
connexion, elle peut également être nulle par choix de l’application.

22
 c) Contrôle du transport
Le bon acheminement des données applicatives est assuré par un mécanisme
d’acquittement des paquets.

Mécanisme de l’acquittement

Fig 16. Mécanisme de l’acquittement

– Au départ du Paquet i une horloge se déclenche. Si cette horloge dépasse une

valeur limite (généralement de 30 secondes à 2 minutes) avant réception de l’ACK
le Paquet i est retransmis.
– Le temps qui s’´ecoule entre l’émission d’un paquet et la réception de son
acquittement est le RTT (Round Trip Time).
– L’émetteur conserve la trace du Paquet i pour éventuellement le renvoyer.
Si on considère des délais de transmission de l’ordre de 500 ms (voire plus), un tel mécanisme
est totalement inadapté au transfert de flux de données. On peut aussi remarquer qu’il sous-
emploie la bande passante du réseau.

Fenêtres glissantes
Cette attente de l’acquittement est pénalisante, sauf si on utilise un mécanisme de
“ fenêtres glissantes ”, comme le suggère la figure suivante :

23
 Fig17 . Principe de la fenêtre glissante

– Avec ce principe, la bande passante du réseau est beaucoup mieux employée.

– A chaque paquet est associé une horloge comme sur la figure 16.
– Le nombre de paquets à envoyer avant d’attendre le premier acquittement est fonction
de deux paramètres :
1. La largeur de la fenêtre précisée dans le champ WINDOW de l’en-tête.
2. La taille maximale des données, ou MSS qui vaut 512 octets par défaut.
C’est la plus grande taille du segment de données que TCP enverra au
cours de la session.

d) Conclusion sur TCP

Le protocole TCP a été conçu à une époque ou les applications graphiques utilisant le
réseau étaient très rares.
Des années plus tard, nous utilisons des applications qui sont plus orientées flux de
données (vidéo, audio, téléphonie. . .) avec des échanges plus volumineux et des besoins en
transport qui ont évolué.
Le principe de la fenêtre glissante, si performant qu’il soit pour assurer le bon
acheminement des données, est bloquant pour certaines applications comme le web. En effet,
si le paquet de données de tête n’est pas acquitté, les suivants, même reçus, sont en attente
avant d’être délivrés à l’application.
L’indépendance de TCP vis à vis de la structure des données est également un
inconvénient dans certaines applications comme la téléphonie pour laquelle la notion de
messages successifs est bien plus intéressante.
TCP ne conviendra pas pour des communications en temps réel.
Pour la téléphonie sur IP (VoIP – Voice over IP), il faut distinguer deux types
d’information : les informations de service et les messages vocaux. Les informations de
service sont envoyées par TCP, puisqu’il est important qu’elles arrivent bien à destination.
Pour les messages vocaux, une retransmission est exclue en raison du temps prohibitif d’une
retransmission. On utilise plutôt le protocole RTP.

24
4-3-4 / Protocole RTP / RTCP

a) Caractéristiques du protocole RTP/RTCP

RTP/RTCP sont les acronymes de “ Real Time Transport Protocol ” et “ Real Time
Transport Control Protocol ”, définis dans la RFC 1889. Ils permettent respectivement
de transporter et de contrôler des flots de données qui ont des propriétés temps réel.

RTP fournit des fonctions de transport de bout en bout pour les applications temps réel sur des
services réseaux multicast (multipoint) ou unicast (point à point):
- conférence audio, vidéo interactive
- diffusion vidéo, audio
RTP permet :

 d'identifier le type de l'information transportée,

 d'ajouter des marqueurs temporels permettant d’indiquer l’instant d’émission du
paquet. L’application destinataire peut alors synchroniser les flux et mesurer les délais.
o d’inclure des numéros de séquence à l'information transportée afin de détecter
l’occurrence de paquets perdus et de délivrer les paquets en séquence à
l’application destinataire.
 De plus, RTP peut être véhiculé par des paquets multicast afin d'acheminer des
conversations vers des destinataires multiples.

RTP s'appuie dans l'architecture TCP/IP sur UDP un Protocol simple (sans réservation de
ressources), ne garantie pas la livraison du paquet à l’arrivée et sans correction d’erreur (il ne
prévoit pas la retransmission automatique des paquets manquants).
Il fait partie intégrante de l'application (implémenté dans la couche application) contrairement
à d'autres protocoles de transport comme TCP.

Le RTCP accompagne le RTP.

o Il assure un trafic de contrôle, c'est un "feedback" pour l'émetteur sur la qualité de
transmission et d'autres informations.
o Basé sur la transmission périodique de paquets de contrôle à tous les participants
dans une session.
o Utilise le même mécanisme de distribution que les paquets de données mais ne
transporte aucune donnée.

Ces quatre fonctions sont:

 Fournir des informations sur la qualité de la session:
– information en retour pour une source (feedback)
– permet à une source de changer de politique
– met en évidence des défauts de distribution individuels, collectifs
 Garder une trace de tous les participants à une session

 Contrôler le débit auquel les participants à une session RTP transmettent leurs
paquets RTCP : Plus il y a de participants, moins la fréquence d'envoi de paquets
RTCP par un participant est grande, donc la vision de l’état du réseau par un
participant est moins précise. Il faut garder le trafic RTCP en dessous de 5% du
trafic de la session.

25
  Transmettre des informations de contrôle sur la session (optionnel)
exemple : identifier un participant sur les écrans des participants.

b) Position de RTP/RTCP dans le modèle OSI :

Fig 18. RTP/RTCP dans de modèle OSI

Ces deux protocoles utilisent des ports de communications différents permettant de référencer
les applications qui s’exécutent sur les deux machines (locale et distante). Un port pair sera
utilisé par RTP et un port impair (le suivant) par RTCP,  les numéros de ports 5004 et 5005
ont étés enregistrés pour l'utilisation par défaut du couple de protocoles RTP/RTCP.

Comme le montre la figure ci-dessous,

Fig 19. Les tubes de communication RTP,RTCP

Lorsqu’une session RTP est ouverte, alors une session RTCP est aussi ouverte de manière
implicite.
RTP est en fait le canal contenant les informations utiles propres à l'image ou la bande son en
cours.

RTCP beaucoup moins gourmand en bande passante est en fait un canal de supervision du
canal porteur RTP.

26
 c) En-tête RTP
L’entête d’un paquet RTP est obligatoirement constitué de 16 octets.

V : Ce champ, codé sur 2 bits, permet d’indiquer la version de Rtp. Actuellement, V=2.
P : Padding Ce bit indique, s’il est à 1, que les données possèdent une partie de bourrage.
X : (Extension) Ce bit spécifie, s’ il est à 1, que l’en-tête est suivi d’un en-tête supplémentaire.
CC : (CSRC Count) Ce champ, codé sur 4 bits, représente le nombre de CSRC qui suit
l’entête (nombre de sources contributives contenues dans la liste CSRC).
M : Marqueur il s’agit d’un bit de signalisation, permettant aux applications de définir des
comportements qui leurs sont propre (exemple : fin de séquence d’images).
PT (Payload Type) Basé sur 7 bits, ce champ identifie le type du payload (audio, vidéo,
image, texte, html, etc.), qui représente le type de codage de l’information véhiculé dans le
paquet. Cette liste est détaillée dans le RFC 3551.
Numéro de séquence : Ce champ, d’une taille de 2 octets, représente le numéro d’ordre
d’émission des paquets. Sa valeur initiale est aléatoire et il s’incrémente de 1 à chaque paquet
envoyé, il peut servir à détecter des paquets perdus.
Timestamp : Ce champ de 4 octets, représente l’horloge système ou l’horloge
d’échantillonnage de l’émetteur, qui permet de dater les paquets émis. Elle doit être monotone
et linéaire pour assurer la synchronisation des flux. Ces informations sont la base de calculs
permettant d’évaluer le délai introduit par un système de communication.
SSRC (Synchronisation Source): Basé sur 4 octets, ce champ identifie de manière unique la
source ayant produit le paquet, sa valeur est choisie de manière aléatoire par l’application. On
parle ici de synchronisation car l’échelle de temps installée par la source dans ses paquets va
servir de repère aux récepteurs pour restituer l’information correctement.

27
CSRC (Contributing Source) : Ce champ, sur 4 octets, identifie les sources de contribution.
La liste des participants ayant leur contribution (audio, vidéo) mixées dans un même paquet.

d) En-tête RTCP
Le protocole RTCP est basé sur des transmissions périodiques de paquets de contrôle par tous
les participants dans la session. C'est un protocole de contrôle des flux RTP, permettant de
véhiculer des informations basiques sur les participants d'une session, et sur la qualité de
service. Il existe cinq types différents de paquets RTCP pour chaque type d'information :

 200 - SR (Sender Report) : Ce rapport regroupe des statistiques concernant la

transmission (pourcentage de perte, nombre cumulé de paquets perdus, variation de
délai, …Ces rapports sont issus d’émetteurs actifs d’une session.
 201 - RR (Receiver Report) : Ensemble de statistiques portant sur la communication
entre les participants. Ces rapports sont issus des récepteurs d’une session.
 202 - SDES (Source Description) : Carte de visite de la source (nom, e-mail,
localisation).
 203 - BYE : Message de fin de participation à une session.
 204 - APP : Paquet de signalisation spécifique à une application.

Voici l’entête commun à tous les paquets RTCP.

V : Ce champ, codé sur 2 bits, permet d’indiquer la version de RTP, qui est la même que dans
les paquets RTCP.
P (Padding): Ce bit indique, s’il est à 1, que les données possèdent une partie de bourrage.
RC (Reception Report Count) : Ce champ, basé sur 5 bits, indique le nombre de rapport de
réception contenus en ce paquet SR, on considérant un rapport pour chaque source. Une
valeur de zéro est valide.
PT (Paquet Type): Ce champ, codé sur 1 octet, indique le type de paquet ; il s’agit d’un
paquet SR identifié par la valeur 200 dans ce datagramme RTCP.

28
Longueur : Ce champ de 2 octets, représente la longueur de ce paquet RTCP incluant l’entête
et le bourrage.
SSRC of sender : Basé sur 4 octets, ce champ, représente l’identification de la source pour le
créateur de ce paquet SR.
e) Mixer et Translator
Le mixer (mixeur) est une application qui reçoit des flux de données de plusieurs sources
qu’on appelle SSRCs (Synchronization Sources), en modifie éventuellement le format et
renvoie un seul flux de données agrégé.
En faisant ce travail, le mixer se comporte comme une source particulière (SSRC) qui
regroupe les données de plusieurs autres sources qui étaient des SSRCs et qui deviennent des
CSRC (Contributing Source).
Les paquets émis par une quelconque source (terminal, mixer) contiennent une information
d’identification de la SSRC qui les émet. Ces paquets peuvent contenir également
l’identification des CSRC qui sont les sources réelles des informations lorsqu’il s’agit d’un
paquet construit par transformation.

Sur la figure 20, un mixer reçoit des paquets de trois sources (SSRC). Il peut réaliser des
conversions de format, mixe le contenu en fonction de l’application et produit un nouveau
paquet RTP qu’il relaye à la destination. Le mixer fournit la synchronisation pour le nouveau
flux et s’identifie comme la nouvelle source SSRC. Les trois sources origines sont déclarées
comme CSRC dans le paquet RTP composé.

Fig 20. Mixer RTP

Le translator (traducteur) est une application qui transmet les paquets RTP qu’elle
reçoit sans changer l’identificateur de SSRC (à l’inverse de ce que fait le mixeur). Un
traducteur permet par exemple de changer le codage d’une donnée ou le débit, ou encore de
traiter les problèmes de sécurité (firewalls) à la frontière d’un réseau privé.

29
Par exemple, si un terminal utilisant un codage PCM μ-law à 64 kbit/s souhaite établir une
session avec un terminal supportant un codage G.726 ADPCM à 32 kbit/s, alors il est
nécessaire d’interfacer les deux terminaux à travers un translator.
Les fonctions Mixer et Translator sont généralement mises en œuvre dans un Gateway.

f) Conclusion  :
Les protocoles RTP et RTCP sont adaptés pour la transmission de données temps réel
Ils sont principalement utilisés en visioconférence, où les participants sont tour à tour,
émetteurs ou récepteurs. Pour le transport de la voix, ils permettent une transmission correcte
sur des réseaux bien ciblés et bien dimensionnés tel que les réseaux de type LAN d'entreprise.

Cependant, ils fonctionnent en stratégie bout à bout et donc ne peuvent contrôler

l'élément principal de la communication : le réseau. Pourtant, quelques soient les efforts
d'adaptation des émetteurs, ou les moyens mis en œuvre par les récepteurs, c'est au cœur du
réseau que les dysfonctionnements critiques sont générés tels que le délai de transmission et la
gigue. La gigue dite aussi ‘variation de délai’ due principalement aux files d’attentes des
routeurs, détruit la synchronisation entre la source et le destinataire. Phénomène auquel la
transmission multimédia et en particulier la transmission audio est très sensible.

Le protocole RSVP (Resource reSerVation Protocol) défini par l’IETF a été

développé afin de remédier à ces dysfonctionnements et ainsi améliorer les transmissions
temps réel.

4-3-5/ Protocole RSVP

a) Introduction
 Le protocole RSVP (Ressource reSerVation Protocol) est utilisé par les réseaux
intégrant IntServ, c’est un protocole de contrôle de réseau qui permet au destinataire des
données de demander une certaine qualité de service (par exemple le délai ou la bande
passante) à travers le réseau (garantie de QoS).
Ce protocole de signalisation permet d'allouer dynamiquement de la bande passante : il est
utilisé par les applications "temps réel" afin de réserver les ressources nécessaires au niveau
des routeurs pour que la bande passante nécessaire soit disponible lors de la transmission.

b) Principe
 Les routeurs communiquent via RSVP pour initialiser et gérer la bande passante
réservée aux sessions. Ce protocole est responsable de la négociation des paramètres de
connexion avec ces routeurs. Si la réservation est établie, RSVP se charge aussi du maintien
de l'état des routeurs et de l'hôte afin de fournir le service demandé.

RSVP fait des réservations de ressources pour les applications unicast et multicast et s’adapte
dynamiquement aux évolutions (changements de routes, ajout d’un équipement ou d’un
participant, etc.). Le protocole demande des ressources dans une seule direction
(unidirectionnel) et traite l’émetteur et le récepteur de manière différente. 

RSVP  rend obligatoire la demande de QoS par le récepteur  plutôt que par l’émetteur.
L'émetteur envoie ses exigences au destinataire. Après réception, le destinataire  utilise le

30
même chemin pour renvoyer un message spécifiant la QoS souhaitée et fixer la réservation
des ressources correspondantes dans chaque routeur. L'émetteur envoie alors les données.

RSVP agit avant l’envoi des données, occupe la place d’un protocole de transport dans la pile
des protocoles mais ne transporte pas de données utilisateurs. Dans le cas où le système ne
permet pas l’utilisation de services réseau directement, RSVP est encapsulé dans des paquets
UDP.

c) Principaux paquets de contrôle RSVP

Il existe sept types de message RSVP:
– 1=Path : envoyé par la source pour indiquer la liste des routeurs du chemin
suivi par les données.
– 2=Resv : message de réservation vers les émetteurs.
– 3=PathErr : message d'erreur concernant le chemin.
– 4=ResvErr : message d'erreur de demande de réservation.
– 5=PathTear : indique aux routeurs d'annuler les états concernant la route.
– 6=ResvTear : indique aux routeurs d'annuler les états de réservation (fin de
session).
– 7=ResvConf (optionnel) : message de confirmation envoyé par le routeur au
demandeur de la réservation.

d) En-tête RSVP
Vers Flags Type du Msg Checksum
Send_TTL Réservé Longueur Msg.
Message RSVP

 Vers (4 bits): version du protocole RSVP ;

 Flags (4 bits): non utilisé à ce jour;
 Type de Msg (8 bits): 1 à 7 selon le type ci-dessus;
 Checksum (16 bits): Contrôle d'erreurs;
 Send_TTL (8 bits): valeur du Time To Live de l’en-tête IP qui accompagne le
message;
 Longueur (16 bits): longueur totale du message en octets (en-tête inclus).

e) Modes de fonctionnement
Pour initier un flux de bout en bout, l’émetteur envoie tout d’abord un message RSVP
path afin de tracer le chemin jusqu’à la destination souhaitée. Un autre message est envoyé
des récepteurs vers l’émetteur, message RESV qui consiste à réaliser l’allocation des
ressources nécessaires au flux qu’il est sur le point de générer (figure 21). Cette allocation
spécifie les valeurs de QoS souhaitées, qui doivent être incluses dans tous les routeurs situés
sur ce chemin.

31
 Fig 21. Messages PATH et RESV pour la réservation de ressources

Le flux RSVP est simplex : dans le cas d’une application nécessitant des garanties de
QoS dans les deux sens, les deux extrémités de la communication envoient des requêtes
RSVP, dans ce cas là il n’y a aucune garantie que les deux flux passent par les mêmes
routeurs, ni que l’approbation d’un flux implique l’approbation de l’autre.

RSVP possède deux modes de fonctionnements pour la détermination du chemin. Le Hop by

Hop (ou saut par saut) et le Explicit Path (chemin explicite).

Saut par saut (Hop by Hop) : Le modèle Hop by Hop est celui qui définit le meilleur
chemin par défaut entre deux routeurs. Les chemins sont déterminés automatiquement grâce à
leurs coûts en bande-passante.

Chemin explicite (Explicit Path) : Le modèle Explicit Path permet de choisir manuellement
le chemin qu’un message va prendre pour aller de sa source à sa destination. Il existe deux
types de chemins :

Strict Path : Permet de choisir le prochain routeur par lequel un message doit passer.
Ce routeur doit être directement connecté (adjacent).
Si le message ne peut pas accéder au routeur suivant, il ne prendra pas de chemin alternatif :
un message de type PathErr est envoyé au routeur source.

Loose Path  : Permet de choisir un ou plusieurs routeurs par le(s)quel(s) le message

doit passer. Cette technique permet de partager la charge entre routeurs et de faire passer le
message par un certain routeur, sans lui définir un chemin totalement strict. Avec un chemin
Loose Path, si un routeur n’est pas accessible, un chemin alternatif va être trouvé.

f) Limitations

RSVP oblige à maintenir l'état d'un flot. Lorsque le nombre d'usagers augmente (scalability),
le nombre d'états devient conséquent avec le trafic généré pour les rafraîchissements. Cela
nuit aux performances du système dans son ensemble. C'est pourquoi RSVP est plus adapté à
des réseaux de petite taille comme les LAN.

RSVP ne s'applique pas au dernier Km puisqu'il n'est pas possible de contrôler la gestion des
files d'attente sur les équipements de la couche liaison avec les réseaux locaux.

32
Les opérateurs préfèrent augmenter les ressources que de réserver les ressources vu la
complexité du système sans oublier que la démarche de réservation des ressources est
inégalitaire puisqu'elle favorise les consommateurs payants.

Enfin, d'autres architectures reposant sur l'étiquetage de priorité dans les paquets et la
classification des services sont plus simples à mettre en œuvre. Paradoxalement, ces
architectures qui peuvent paraître comme concurrents de RSVP peuvent être ses alliés en
allégeant au maximum la tâche de maintien d'états, de rafraîchissement et de classification.

4.3.6 / Les services différenciés (DiffServ)

a) introduction
Les services différenciés (DiffServ) ne traitent pas des flux individuels de paquets
mais plutôt agissent sur des classes de flux ; d’autre part, à la différence du protocole RSVP,
dans lequel l’allocation de ressources se fait de bout en bout, DiffServ permet que chaque
nœud le long du chemin définisse le type de service réservé à une classe de flux donnée.
DiffServ est un autre mécanisme de contrôle de la qualité de service qui mise sur la
simplicité. Il consiste à pré-classer les paquets selon leur niveau de priorité dans le réseau. Un
flux de paquet IP perd son identité propre et circule sur Internet en tant que membre d’une
classe de flux, marqué d’un indice entre 0 et 7 correspondant à la classe de service (CoS) (8
classes) qui sera exploitée par les nœuds pour fournir un traitement différencié à chaque
paquet, en fonction de son degré de priorité.
Le mécanisme d’affectation de priorité selon la classe de service est appelé IP
Precedence (Préséance IP), marqué par le champ TOS (Type of service sur 8 bits) dans l’en-
tête IP réservé à DiffServ, qui n’a été exploité qu’après l’arrivée des applications multimédia
avec leurs contraintes de temps, obligeant à traiter les flots de manière différenciée.

… Rappel En-Tête IP

b) La philosophie DiffServ

Un réseau DiffServ est vu comme une interconnexion de routeurs obéissant chacun à

une politique déterminée dans l’ordonnancement des paquets, mais agissant indépendamment
les uns des autres.
C’est à chaque nœud d’apporter un traitement différencié, Per Hop Behaviour en fonction de
la classe de service du paquet concerné. Il n’est plus nécessaire de maintenir des états dans les
routeurs pour chacun des flots (cas de RSVP). Chaque nœud du réseau se contente de filtrer

33
les paquets en ne s’intéressant qu’à un seul champ d’en-tête, celui qui porte l’indice de sa
classe de service.

Le marquage des paquets s’effectue dans les nœuds périphériques qui constituent les points
d’entrée sur le réseau. Les routeurs intermédiaires n’ont plus à modifier ce champ qui ne sert
qu’à la lecture.

L’architecture adoptée par DiffServ est fondée sur deux principales catégories de routeurs :
les routeurs de bordure (edge routers) et les routeurs de cœur, internes (core routers), comme
l’illustre la figure 22.

Fig 22. Aspect général d’un réseau DiffServ

Il est implémenté dans :

- Les routeurs Edge un trieur de paquet (Packet Classifier) responsable de la
classification des paquets, qui lit l’octet TOS du paquet ou un autre indice
de priorité ;
- Les routeurs internes un répartiteur de paquet (Packet scheduler) qui met
en œuvre le traitement différencié par nœud (Per Hop Behaviour), en
affectant au paquet une discipline de service adaptée dans une file d’attente
spécialisée.
Ainsi, chaque file d’attente caractérise une classe de service et ne recevra que les paquets qui
sont conformes à ce service. Au niveau des files d’attente, des mécanismes
d’ordonnancement, permettent de traiter les paquets en fonction de leur besoin en débit, délai,
etc…

c) Classes de services de DiffServ

Dans cette approche, on dispose de trois niveaux de priorité :
Le service « Best-Effort »
Le service Best-Effort (BE), correspond à la priorité la plus faible. C’est le service
actuellement utilisé dans l’Internet et qui ne distingue pas les flots prioritaires des flots moins
prioritaires.
Le service « Assured Forwarding »
Le comportement Assured Forwarding (AF) est plutôt dédié à des services généraux. Il
englobe quatre classes de traitement et un second niveau de différenciation pour attribuer les
priorités : la précédence. Cette dernière met en évidence l’importance d’un paquet et par
conséquent la dégradation que peut engendrer sa perte sur la qualité de l’information. Le

34
service AF se trouve donc constitué de quatre classes de service définissant chacun trois
niveaux de priorité.
Le service « Expedited Forwarding »
Le service Expedited Forwarding (EF) conçu pour servir des applications demandant de
faibles pertes, un délai et une gigue très faibles et une garantie de bande-passante. Le principe
de base est de pouvoir garantir une taille des files d’attente dans les routeurs la plus restreinte
possible avec un débit d’émission du trafic qui soit toujours supérieur ou égal à un certain
seuil. Il a été proposé l’utilisation d’une file prioritaire pour les flux typés EF. Le délai
observé pour les flux à l’intérieur des files est fortement réduit, mais un problème de famine
des autres classes pourrait se manifester si une mauvaise gestion est opérée dans le système.

d) Conclusion
La gestion de la qualité de service par IntServ et DiffServ présente tout de même
quelques limites.
Tout d’abord, IntServ emploi un mécanisme de réservation de ressources, qui doit être
implémentée au niveau de chaque routeur, ce qui conduit à une lourdeur de traitement. La
gestion de QoS est par conséquent appliquée par flot. De ces limites découlent des critiques
en raison de son incapacité à gérer la QoS pour des réseaux largement déployés : le problème
de passage à l’échelle est un aspect important puisque l’envergure des réseaux ne cesse
d’accroître, et le trafic qui les traverse est en perpétuelle augmentation.
L’approche DiffServ consiste, quant à elle, à remédier aux problèmes de passage à
l’échelle et de complexité de gestion. Néanmoins, cette politique présente l’inconvénient de
garantir une différenciation absolue, c’est-à-dire que plus une classe est grande, plus elle sera
privilégiée pour le partage des ressources par rapport aux autres classes concurrentes. De plus
aucun mécanisme n’est prévu pour le contrôle d’admission, la file d’attente d’une CoS peut
être surchargée par un afflux de paquets au point de devenir inapte à rendre le service
demandé.
Les paquets de haute priorité peuvent être rétrogradés dans la classe inférieure, en cas de
surcharge de la leur. Ces mécanismes engendrent une discrimination de répartition et par
conséquent peuvent provoquer le phénomène de famine entre les classes.
D’autre part, dans le contexte de l’Internet, l’usage d’un débit de paquets constant n’a
aucune signification, d’où un des intérêts majeur de l'Internet Multimédia qui est de pouvoir
effectuer un Streaming du flux de données.

4.3.7 / Le protocole RTSP

a) introduction
La transmission de flux multimédia nécessite la présence de protocole permettant
d’initier et de contrôler les sessions. A cet effet des protocoles ont été développés au niveau
de la couche application, et ont permis de renforcer les protocoles déjà présents dans la
couche transport, en offrant la capacité de gérer en continu des flux multimédias. SIP et RTSP
sont les deux protocoles principaux permettant la gestion de sessions multimédias au niveau
de la couche Application du modèle OSI.
RTSP (Real Time Streaming Protocol) permet de contrôler la distribution de flux
multimédias (streaming) sur un réseau IP, défini dans la norme (RFC 2326). C'est un
protocole de niveau applicatif prévu pour fonctionner sur des protocoles tels que RTP/RTCP
et RSVP.
Le Streaming consiste à découper les données en paquets dont la taille est adaptée à la
bande passante disponible entre le client et le serveur. Quand le client a reçu suffisamment de

35
paquets (bufferring), l'application cliente commence à jouer un paquet, décompresse un autre
et reçoit un troisième. Ainsi l'utilisateur peut avoir le flux multimédia sans avoir à télécharger
tout le fichier. Toutefois, il y a un retard du à la bufferisation.
Les flux peuvent provenir soit de fichiers stockés soit d'une source temps réel (caméra,
micro).
b) Les fonctions de RTSP
Le but du protocole RTSP est de permettre à l’utilisateur de commander le flux
multimédia en cours (avance rapide, pause etc.). Cette sorte de télécommande lui servira à
commander un ou plusieurs serveurs en parallèle et pourra être partagée simultanément entre
plusieurs utilisateurs.
RTSP a pour fonction d’établir et de contrôler un ou plusieurs flux synchronisés de
contenu continu de multimédia (streaming), tels l’audio et le vidéo par exemple. RTSP sert de
déclencheur à distance pour les serveurs multimédia : seule fonction celle de commande de
flux,  la distribution de ce flux sera en général prise en charge par RTP.
c) RTSP et les protocoles de transport 
RTSP n’est pas un protocole connecté. C’est le serveur qui garde tout au long d’une
session un numéro lui permettant d’identifier les flux en cours et les clients concernés par ce
flux. Les messages de contrôle RTSP seront acheminés via une connexion qui pourra utiliser
soit UDP soit TCP. Les flux multimédia seront acheminés par une connexion hors bande
(permanente) utilisant un protocole quelconque de la couche de transport. C’est souvent le
protocole RTP qui est utilisé pour la transmission des flux. 
d) RTSP et HTTP 
Le protocole RTSP utilise comme format les caractères de texte. Les concepteurs de
RTSP ont aussi choisi de baser leur protocole sur un protocole applicatif réussi, HTTP, ce qui
permettrait de réutiliser les protocoles de commerce électronique et d’authentification déjà
implémentés sur HTTP.
HTTP ne peut pas gérer les connexions hors bande, et il convenait plus d’avoir une
certaine séparation entre le serveur Web et le serveur multimédia. Les principaux points de
différence entre RTSP et HTTP sont les suivants : 
 un serveur RTSP garde un état de la connexion avec le client au cours d’une session à
la différence de HTTP,
 un serveur RTSP peut initier des requêtes ayant le client comme destinataire, 
e) Fonctionnalités de RTSP 
Le protocole RTSP permet de réaliser les scénarios suivants : 
 Récupération d’un contenu multimédia à partir d’un serveur. La description du contenu
multimédia est récupérée via HTTP par exemple. La récupération du flux multimédia
peut se faire en unicast aussi bien qu’en multicast, 
 Invitation d’un serveur multimédia à une conférence, afin d’incorporer à la conférence
un flux multimédia existant sur ce serveur, ou d’effectuer un enregistrement d’une
partie ou de la totalité de la conférence sur le serveur invité. Cette fonctionnalité est
utile dans le cas d’une application distribuée tel que le e-learning, 
 Ajout d’un contenu multimédia à une présentation en cours. Dans ce cas, lors d’une
diffusion en direct par exemple, le serveur prévient le client qu’un flux supplémentaire
est disponible pour la transmission. 
La figure ci-dessous représente les différentes étapes d’une session RTSP. Nous pouvons
ainsi voir concrètement comment sont utilisés les mécanismes détaillés précédemment.

36
Voici un exemple sur un passage d’un message RTSP avec les différentes méthodes qu’il peut
inclure :

method direction object requirement

DESCRIBE C->S P,S recommended
ANNOUNCE C->S, S->C P,S optional
GET_PARAMETER C->S, S->C P,S optional
OPTIONS C->S, S->C P,S required
(S->C: optional)
PAUSE C->S P,S recommended
PLAY C->S P,S required
RECORD C->S P,S optional
REDIRECT S->C P,S optional
SETUP C->S S required
SET_PARAMETER C->S, S->C P,S optional
TEARDOWN C->S P,S required

Object (P: presentation, S: stream)

Direction (C: client, S :serveur)

Copyright © 2010-2011 FA11 - Option SER

37
 ANNEXE

Précision sur la gestion nominative des adresses par DNS

Toute machine constituant un réseau de technologie Internet est identifiée par une
adresse longue de 32 bits. Pour faciliter l’identification des adresses, on a défini un
mécanisme permettant de nommer une machine, étant entendu que, puisque le protocole IP
nécessite l’utilisation d’adresses IP, il doit être possible à tout moment de retrouver l’adresse
correspondante.
Le Domain Name System (DNS) est constitué d’une hiérarchie de serveurs capables de
traduire un nom de domaine en une adresse Internet. Considérons par exemple, le serveur
nommé www.yahoo.fr. Il lui correspond l’adresse IP suivante : 194.237.109.72.
C’est précisément pour éviter que l’utilisateur ait à manipuler des adresses IP que le
mécanisme de DNS a été mis en place.
La dénomination du DNS est basée sur les codes nationaux définis par l’ITU (.fr, .be, etc)
gérés par des instances nationales et sur une série d’ajouts (.com, .edu, .org, etc). Pour toute
destination exprimée sous la forme d’un nom de domaine, l’ordinateur émet d’abord une
requête à un DNS, puis il utilise la véritable adresse IP pour contacter le correspondant.
Pour éviter des appels répétés au DNS, l’ordinateur conserve en mémoire l’adresse IP des
correspondants contactés précédemment.

Les réseaux à intégration de services sont constitués de routeurs qui assurent les
fonctionnalités de contrôle d’admission de flux et de réservation de ressources avec
différentes qualités de service.

Qualité de service sur le réseau internet QoS:

Il en existe trois niveaux :

 Meilleur effort (best effort ou Lack of QoS), ne fournissant aucune différenciation

entre plusieurs flux réseaux (flots prioritaires des flots moins prioritaires) et ne
permettant aucune garantie IP, TCP/IP.
 Service différencié (differenciated service ou soft QoS), permettant de définir des
niveaux de priorité aux différents flux réseau sans toutefois fournir une garantie
stricte.
 Service garanti (guaranteed service ou hard QoS), consistant à réserver des
ressources réseau pour certains types de flux. Le principal mécanisme utilisé pour
obtenir un tel niveau de service est RSVP.

38