c4 PDF

Exploration 1 - Couche transport OSI - Page 1 sur 43
Chapitre 4 : Couche transport OSI

Les rseaux de donnes et Internet tayent le rseau humain en permettant aux individus de
communiquer de faon transparente et fiable, aussi bien lchelon local quau niveau international.
Nous pouvons, sur un mme priphrique, utiliser des services aussi divers que les messageries
lectroniques, le Web ou les messageries instantanes pour envoyer des messages et recevoir des
informations. Grce aux applications de clients de messagerie, de navigateurs Internet et de clients
de messagerie instantane, nous sommes en mesure denvoyer et de recevoir des messages et des
informations par le biais dordinateurs et de rseaux.
Dans chacun de ces types dapplications, les donnes sont empaquetes, transportes et livres au
dmon du serveur appropri ou lapplication voulue sur le priphrique de destination. Le
processus dcrit dans la couche transport OSI accepte des donnes provenant de la couche
application et les prpare pour les adresser la couche rseau. La couche transport est globalement
responsable du transfert de bout en bout des donnes dapplication.
Ce chapitre est consacr ltude du rle de la couche transport dans le processus dencapsulation
des donnes dapplication en vue de leur utilisation par la couche rseau. La couche transport
remplit galement dautres fonctions :
elle permet de nombreuses applications de communiquer sur le rseau au mme moment,
sur un mme priphrique ;
elle vrifie, si cela est ncessaire, que toutes les donnes sont reues de faon fiable et dans
lordre par lapplication voulue ;
elle utilise des mcanismes de gestion des erreurs.
Objectifs pdagogiques
lissue de ce chapitre, vous serez en mesure deffectuer les tches suivantes :
Expliquer lutilit de la couche transport
Dfinir le rle de la couche transport en matire de transfert, de bout en bout, de donnes
entre applications
Dcrire le rle de deux protocoles utiliss par la couche transport TCP/IP, savoir les
protocoles TCP et UDP
Citer les principales fonctions de la couche transport, y compris en matire de fiabilit,
dadressage de ports et de segmentation
Expliquer comment les protocoles TCP et UDD grent, chacun, des fonctions cls
Reconnatre les situations o lutilisation des protocoles TCP ou UDP simpose et fournir des
exemples dapplications utilisant chacun de ces protocoles

1/ Rle de la couche transport
1/ objectifs de la couche transport
La couche transport segmente les donnes et se charge du contrle ncessaire au rassemblage de
ces blocs de donnes dans les divers flux de communication. Pour ce faire, il doit :
effectuer un suivi des communications individuelles entre les applications rsidant
sur les htes source et de destination ;
segmenter les donnes et grer chaque bloc individuel ;
rassembler les segments en flux de donnes dapplication ;
identifier les diffrentes applications.
Suivi des conversations individuelles
Tout hte peut hberger plusieurs applications qui communiquent sur le rseau. Chacune de ces
applications communique avec une ou plusieurs applications hberges sur des htes distants. Il
incombe la couche transport de grer les nombreux flux de communication entre ces applications.
Segmentation des donnes
Chaque application cre un flux de donnes envoyer vers une application distante ; ces donnes
doivent donc tre prpares pour tre expdies sur le support sous forme de blocs faciles grer.
Les protocoles de la couche transport dcrivent les services qui segmentent les donnes provenant
de la couche application. Il sagit notamment de lencapsulation devant sappliquer chaque bloc de
donnes. Des en-ttes doivent tre ajouts chaque bloc de donnes dapplication au niveau de la
couche transport pour indiquer quelle communication il est associ.
Reconstitution des segments
Lhte recevant les blocs de donnes peut les diriger vers lapplication approprie. Il faut en outre
que ces blocs de donnes individuels puissent tre rassembls dans un flux de donnes complet
utile la couche application. Les protocoles intervenant au niveau de la couche transport grent la
faon dont les informations den-tte de la couche transport servent rassembler les blocs de
donnes en flux qui seront transmis la couche application.
Identification des applications
Pour que les flux de donnes atteignent les applications auxquelles ils sont destins, la couche
transport doit identifier lapplication cible. Pour cela, la couche transport affecte un identificateur
chaque application. Les protocoles TCP/IP appellent cet identificateur un numro de port. Chaque
processus logiciel ayant besoin daccder au rseau se voit affecter un numro de port unique sur
son hte. Ce numro de port est inclus dans len-tte de la couche transport afin de prciser quelle
application ce bloc de donnes est associ.
La couche transport fait le lien entre la couche application et la couche infrieure responsable de la
transmission rseau. Cette couche accepte les donnes provenant de plusieurs conversations et les
fait descendre vers les couches infrieures sous forme de blocs faciles grer pouvant au final faire
lobjet dun multiplexage sur le support.
Les applications nont pas besoin de connatre les dtails du fonctionnement du rseau utilis. Les
applications gnrent des donnes qui sont envoyes dune application une autre sans se soucier
du type de lhte de destination, du type de support que les donnes doivent emprunter, du chemin
suivi par ces donnes, de l'encombrement dune liaison ni de la taille du rseau.

En outre, les couches infrieures ignorent que plusieurs applications envoient des donnes sur le
rseau. Leur responsabilit se limite livrer les donnes au priphrique appropri. La couche
transport trie ensuite ces blocs avant de les acheminer vers lapplication voulue.
Variabilit des besoins en donnes
Parce que des applications diffrentes ont des besoins diffrents, il existe plusieurs protocoles pour
la couche transport. Dans le cas de certaines applications, les segments doivent arriver dans un ordre
bien prcis pour tre traits correctement. Pour dautres applications, il faut que toutes les donnes
soient arrives pour quil soit possible de traiter nimporte laquelle dentre elles. Dautres
applications, enfin, tolrent la perte dune certaine quantit de donnes lors de la transmission sur le
rseau.
Les rseaux convergents actuels permettent des applications dont les besoins en matire de
transport sont trs diffrents de communiquer sur le mme rseau. Les diffrents protocoles
sappliquant la couche transport reposent sur des rgles varies qui permettent aux priphriques
de satisfaire ces diffrents besoins en donnes.
Certains protocoles noffrent que des fonctions de base permettant de livrer efficacement les blocs
de donnes entre les applications appropries. Ces types de protocoles sont particulirement utiles
pour les applications dont les donnes sont sensibles aux retards.
Dautres protocoles de la couche transport dcrivent des processus offrant des fonctions
supplmentaires, comme la remise fiable des donnes entre applications. Si ces fonctions
supplmentaires assurent des communications plus robustes entre applications au niveau de la
couche transport, elles entranent une surcharge supplmentaire et sont plus gourmandes en
ressources rseau.

Sparation de communications multiples
Reprsentez-vous un ordinateur connect un rseau qui envoie et reoit simultanment des
courriels et messages instantans, affiche des sites Web et passe un appel tlphonique par voix sur
IP. Chacune de ces applications envoie des donnes sur le rseau et en reoit simultanment.
Pourtant, les donnes de lappel tlphonique ne sont pas orientes vers le navigateur Web et le
texte des messages instantans ne finit pas dans un courriel.
De plus, les informations contenues dans un courriel ou une page Web doivent avoir t
intgralement reues et affiches pour prsenter un intrt pour lutilisateur. On considre certains
retards comme acceptables pour veiller ce que lensemble des informations soit reu et prsent.
Dans le cas dune conversation tlphonique, labsence de petits bocs peut par contre tre
considre comme acceptable. Il est en effet possible de dduire le contenu audio manquant partir
du contexte de la conversation ou de demander lautre interlocuteur de rpter ce quil vient de
dire. Ceci est jug prfrable aux retards que provoqueraient la gestion et le renvoi des segments
manquants par le rseau. Dans notre exemple, cest lutilisateur, et non le rseau, qui gre la
rexpdition ou la reconstitution des informations manquantes.

Comme nous vous lavons expliqu dans un chapitre prcdent, envoyer certains types de donnes
(par exemple une vido) sur un rseau sous forme dun flux de communication complet risque
dempcher dautres communications davoir lieu en mme temps. Ceci rend galement difficile la
reprise sur erreur et la retransmission des donnes endommages.
Fractionner les donnes en blocs plus petits et envoyer ceux-ci de la source vers la destination
permet plusieurs communications diffrentes dtre entrelaces (de faire lobjet dun multiplexage)
sur le mme rseau.
La segmentation des donnes, conformment aux protocoles de la couche transport, permet
denvoyer et de recevoir des donnes tout en excutant plusieurs applications simultanment sur un
ordinateur. En labsence de segmentation, une seule application, par exemple la lecture vido en
continu, pourrait recevoir des donnes. Il serait impossible de recevoir des courriels, de parler sur
une messagerie instantane ou dafficher des pages Web tout en visualisant la vido.
Au niveau de la couche transport, chaque ensemble de blocs transitant entre une application source
et une application de destination est appel une conversation.
Pour identifier chaque segment de donnes, la couche transport ajoute un en-tte contenant des
donnes binaires chaque bloc. Cet en-tte contient des champs de bits. Ce sont les valeurs
contenues dans ces champs qui permettent aux diffrents protocoles de la couche transport
dexcuter des fonctions diverses

2/ Contrle des conversions
Tous les protocoles de la couche transport ont des fonctions essentielles communes :
Segmentation et reconstitution. La plupart des rseaux limitent la quantit de donnes pouvant tre
incluses dans une mme unit de donnes de protocole. La couche transport divise les donnes
dapplication en blocs de donnes dune taille adquate. Une fois ces blocs parvenus destination, la
couche transport rassemble les donnes avant de les envoyer vers lapplication ou le service de
destination.
Multiplexage de conversations. De nombreux services ou applications peuvent sexcuter sur
chaque hte sur le rseau. Une adresse, appele port, est affecte chacun de ces services ou
applications afin que la couche transport puisse dterminer quel service ou application les donnes
se rapportent.

Dans le cadre des fonctions essentielles que sont la segmentation et la reconstitution des donnes, la
couche transport fournit, en plus des informations contenues dans les en-ttes :
des conversations avec connexion ;
un acheminement fiable ;
une reconstitution ordonne des donnes ;
un contrle du flux.

tablissement dune session
La couche transport est en mesure dorienter la connexion en crant des sessions entre les
applications. Ces connexions prparent les applications communiquer entre elles avant le transfert
des donnes. Dans ces sessions, il est possible de grer avec prcision les donnes dune
communication entre deux applications.
Acheminement fiable
Bien des circonstances peuvent entraner la corruption ou la perte dun bloc de donnes lors de son
transfert sur le rseau. La couche transport veille ce que tous les blocs atteignent leur destination
en demandant au priphrique source de retransmettre les donnes qui ont pu se perdre.
Livraison dans un ordre dfini
tant donn que les rseaux fournissent une multitude de routes dont les dlais de transmission
varient, il se peut que les donnes arrivent dans le dsordre. En numrotant et en ordonnant les
segments, la couche transport sassure que ces segments sont rassembls dans le bon ordre.
Contrle du flux
Les htes du rseau disposent de ressources limites, par exemple en ce qui concerne la mmoire ou
la bande passante. Quand la couche transport dtermine que ces ressources sont surexploites,
certains protocoles peuvent demander lapplication qui envoie les donnes den rduire le flux.
Ceci seffectue au niveau de la couche transport en rgulant la quantit de donnes que la source
transmet sous forme de groupe. Le contrle du flux contribue prvenir la perte de segments sur le
rseau et rendre inutiles les retransmissions.

3/ prise en charge des communications fiables
Souvenez-vous que la fonction premire de la couche transport est de grer les donnes
dapplication des conversations entre htes. Cependant, des applications diffrentes ont des
exigences diffrentes pour leurs donnes, de sorte que des protocoles de transport diffrents ont t
dvelopps afin de satisfaire ces exigences.
Un protocole de couche transport est en mesure dassurer lacheminement fiable des donnes. Dans
le contexte des rseaux, la fiabilit consiste veiller ce que chaque bloc de donnes envoy par la
source parvienne destination. Au niveau de la couche transport, les trois oprations de base en
matire de fiabilit consistent :
effectuer le suivi des donnes transmises ;
accuser rception des donnes ;
retransmettre toute donne nayant pas fait lobjet dun reu.

Pour cela, les processus de la couche transport de la source doivent effectuer le suivi de tous les
blocs de donnes de chaque conversation et retransmettre les donnes pour lesquelles la destination
na pas mis de reu. La couche transport de lhte de destination doit galement effectuer un suivi
des donnes lors de leur arrive et en accuser rception.

Ces processus assurant la fiabilit augmentent la surcharge des ressources du rseau du fait des
oprations de reu, de suivi et de retransmission. Pour prendre en charge ces oprations assurant la
fiabilit, un nombre plus important de donnes de contrle est chang entre les htes qui
expdient et ceux qui reoivent les donnes. Ces informations de contrle sont contenues dans len-
tte de la couche 4.
Il stablit ainsi un compromis entre la valeur accorde la fiabilit et la charge quelle reprsente
sur le rseau. Les dveloppeurs dapplications doivent dterminer quel type de protocole de
transport est appropri en fonction des exigences de leurs applications. Au niveau de la couche
transport, il existe des protocoles qui prcisent des mthodes choisies pour leur fiabilit, leur
livraison garantie ou leur acheminement au mieux. Dans le contexte des rseaux, lacheminement au
mieux est considr comme ntant pas fiable car aucun reu ne confirme que les donnes sont
arrives destination.
Dtermination du besoin de fiabilit
Certaines applications, comme les bases de donnes, les pages Web et les courriels, ont besoin que
toutes les donnes envoyes arrivent destination dans leur tat dorigine afin que ces donnes
soient utiles. Toute donne manquante risque de corrompre la communication en la rendant
incomplte ou illisible. Cependant, ces applications sont conues pour utiliser un protocole de
couche transport qui implmente la fiabilit. On considre que cette surcharge supplmentaire pour
le rseau est indispensable pour ces applications.
Dautres applications tolrent mieux la perte de petites quantits de donnes. Si, par exemple, un ou
deux segments dune lecture vido narrivent pas, cela ne fera que crer une interruption
momentane du flux. Ceci pourra se traduire par une distorsion de limage que lutilisateur ne
remarquera peut-tre mme pas.
Imposer une surcharge pour garantir la fiabilit de cette application risquerait de rduire lutilit de
lapplication. Limage produite par une lecture vido en continu serait fortement dgrade si le
priphrique de destination devait rendre compte des donnes perdues et retarder la lecture en
continu le temps quelles arrivent. Mieux vaut assurer un rendu aussi bon que possible de limage
laide des segments qui arrivent et renoncer la fiabilit. Si, pour une raison ou pour une autre, la
fiabilit est un impratif, ces applications peuvent mettre des demandes de vrification des erreurs
et de retransmission.

4/ TCP et UDP
Les deux protocoles de la suite de protocoles TCP/IP les plus couramment employs sont le protocole
TCP (Transmission Control Protocol) et le protocole UDP (User Datagram Protocol). Ces deux
protocoles grent les communications de nombreuses applications. Ce sont les fonctions spcifiques
implmentes par chaque protocole qui les diffrencient.
Protocole UDP (User Datagram Protocol)
Le protocole UDP est un protocole simple, sans connexion, dcrit par le document RFC 768. Il
prsente lavantage dimposer peu de surcharge pour lacheminement des donnes. Les blocs de
communications utiliss dans le protocole UDP sont appels des datagrammes.

Ces datagrammes sont envoys au mieux par ce protocole de couche transport.
o Le protocole UDP est notamment utilis par des applications de :
o Systme de noms de domaine (DNS)
o Lecture vido en continu
o Voix sur IP (VoIP)

Protocole TCP (Transmission Control Protocol)
Le protocole TCP est un protocole avec connexion dcrit dans le document RFC 793. Le protocole TCP
impose une surcharge pour accrotre les fonctionnalits. Le protocole TCP spcifie dautres fonctions,
savoir la livraison dans lordre, lacheminement fiable et le contrle du flux.

Chaque segment du protocole TCP utilise 20 octets de surcharge dans len-tte pour encapsuler les
donnes de la couche application alors que chaque segment du protocole UDP najoute sur 8 octets
de surcharge. Examinez le tableau comparatif ci-contre.

Le protocole TCP est utilis par des applications de :
o Navigateurs Web
o Courriel
o Transfert de fichiers
5/ Adressage de ports
Identification des conversations
Reprenons lexemple prcdent dun ordinateur envoyant et recevant simultanment des courriels,
des messages instantans, des pages Web et un appel de voix sur IP.
Les services bass sur les protocoles TCP et UDP effectuent le suivi des applications qui
communiquent. Pour diffrencier les segments et les datagrammes de chaque application, les
protocoles TCP et UDP utilisent chacun des champs den-tte identifiant ces applications de faon
unique. Ces identificateurs uniques sont les numros de port.
Len-tte de chaque segment ou datagramme contient un port source et un port de destination. Le
numro de port source est le numro associ lapplication dorigine sur lhte local pour cette
communication. Le numro de port de destination est le numro associ lapplication de
destination sur lhte distant pour cette communication.
Laffectation des numros de port seffectue de diffrentes faons selon que le message est une
requte ou une rponse. Alors que les processus serveur se voient attribuer des numros de port
statiques, les clients choisissent dynamiquement un numro de port pour chaque conversation.
Lorsquune application cliente envoie une requte une application serveur, le port de destination
inclus dans len-tte est le numro de port affect au dmon du service sexcutant sur lhte
distant. Le logiciel client doit savoir quel numro de port est associ au processus serveur sur lhte
distant. Ce numro de port de destination est configur par dfaut ou manuellement. Ainsi, quand
une application de navigateur Web envoie une requte un serveur Web, le navigateur utilise le
protocole TCP et le port numro 80, sauf indication contraire. Ceci est d au fait que le port 80 du
protocole TCP est le port affect par dfaut aux applications de service Web. De nombreuses
applications courantes ont des ports qui leur sont affects par dfaut.
Le port source dun en-tte de segment ou de datagramme dune requte client est gnr de faon
alatoire. Du moment que le numro de port nentre pas en conflit avec dautres ports utiliss par le
systme, le client peut choisir nimporte quel numro de port. Le numro de port fait office
dadresse de retour pour lapplication envoyant la requte. La couche transport effectue le suivi du
port et de lapplication lorigine de la requte afin que la rponse, quand elle sera envoye, soit
transmise lapplication approprie. Le numro de port de lapplication envoyant la requte sert de
numro de port de destination dans la rponse renvoye depuis le serveur.
Lensemble form par le numro de port de la couche transport et ladresse IP de la couche rseau
affecte lhte identifie de faon unique un processus prcis sexcutant sur un priphrique hte
spcifique. Cet ensemble est appel une interface de connexion. Il arrive parfois que les expressions
numro de port et interface de connexion soient utilises lune pour lautre. Dans le cadre de
ce cours, lexpression interface de connexion ne dsigne que la combinaison unique forme par
ladresse IP et le numro de port. Une paire dinterfaces de connexion, compose des adresses IP et
des numros de port source et de destination, est galement unique et identifie une conversation
entre deux htes.
Par exemple, une requte de page Web HTTP envoye un serveur Web (port 80) sexcutant sur un
hte avec une adresse IPv4 de couche 3 gale 192.168.1.20 sera destine linterface de connexion
192.168.1.20:80.
Si le navigateur Web demandant la page Web sexcute sur lhte 192.168.100.48 et que le numro
de port dynamique affect au navigateur Web est 49152, linterface de connexion de la page Web
sera linterface 192.168.100.48:49152.

L'Internet Assigned Numbers Authority (IANA) attribue les numros de ports. LIANA est une agence
de normalisation responsable de laffectation de diverses normes dadressage.

Il existe diffrents types de numros de ports :
Ports rservs (numros 0 1023). Ces numros sont rservs des services et applications. Ils sont
gnralement rservs des applications de type HTTP (serveur Web), POP3/SMTP (serveur de
messagerie) et Telnet. En dfinissant ces ports rservs pour une utilisation par des applications
serveur, il est possible de programmer les applications clientes de faon ce quelles demandent
tre connectes ce port prcis et au service qui lui est associ.

Ports inscrits (numros 1024 49151). Ces numros de ports sont affects des processus ou
applications dutilisateurs. Ces processus sont essentiellement des applications particulires quun
utilisateur a choisi dinstaller plutt que des applications courantes qui recevraient un port rserv.
Un client peut galement slectionner dynamiquement ces ports en tant que ports source lorsquils
ne sont pas utiliss par une ressource serveur.
Ports privs ou dynamiques (numros 49152 65535). galement appels ports phmres, ces
ports sont gnralement affects de faon dynamique des applications clientes lorsquune
connexion est initie. Il est relativement rare pour un client de se connecter un service par le biais
dun port dynamique ou priv (bien que certains programmes de partage de fichiers peer to peer le
fassent).
Utilisation du protocole TCP et du protocole UDP
Certaines applications utilisent le protocole TCP et le protocole UDP. En effet, la faible surcharge du
protocole UDP permet au service DNS de grer trs rapidement de nombreuses requtes de clients.
Parfois, cependant, lenvoi des informations demandes exige la fiabilit du protocole TCP. Dans ce
cas, le port rserv 53 est utilis par les deux protocoles en association avec ce service.
Liens
Vous trouverez une liste des numros de ports actuels sur le site
http://www.iana.org/assignments/port-numbers.


Il est parfois ncessaire de savoir quelles connexions TCP actives sont ouvertes et sexcutent sur un
hte en rseau. Netstat est un important utilitaire rseau permettant de vrifier ces connexions.
Netstat rpertorie le protocole utilis, ladresse et le numro de port locaux, ladresse et le numro
de port distants ainsi que ltat de la connexion.
Les connexions TCP inexpliques peuvent poser un risque de scurit majeur. Elles peuvent en effet
signaler que quelque chose ou quelquun est connect lhte local. En outre, les connexions TCP
inutiles consomment des ressources systme importantes et ralentissent donc les performances de
lhte. Il est conseill dutiliser Netstat pour examiner les connexions ouvertes sur un hte lorsque
les performances semblent peu satisfaisantes.
La commande netstat dispose de nombreuses options utiles.



6/ Segmentation et reconstitution : diviser et conqurir
Dans un chapitre prcdent, nous vous avons expliqu que les units de donnes de protocole sont
labores en faisant transiter les donnes dune application par divers protocoles afin de crer des
units de donnes de protocole qui sont ensuite transmises sur le support. Une fois les donnes
parvenues sur lhte de destination, le processus est invers jusqu ce que les donnes puissent tre
communiques lapplication.
Certaines applications transmettent de trs importants volumes de donnes pouvant parfois
atteindre plusieurs gigaoctets. Transmettre lensemble de ces donnes en un envoi massif serait peu
pratique car aucun autre trafic ne pourrait tre transmis sur le rseau pendant lenvoi de ces
donnes. De plus, lenvoi dune grosse quantit de donnes peut prendre de plusieurs minutes
plusieurs heures. En outre, si une erreur se produisait, lensemble du fichier de donnes serait perdu
ou devrait tre rexpdi. La mmoire tampon des priphriques rseau ne serait pas suffisante
pour stocker autant de donnes pendant leur transmission ou leur rception. La limite varie selon la
technologie rseau employe et le support physique particulier qui est utilis.
Diviser les donnes dapplication en blocs permet de sassurer que les donnes sont transmises en
tenant compte des limites du support et que les donnes provenant dapplications diffrentes
peuvent faire lobjet dun multiplexage sur le support.
Les protocoles TCP et UDP traitent diffremment la segmentation.
Avec le protocole TCP, chaque en-tte de segment contient un numro dordre. Ce numro dordre
permet aux fonctions de la couche transport, au niveau de lhte de destination, de rassembler les
segments dans lordre de leur envoi. Lapplication de destination peut ainsi disposer des donnes
sous la forme exacte voulue par lexpditeur.
Bien que les services utilisant le protocole UDP effectuent galement un suivi des conversations
entre les applications, ils ne prtent pas attention lordre dans lequel les informations ont t
transmises ni au maintien de la connexion. Un en-tte UDP ne contient pas de numro dordre. La
conception du protocole UDP est plus simple et produit moins de surcharge que le protocole TCP, de
sorte que le transfert de donnes est plus rapide.
Il se peut que les informations arrivent dans un ordre diffrent de celui dans lequel elles ont t
transmises car les diffrents paquets peuvent emprunter plusieurs chemins sur le rseau. Les
applications qui utilisent le protocole UDP doivent tolrer le fait que les donnes peuvent arriver
dans un ordre diffrent de celui dans lequel elles ont t envoyes.

2/ Protocole TCP : des communications fiables
1/ Fiabilisation des conversions
La fiabilit est le principal lment diffrentiateur entre les protocoles TCP et UDP. La fiabilit des
communications TCP est assure laide de sessions avec connexion. Avant quun hte utilisant le
protocole TCP nenvoie de donnes un autre hte, la couche transport initie un processus destin
tablir une connexion avec la destination. Cette connexion rend possible le suivi dune session, ou
dun flux de communication, entre les htes. Ce processus veille ce que chaque hte soit notifi de
la communication et quil y soit prt. Une conversation TCP complte exige ltablissement dune
session entre les htes dans les deux directions.
Lorsquune session a t tablie, la destination envoie des reus la source pour les segments quelle
reoit. Ces reus constituent llment de base de la fiabilit dans la session TCP. Quand la source
reoit un reu, elle sait que les donnes ont bien t livres et quelle peut cesser den effectuer le
suivi. Si la source ne reoit pas de reu dans un dlai prdtermin, elle retransmet ces donnes vers
la destination.
La surcharge provoque par lutilisation du protocole TCP provient en partie du trafic rseau gnr
par les reus et les retransmissions. Ltablissement des sessions cre une surcharge prenant la
forme dun change supplmentaire de segments. Une surcharge supplmentaire provoque par la
ncessit deffectuer un suivi des segments pour lesquels on attend un reu et par le processus de
retransmission pse galement sur les htes individuels.
La fiabilit est assure par le recours des champs du segment TCP qui ont, chacun, une fonction
prcise ainsi que lillustre la figure ci-contre. Nous tudierons ces champs plus tard dans cette
section.


2/ Processus serveur TCP
Comme nous lavons vu dans le chapitre prcdent, les processus applicatifs sexcutent sur des
serveurs. Ces processus attendent quun client lance une demande dinformation ou dautres
services.
Chaque processus applicatif qui sexcute sur le serveur est configur par dfaut, ou manuellement
par un administrateur systme, pour utiliser un numro de port. Deux services ne peuvent pas tre
affects au mme numro de port dun serveur particulier au sein des mmes services de la couche
transport. Il est impossible quune application de serveur Web et une application de transfert de
fichiers sexcutant sur un hte soient toutes deux configures pour utiliser le mme port (par
exemple le port TCP 8080). Quand une application de serveur active est affecte un port spcifique,
on considre que ce port est ouvert sur le serveur. Ceci signifie que la couche transport accepte
et traite les segments adresss ce port. Toute demande entrante dun client qui est adresse
linterface de connexion correcte est accepte et les donnes sont transmises lapplication de
serveur. De nombreux ports peuvent tre ouverts simultanment sur un serveur, chacun tant
destin une application de serveur active. Il est courant quun serveur fournisse plusieurs services
simultanment, par exemple en tant que serveur Web et en tant que serveur FTP.
Limiter laccs au serveur aux seuls ports associs aux services et applications devant tre accessibles
aux demandeurs autoriss est un moyen damliorer la scurit sur le serveur.
La figure ci-contre illustre laffectation typique de ports source et de destination dans des oprations
clients/serveurs TCP.

3/ Etablissement et fermeture d'une session TCP
Lorsque deux htes communiquent laide de TCP, une connexion est tablie avant que les donnes
ne puissent tre changes. Une fois la communication termine, les sessions sont fermes et il est
mis fin la connexion. Les mcanismes de connexion et de sessions permettent la fonction de
fiabilit de TCP.
Consultez la figure ci-contre pour dcouvrir les tapes de ltablissement et de la fermeture dune
connexion TCP.


Lhte effectue un suivi de chaque segment de donnes au sein dune session et change des
informations sur les donnes reues par chaque hte grce aux informations contenues dans len-
tte TCP.
Chaque connexion reprsente deux flux de communications, ou sessions, unidirectionnels. Pour
tablir la connexion, lhte effectue une connexion en trois tapes. Les bits de contrle de len-tte
TCP indiquent la progression et ltat de la connexion. La connexion en trois tapes :
vrifie que le priphrique de destination est bien prsent sur le rseau ;
sassure que le priphrique de destination a un service actif et quil accepte les requtes sur
le numro de port de destination que le client qui dmarre la session a lintention dutiliser ;
informe le priphrique de destination que le client source entend tablir une session de
communication sur ce numro de port.
Dans les connexions TCP, lhte faisant office de client initie la session auprs du serveur. Les trois
tapes de ltablissement dune connexion TCP sont les suivantes :
1. Le client initiant la session envoie au serveur un segment contenant un numro dordre initial
faisant office de requte afin de commencer une session de communication.
2. Le serveur rpond par un segment contenant un numro de reu gal au numro dordre reu plus
1, ainsi que son propre numro dordre de synchronisation. Ce numro est suprieur au numro
dordre car lACK est toujours loctet suivant attendu. Ce numro de reu permet au client de relier la
rponse au segment dorigine envoy au serveur.
3. Le client initiant la session rpond par un numro de reu gal au numro dordre reu plus un.
Ceci achve le processus dtablissement de la connexion.
Pour comprendre le processus de connexion en trois tapes, il convient dexaminer les diffrentes
valeurs changes par les deux htes. Dans len-tte du segment TCP se trouvent six champs de 1 bit
contenant des informations de contrle qui servent grer les processus TCP. Il sagit des champs :
URG : pointeur de donnes urgentes valide
ACK : champ de reu valide
PSH : fonction de livraison des donnes sans attendre le remplissage des tampons (Push)
RST : rinitialisation de la connexion
SYN : synchronisation des numros dordre
FIN : plus denvoi de donnes par lexpditeur
Ces champs sont appels des indicateurs car la valeur de chaque champ nest que de 1 bit et que,
donc, ils ne peut prendre que deux valeurs, savoir 1 ou 0. Quand une valeur de bit est dfinie sur 1,
ceci indique le type dinformations de contrle contenues dans le segment.
Un processus en quatre tapes permet dchanger les indicateurs pour mettre fin une connexion
TCP.
4/ Connexion TCP en 4 tapes
Les rsultats Wireshark vous permettent dexaminer le fonctionnement dune connexion TCP en trois
tapes :
tape 1
Un client TCP initie une connexion en trois tapes en envoyant un segment contenant lindicateur de
contrle SYN (Synchronize Sequence Number) qui indique une valeur initiale dans le champ de
numro dordre de len-tte. Cette valeur initiale du numro dordre, appele ISN (Initial Sequence
Number), est choisie de faon alatoire et sert commencer le suivi du flux de donnes entre le
client et le serveur pour cette session. LISN figurant dans len-tte de chaque segment est
incrment de un pour chaque octet de donnes envoy par le client au serveur tandis que la
conversation de donnes se poursuit.
Comme lillustre la figure ci-contre, le rsultat dun analyseur de protocole affiche lindicateur de
contrle SYN et le numro dordre relatif.
Lindicateur de contrle SYN est dfini et le numro dordre relatif est gal 0. Bien que dans le
graphique lanalyseur de protocole indique les valeurs relatives des numros dordre et de reus, les
vraies valeurs sont des nombres binaires de 32 bits. Nous pouvons dterminer les nombres rels
envoys dans les en-ttes de segments en examinant le volet des octets de paquet. Ici, vous pouvez
voir les quatre octets reprsents en hexadcimal.

tape 2
Le serveur TCP doit accuser rception du segment SYN provenant du client pour tablir la session du
client vers le serveur. Pour cela, le serveur renvoie au client un segment accompagn de lindicateur
ACK indiquant que le numro de reu est valide. Grce cet indicateur prsent dans le segment, le
client identifie ceci comme un reu indiquant que le serveur a reu le SYN du client TCP.
La valeur du champ du numro de reu est gale au numro dordre initial du client plus 1. Ceci
tablit une session du client vers le serveur. Lindicateur ACK demeurera dfini pour le reste de la
session. Souvenez-vous quen fait la communication entre le client et le serveur est compos de deux
sessions unidirectionnelles : une allant du client vers le serveur et lautre du serveur vers le client.
Dans cette deuxime tape de la connexion en trois tapes, le serveur doit initier la rponse du
serveur au client. Pour lancer cette session, le serveur utilise lindicateur SYN comme le client la fait.
Il inclut lindicateur de contrle SYN dans len-tte pour tablir une session entre le serveur et le
client. Lindicateur SYN prcise que la valeur initiale du champ de numro dordre se trouve dans
len-tte. Cette valeur servira effectuer le suivi du flux de donnes dans cette session en retour du
serveur vers le client.

Comme lillustre la figure ci-contre, les rsultats de lanalyseur de protocole montrent que les
indicateurs de contrle ACK et SYN sont dfinis et que les numros relatifs dordre et de reu sont
affichs.

tape 3
Enfin, le client TCP rpond laide dun segment contenant un ACK qui constitue la rponse au SYN
TCP envoy par le serveur. Ce segment ne contient pas de donnes de lutilisateur. La valeur du
champ du numro de reu est suprieure de 1 au numro dordre initial reu du serveur. Quand les
deux sessions sont tablies entre le client et le serveur, tous les segments supplmentaires changs
dans cette communication comporteront lindicateur ACK dfini.
Comme lillustre la figure ci-contre, le rsultat de lanalyseur de protocole montrent que lindicateur
ACK est positionn et affiche les numros de reus relatifs.
Il est possible de scuriser le rseau de donnes en :
refusant ltablissement de sessions TCP ;
autorisant uniquement ltablissement de sessions pour des services spcifiques ;
autorisant uniquement le trafic faisant dj partie de sessions tablies.
Ces mesures de scurit peuvent tre implmentes pour toutes les sessions TCP ou uniquement
pour certaines sessions slectionnes.

5/ Fermeture d'une session TCP
Pour fermer une connexion, il faut que lindicateur de contrle FIN de len-tte du segment soit
dfini. Pour mettre fin chaque session TCP unidirectionnelle, on utilise un change en deux tapes
constitue dun segment FIN et dun segment ACK. Pour mettre fin une seule conversation TCP,
quatre changes sont ncessaires pour mettre fin aux deux sessions. Remarque : les termes client et
serveur sont utiliss ici pour simplifier lexplication, mais le processus de fermeture peut tre initi
par nimporte lequel des deux htes terminant la session.

1. Quand le client na plus de donnes envoyer dans le flux, il envoie un segment dont lindicateur
FIN est dfini.

2. Le serveur envoie un segment ACK pour accuser rception du segment FIN afin de fermer la
session du client au serveur.

3. Le serveur envoie un segment FIN au client pour mettre fin la session du serveur au client.

4. Le client rpond laide dun segment ACK pour accuser rception du segment FIN envoy par le
serveur.

Quand lextrmit cliente de la session na plus aucune donne transfrer, elle dfinit lindicateur
FIN dans len-tte dun segment. Ensuite, lextrmit serveur de la connexion envoie un segment
normal contenant des donnes dont lindicateur ACK est dfini en utilisant le numro de reu,
confirmant ainsi que tous les octets de donnes ont t reus. Quand la rception de tous les
segments a t confirme, la session est ferme.
La session dans lautre sens est ferme selon le mme processus. Le rcepteur indique quil ny a plus
de donnes envoyer en dfinissant lindicateur FIN dans len-tte dun segment envoy la source.
Un reu en retour confirme que tous les octets de donnes ont t reus et que cette session, son
tour, se ferme.
Comme lillustre la figure ci-contre, les indicateurs de contrle FIN et ACK sont dfinis dans len-tte
du segment et ferment donc une session HTTP.


Il est galement possible de fermer la connexion laide dune connexion en trois tapes. Quand le
client na plus de donnes envoyer, il envoie un segment FIN au serveur. Si le serveur na plus de
donnes envoyer, il peut rpondre en dfinissant les indicateurs FIN et ACK simultanment et en
combinant ainsi deux tapes en une. Le client rpond par un segment ACK.

3/ Gestion des sessions TCP
1/ Reassemblage des segments TCP
Rordonnancement des segments dans lordre de leur transmission
Quand des services envoient des donnes laide du protocole TCP, il arrive que les segments
parviennent destination dans le dsordre. Pour que le destinataire puisse comprendre le message
dorigine, il faut que les donnes contenues dans ces segments soient ragences dans leur ordre
dorigine. Pour cela, des numros dordre sont affects len-tte de chaque paquet.
Lors de la configuration de la session, un numro dordre initial, ou ISN, est dfini. Ce numro dordre
initial reprsente la valeur de dpart des octets de cette session qui seront transmis lapplication
rceptrice. Lors de la transmission des donnes pendant la session, le numro dordre est incrment
du nombre doctets ayant t transmis. Ce suivi des octets de donnes permet didentifier chaque
segment et den accuser rception individuellement. Il est ainsi possible didentifier les segments
manquants.
Les numros dordre des segments permettent la fiabilit en indiquant comment rassembler et
rordonnancer les segments reus, ainsi que lillustre la figure ci-contre.
Le processus TCP rcepteur place les donnes dun segment dans une mmoire tampon de
rception. Les segments sont remis dans lordre correct et sont transmis la couche application une
fois quils ont t rassembls. Tous les segments reus dont les numros dordre ne sont pas
contigus sont conservs en vue dun traitement ultrieur. Puis ces segments sont traits quand les
segments contenant les octets manquants sont reus.

2/ Reu TCP avec fentrage
Confirmation de la rception des segments

Lune des fonctions de TCP est de veiller ce que chaque segment atteigne sa destination. Les
services TCP sur lhte de destination accusent rception des donnes reues lapplication source.

Le numro dordre et le numro de reu de len-tte du segment sont utiliss ensemble pour
confirmer la rception des octets de donnes contenus dans les segments. Le numro dordre est le
nombre relatif doctets qui ont t transmis dans cette session plus 1 (qui est le numro du premier
octet de donnes dans le segment actuel). TCP utilise le numro de reu des segments renvoys la
source pour indiquer loctet suivant de cette session que le rcepteur sattend recevoir. Cest ce
que lon appelle un reu prvisionnel.

La source est informe que la destination a reu tous les octets de ce flux de donnes jusqu loctet
indiqu par le numro de reu, mais sans inclure ce dernier. Lhte expditeur est cens envoyer un
segment qui utilise un numro dordre gal au numro de reu.

Souvenez-vous quen fait chaque connexion est compose de deux sessions unidirectionnelles. Les
numros dordre et les numros de reu sont changs dans les deux sens.
Dans lexemple de la figure ci-contre, lhte de gauche envoie des donnes lhte de droite. Il
envoie un segment contenant 10 octets de donnes pour cette session et un numro dordre gal 1
dans len-tte.
Lhte rcepteur sur la droite reoit le segment au niveau de la couche 4 et dtermine que le numro
dordre est 1 et quil y a 10 octets de donnes. Lhte renvoie alors un segment lhte de gauche
pour accuser rception de ces donnes. Dans ce segment, lhte dfinit le numro de reu 11 pour
indiquer que le prochain octet de donnes quil sattend recevoir dans cette session est loctet
numro 11.
Quand lhte metteur sur la gauche reoit ce reu, il peut envoyer le segment suivant contenant des
donnes pour cette session commenant par loctet numro 11.
Dans notre exemple, si lhte metteur devait attendre un reu pour chaque ensemble de 10 octets
reu, le rseau subirait un forte surcharge. Pour rduire la surcharge de ces reus, plusieurs
segments de donnes peuvent tre envoys lavance et faire lobjet dun reu par un unique
message TCP en retour. Ce reu contient un numro de reu bas sur le nombre total doctets reus
dans la session.
Prenons lexemple dun numro dordre de dbut gal 2000. Si 10 segments de 1000 octets chacun
taient reus, un numro de reu de 12001 serait renvoy la source.
La quantit de donnes quune source peut transmettre avant de devoir recevoir un reu est appele
la taille de fentre. La taille de fentre est un champ de len-tte TCP qui permet de grer les
donnes perdues et le contrle du flux.

3/ Retransmission TCP
Traitement des pertes de segments
Tous les rseaux, mme les mieux conus, connaissent parfois des pertes de donnes. Le protocole
TCP fournit donc des mthodes de traitement de ces pertes de segments. Parmi elles se trouve un
mcanisme de retransmission des segments contenant des donnes sans reu.
En gnral, un service sur lhte de destination utilisant le protocole TCP ne gnre de reu que pour
les squences contigus doctets. Si un ou plusieurs segments sont manquants, seules les donnes
des segments qui compltent le flux donnent lieu lmission de reus.
Par exemple, en cas de rception des segments dont les numros dordre vont de 1500 3000 et de
3400 3500, le numro du reu sera 3001. Ceci sexplique par le fait que certains segments nont pas
t reus entre les numros dordre 3001 et 3399.
Quand le protocole TCP sur lhte source na pas reu de reu aprs un dlai prdtermin, il revient
au dernier numro de reu et retransmet les donnes depuis ce point.
Le processus de retransmission nest pas spcifi par le document RFC et il incombe
limplmentation particulire du protocole TCP de le dterminer.
Dans une implmentation TCP classique, un hte peut transmettre un segment, placer une copie du
segment dans une file dattente de retransmission et lancer un minuteur. Quand le reu des donnes
est reu, le segment est supprim de la file dattente. Si le reu nest pas reu avant lcoulement du
dlai prvu, le segment est retransmis.
Aujourdhui, les htes utilisent galement une fonction facultative appele reus slectifs. Si les deux
htes prennent en charge les reus slectifs, la destination peut accuser rception des octets de
segments ne se suivant pas et lhte ne retransmettra que les donnes manquantes.
4/ Contrle de l'encombrement TCP
Contrle de flux
Le protocole TCP inclut galement des mcanismes de contrle de flux. Le contrle de flux contribue
la fiabilit des transmissions TCP en rglant le taux effectif de flux de donnes entre les deux
services de la session. Quand la source est informe que la quantit de donnes spcifie dans les
segments a t reue, elle peut continuer envoyer plus de donnes pour cette session.
Ce champ Taille de fentre dans len-tte TCP prcise la quantit de donnes pouvant tre transmise
avant quil ne soit ncessaire de recevoir un reu. La taille de fentre initiale est dtermine lors du
dmarrage de la session par lintermdiaire de la connexion en trois tapes.
Le mcanisme de retour dinformation TCP rgle le taux de transmission effectif des donnes sur le
flux maximum que le rseau et le priphrique de destination peuvent prendre en charge sans perte.
Le TCP sefforce de grer le taux de retransmission de faon ce que toutes les donnes soient
reues et que les retransmissions soient limites au maximum.
La figure ci-contre prsente une reprsentation simplifie de la taille de fentre et des reus. Dans
cet exemple, la taille de fentre initiale dune session TCP reprsente est dfinie 3000 octets.
Lorsque lexpditeur a transmis 3000 octets, il attend le reu de ces octets avant de transmettre
dautres segments de cette session.

Une fois que lexpditeur a reu le reu du destinataire, il peut transmettre 3000 octets
supplmentaires.
Pendant le dlai dattente de rception du reu, lexpditeur nenverra pas de segment
supplmentaire pour cette session. Quand le rseau est encombr ou que les ressources de lhte
rcepteur subissent une forte pression, le dlai peut augmenter. Plus ce dlai sallonge, plus le taux
de transmission effectif des donnes de cette session diminue. La diminution du taux de transfert des
donnes contribue rduire les conflits dutilisation des ressources.
Rduction de la taille de fentre
Lutilisation de tailles de fentres dynamiques permet galement de contrler le flux de donnes.
Quand les ressources rseau sont soumises de fortes contraintes, le protocole TCP peut rduire la
taille de fentre afin dimposer lenvoi plus frquent de reus pour les segments reus. Ceci a pour
effet de ralentir le taux de transmission car la source attend des reus des donnes plus frquents.
Lhte TCP destinataire envoie la valeur de la taille de fentre lexpditeur TCP afin de lui indiquer
le nombre doctets quil est prpar recevoir dans le cadre de cette session. Si la destination doit
ralentir le taux de communication parce que la mmoire tampon est limite, elle peut envoyer une
valeur de taille de fentre plus petite la source en lintgrant un reu.

Comme lillustre la figure ci-contre, si un hte rcepteur subit un encombrement, il peut rpondre
lhte expditeur avec un segment dont la taille de fentre est rduite. Ce graphique montre que lun
des segments a t perdu. Dans cette conversation, le destinataire a chang le champ de fentre
dans len-tte TCP des segments renvoys en le ramenant de 3000 1500. Lexpditeur a donc t
oblig de rduire la taille de fentre 1500.
Quand un certain temps se sera coul sans perte de donnes ni contraintes excessives sur les
ressources, le destinataire pourra recommencer augmenter la taille de fentre. Ceci rduit la
surcharge du rseau car un moins grand nombre de reus doit tre envoy. La taille de fentre
continuera augmenter jusqu ce que des donnes soient nouveau perdues, ce qui entranera une
rduction de la taille de fentre.
Ces augmentations et rductions dynamiques de la taille de fentre constituent un processus continu
dans le protocole TCP, processus qui dtermine la taille de fentre optimale pour chaque session
TCP. Dans les rseaux trs efficaces, les tailles de fentres peuvent augmenter beaucoup car les
donnes ne sont pas perdues. Sur les rseaux dont linfrastructure sous-jacente est soumise
beaucoup de contraintes, la taille de la fentre demeurera probablement rduite.

4/ Protocole UDP
1/ UDP : Faible surcharge contre la fiabilit
Le protocole UDP est un protocole simple offrant des fonctions de couche transport de base. Il cre
beaucoup moins de surcharge que le protocole TCP car il est sans connexion et ne propose pas de
mcanismes sophistiqus de retransmission, de squenage et de contrle de flux.
Mais cela ne signifie pas que les applications utilisant le protocole UDP manquent toujours de
fiabilit. Cela signifie simplement que ces fonctions ne sont pas fournies par le protocole de la
couche transport et quelles doivent tre implmentes un autre niveau, le cas chant.
Bien que le volume total de trafic UDP trouv sur un rseau typique soit relativement faible, des
protocoles importants de la couche application utilisent le protocole UDP, notamment :
DNS (Domain Name System)
SNMP (Simple Network Management Protocol)
DHCP (Dynamic Host Configuration Protocol)
RIP (Routing Information Protocol)
TFTP (Trivial File Transfer Protocol)
Jeux en ligne
Certaines applications, comme les jeux en ligne ou la voix sur IP, peuvent tolrer la perte dune
certaine quantit de donnes. Si ces applications utilisaient le protocole TCP, elles risqueraient dtre
confrontes de longs dlais pendant que le protocole TCP dtecterait les pertes de donnes et
retransmettrait les donnes. Ces dlais seraient plus prjudiciables lapplication que la perte dune
petite quantit de donnes. Certaines applications, comme le systme DNS, se contentent
simplement de rpter leur requte si elles ne reoivent pas de rponse. Elles nont donc pas besoin
du protocole TCP pour garantir la livraison du message.
La faible surcharge quengendre le protocole UDP rend celui-ci trs intressant pour de telles
applications.

2/ Rassemblage des datagrammes udp
Comme le protocole UDP nutilise pas de connexion, les sessions ne sont pas tablies avant que la
communication nait lieu comme cest le cas avec le protocole TCP. Le protocole UDP est connu pour
tre un protocole bas sur les transactions. En dautres termes, quand une application doit envoyer
des donnes, elle les envoie tout simplement.
De nombreuses applications utilisant le protocole UDP envoient de petites quantits de donnes
pouvant tenir dans un seul segment. Cependant, certaines applications envoient des volumes de
donnes plus importants qui doivent tre dcoups en plusieurs segments. Lunit de donnes de
protocole UDP est appele un datagramme, bien que les termes segment et datagramme soient
souvent utiliss lun pour lautre pour dcrire une unit de donnes de protocole de la couche
transport.
Quand plusieurs datagrammes sont envoys vers une destination, ils peuvent emprunter des
chemins diffrents et arriver dans le dsordre. Le protocole UDP neffectue pas de suivi des numros
dordre comme le fait le protocole TCP. Il na en effet aucun moyen de rordonnancer les
datagrammes pour leur faire retrouver leur ordre de transmission dorigine. Consultez la figure.
Le protocole UDP se contente donc de rassembler les donnes dans lordre dans lequel elles ont t
reues, puis de les transmettre lapplication. Si lapplication attache une grande importance
lordre des donnes, elle devra identifier lordre correct des donnes et dterminer leur mode de
traitement.

3/ Processus et requte des serveurs UDP
Comme cest le cas avec des applications bases sur le protocole TCP, des numros de ports rservs
sont affects aux applications serveur bases sur le protocole UDP. Quand ces applications ou
processus sexcutent, ils ou elles acceptent les donnes correspondant au numro de port attribu.
Quand le protocole UDP reoit un datagramme destin lun de ces ports, il transmet les donnes
applicatives lapplication approprie daprs son numro de port.

4/ Processus des clients UDP
Comme cest le cas avec le protocole TCP, la communication entre le client et le serveur est initie
par une application cliente qui demande des donnes un processus serveur. Le processus client
UDP slectionne un numro de port alatoire dans une plage dynamique de numros de ports et il
lutilise comme port source pour la conversation. Le port de destination est gnralement le numro
de port rserv affect au processus serveur.
Le choix alatoire des numros de ports source prsente galement un avantage en matire de
scurit. Quand il existe un modle prvisible de slection du port de destination, il est plus facile
pour un intrus de simuler un accs un client en tentant de se connecter au numro de port le plus
susceptible dtre ouvert.
tant donn que le protocole UDP ne cre pas de session, ds que les donnes sont prtes tre
envoyes et que les ports sont identifis, il peut crer le datagramme et le soumettre la couche
rseau pour son adressage et son envoi sur le rseau.
Souvenez-vous quune fois quun client a choisi le port source et le port de destination, la mme
paire de port est utilise dans len-tte de tous les datagrammes utiliss dans la transaction. Quand
des donnes sont renvoyes du serveur vers le client, les numros de port source et de port de
destination sont inverss dans len-tte du datagramme.

CONCLUSION

La couche transport fournit les donnes dont le rseau a besoin en :
divisant en segments les donnes reues dune application ;
ajoutant un en-tte pour identifier et grer chaque segment ;
utilisant les informations de len-tte pour rassembler les segments en donnes
dapplication ;
transfrant les donnes assembles lapplication adquate.
Les protocoles UDP et TCP sont couramment utiliss en tant que couche transport.
Les datagrammes UDP et les segments TCP ajoutent aux donnes des prfixes, composs den-ttes
contenant un numro de port source et un numro de port de destination. Ces numros de ports
permettent dorienter les donnes vers lapplication correcte sexcutant sur lordinateur de
destination.
Le protocole TCP ne transmet aucune donne au rseau tant quil na pas la confirmation que la
destination est prte les recevoir. Le protocole TCP gre alors le flux de donnes et renvoie tout
segment de donnes pour lequel la destination na pas envoy de reu. TCP utilise divers
mcanismes comme les connexions en trois tapes, les minuteurs, les reus et le fentrage
dynamique pour assurer la fiabilit de ces fonctions. Nanmoins, cette fiabilit impose une surcharge
au rseau car elle cre des en-ttes de segments beaucoup plus volumineux et accrot le trafic rseau
entre la source et la destination qui grent le transport des donnes.
Si les donnes dapplication doivent tre rapidement livres travers le rseau, ou si la bande
passante du rseau ne peut pas prendre en charge la surcharge reprsente par les messages de
contrle changs entre les systmes source et de destination, les dveloppeurs prfreront le
protocole UDP pour la couche transport. Ceci sexplique par le fait que le protocole UDP neffectue
pas de suivi, et naccuse pas rception des datagrammes parvenus leur destination. Il se contente
de transmettre les datagrammes reus la couche application dans lordre de leur arrive et il ne
rexpdie pas les datagrammes perdus. Ceci nimplique pourtant pas ncessairement que la
communication elle-mme nest pas fiable car les protocoles et services de la couche application
peuvent comporter des mcanismes permettant de traiter les datagrammes perdus ou retards si
lapplication lexige.
Les dveloppeurs dapplications choisissent le protocole de la couche transport rpondant le mieux
aux exigences des utilisateurs. Ces dveloppeurs noublient pas, cependant, que les autres couches
jouent un rle dans les communications sur les rseaux de donnes et quelles influencent leurs
performances.


c4 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

c4 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Exploration 1 - Couche transport OSI - Page 1 sur 43

Chapitre 4 : Couche transport OSI

Das könnte Ihnen auch gefallen