Professional Documents
Culture Documents
1 - Introduction 2 - Les diffrentes couches du modle 2.1 - Les 7 couches 2.2 - La couche physique 2.3 - La couche liaison de donnes 2.4 - La couche rseau 2.5 - Couche transport 2.6 - La couche session 2.7 - La couche prsentation 2.8 - La couche application 3 - Transmission de donnes au travers du modle OSI 4 - Critique du modle OSI 4.1 - Ce n'tait pas le bon moment 4.2 - Ce n'tait pas la bonne technologie 4.3 - Ce n'tait pas la bonne implmentation 4.4 - Ce n'tait pas la bonne politique 5 - L'avenir d'OSI 6 - Discussion autour de la documentation 7 - Suivi du document
1 - Introduction
Les constructeurs informatiques ont propos des
architectures rseaux propres leurs quipements. Par exemple, IBM a propos SNA, DEC a propos DNA... Ces architectures ont toutes le mme dfaut : du fait de leur caractre propritaire, il n'est pas facile des les interconnecter, moins d'un accord entre constructeurs. Aussi, pour viter la multiplication des solutions d'interconnexion d'architectures htrognes, l'ISO (International Standards Organisation), organisme dpendant de l'ONU et compos de 140 organismes nationaux de normalisation, a dvelopp un modle de rfrence appel modle OSI (Open Systems Interconnection). Ce modle dcrit les concepts utiliss et la dmarche suivie pour normaliser l'interconnexion de systmes ouverts (un rseau est compos de systmes ouverts lorsque la modification, l'adjonction ou la suppression d'un de ces systmes ne modifie pas le comportement global du rseau).
architecture de rseau, car il ne prcise pas rellement les services et les protocoles utiliser pour chaque couche. Il dcrit plutt ce que doivent faire les couches. Nanmoins, l'ISO a crit ses propres normes pour chaque couche, et ceci de manire indpendante au modle, i.e. comme le fait tout constructeur. Les premiers travaux portant sur le modle OSI datent de 1977. Ils ont t bass sur l'exprience acquise en matire de grands rseaux et de rseaux privs plus petits ; le modle devait en effet tre valable pour tous les types de rseaux. En 1978, l'ISO propose ce modle sous la norme ISO IS7498. En 1984, 12 constructeurs europens, rejoints en 1985 par les grands constructeurs amricains, adoptent le
des bits de faon brute sur un canal de communication. Cette couche doit garantir la parfaite transmission des donnes (un bit 1 envoy doit bien tre reu comme bit valant 1). Concrtement, cette couche doit normaliser les caractristiques lectriques (un bit 1 doit tre reprsent par une tension de 5 V, par exemple), les caractristiques mcaniques (forme des connecteurs, de la topologie...), les caractristiques fonctionnelles des circuits de donnes et les procdures d'tablissement, de maintien et de libration du circuit de donnes. L'unit d'information typique de cette couche est le bit, reprsent par une certaine diffrence de potentiel.
2.3 - La couche liaison de donnes Son rle est un rle de "liant" : elle va transformer la couche
physique en une liaison a priori exempte d'erreurs de transmission pour la couche rseau. Elle fractionne les donnes d'entre de l'metteur en trames, transmet ces trames en squence et gre les trames d'acquittement renvoyes par le rcepteur. Rappelons que pour la couche physique, les donnes n'ont aucune signification particulire. La couche liaison de donnes doit donc tre capable de reconnatre les frontires des trames. Cela peut poser quelques problmes, puisque les squences de bits utilises pour cette reconnaissance peuvent apparatre dans les donnes.
La couche liaison de donnes doit tre capable de renvoyer une trame lorsqu'il y a eu un problme sur la ligne de transmission. De manire gnrale, un rle important de cette couche est la dtection et la correction d'erreurs intervenues sur la couche physique. Cette couche intgre galement une fonction de contrle de flux pour viter l'engorgement du rcepteur. L'unit d'information de la couche liaison de donnes est la trame qui est composes de quelques centaines quelques milliers d'octets maximum.
rseau, i.e. le routage des paquets sur ce sousrseau et l'interconnexion des diffrents sousrseaux entre eux. Au moment de sa conception, il faut bien dterminer le mcanisme de routage et de calcul des tables de routage (tables statiques ou dynamiques...). La couche rseau contrle galement l'engorgement du sous-rseau. On peut galement y intgrer des fonctions de comptabilit pour la facturation au volume, mais cela peut tre dlicat.
2.5 - Couche transport Cette couche est responsable du bon acheminement des
messages complets au destinataire. Le rle principal de la couche transport est de prendre les messages de la couche session, de les dcouper s'il le faut en units plus petites et de les passer la couche rseau, tout en s'assurant que les morceaux arrivent correctement de l'autre ct. Cette couche effectue donc aussi le rassemblage du message la rception des morceaux. Cette couche est galement responsable de l'optimisation des ressources du rseau : en toute rigueur, la couche transport cre une connexion rseau par connexion de transport requise par la couche session, mais cette couche est capable de crer plusieurs connexions rseau par processus de la couche session pour rpartir les donnes, par exemple pour amliorer le dbit. A l'inverse, cette couche est capable d'utiliser une seule connexion rseau pour transporter plusieurs messages la fois grce au multiplexage. Dans tous les cas, tout ceci doit tre transparent pour la couche
service fournir la couche session, et finalement aux utilisateurs du rseau : service en mode connect ou non, avec ou sans garantie d'ordre de dlivrance, diffusion du message plusieurs destinataires la fois... Cette couche est donc galement responsable de l'tablissement et du relchement des connexions sur le rseau. Un des tous derniers rles voquer est le contrle de flux. C'est l'une des couches les plus importantes, car c'est elle qui fournit le service de base l'utilisateur, et c'est par ailleurs elle qui gre l'ensemble du processus de connexion, avec toutes les contraintes qui y sont lies.
changes entre tches distantes. Elle ralise le lien entre les adresses logiques et les adresses physiques des tches rparties. Elle tablit galement une liaison entre deux programmes d'application devant cooprer et commande leur dialogue (qui doit parler, qui parle...). Dans ce dernier cas, ce service d'organisation s'appelle la gestion du jeton. La couche session permet aussi d'insrer des points de reprise dans le flot de donnes de manire pouvoir reprendre le dialogue aprs une panne.
Typiquement, cette couche peut convertir les donnes, les reformater, les crypter et les compresser.
l'utilisateur et le rseau. C'est donc elle qui va apporter l'utilisateur les services de base offerts par le rseau, comme par exemple le transfert de fichier, la messagerie...
faut considrer que chaque couche est programme comme si elle tait vraiment horizontale, c'est dire qu'elle dialoguait directement avec sa couche paire rceptrice. Au moment de dialoguer avec sa couche paire, chaque couche rajoute un en-tte et l'envoie (virtuellement, grce la couche sous-jacente) sa couche paire.
modle OSI est que c'est peut-tre la structure rseau la plus tudie et la plus unanimement reconnue et pourtant ce n'est pas le modle qui a su s'imposer. Les spcialistes qui ont analys cet chec en ont dtermin 4 raisons principales.
4.1 - Ce n'tait pas le bon moment David Clark du MIT a mis la thorie suivant quant l'art
et la manire de publier une norme au bon moment. Pour lui, dans le cycle de vie d'une norme, il y a 2 pics principaux d'activit : la recherche effectue dans le domaine couvert par la norme, et les investissements des industriels pour l'implmentation et la mise en place de la norme. Ces deux pics sont spars par un creux d'activit qui apparat tre en fait le moment idal pour la publication de la norme : il n'est ni trop tt par rapport la recherche et on peut donc assurer une certaine matrise, et il n'est ni trop tard pour les investissements et les industriels sont prts utiliser des capitaux pour l'implmenter.
Le modle OSI tait idalement plac par rapport la recherche, mais hlas, le modle TCP/IP tait dj en phase d'investissement prononc (lorsque le modle OSI est sorti, les universits amricaines utilisaient dj largement TCP/IP avec un certain succs) et les industriels n'ont pas ressenti le besoin d'investir dessus.
4.2 - Ce n'tait pas la bonne technologie Le modle OSI est peut-tre trop complet et trop
complexe. La distance entre l'utilisation concrte (l'implmentation) et le modle est parfois importante. En effet, peu de programmes peuvent utiliser ou utilisent mal l'ensemble des 7 couches du modle : les couches session et prsentation sont fort peu utilises et l'inverse les couches liaison de donnes et rseau sont trs souvent dcoupes en sous-couches tant elles sont complexes. OSI est en fait trop complexe pour pouvoir tre proprement et efficacement implment. Le comit rdacteur de la norme a mme du laisser de ct certains points techniques, comme la scurit et le codage, tant il tait dlicat de conserver un rle bien dtermin chaque couche ainsi complte. Ce modle est galement redondant (le contrle de flux et le contrle d'erreur apparaissent pratiquement dans chaque couche). Au niveau de l'implmentation, TCP/IP est beaucoup plus optimis et efficace.
au modle est qu'il n'est pas du tout adapt aux applications de tlcommunication sur ordinateur ! Certains choix effectus sont en dsaccord avec la faon dont les ordinateurs et les logiciels communiquent. La norme a en fait le choix d'un "systme d'interruptions" pour signaler les vnements, et sur des langages de programmation de haut niveau, cela est peu ralisable.
implmentation Cela tient tout simplement du fait que le modle est relativement complexe, et que du coup les premires implmentations furent relativement lourdes et lentes. A l'inverse, la premire implmentation de TCP/IP dans l'Unix de l'universit de Berkeley (BSD) tait gratuite et relativement efficace. Historiquement, les gens ont donc eu une tendance naturelle utiliser TCP/IP.
4.4 - Ce n'tait pas la bonne politique Le modle OSI a en fait souffert de sa trop forte
normalisation. Les efforts d'implmentation du modle taient surtout "bureaucratiques" et les gens ont peut-tre vu a d'un mauvaise oeil.
A l'inverse, TCP/IP est venu d'Unix et a t tout de suite utilis, qui plus est par des centres de recherches et les universits, c'est--dire les premiers a avoir utilis les rseaux de manire pousse. Le manque de normalisation de TCP/IP a t contre-balanc par une implmentation rapide et efficace, et une utilisation dans un milieu propice sa propagation.
5 - L'avenir d'OSI
Au niveau de son utilisation et
implmentation, et ce malgr une mise jour du modle en 1994, OSI a clairement perdu la guerre face TCP/IP. Seuls quelques grands constructeurs dominant conservent le modle mais il est amen disparatre d'autant plus vite qu'Internet (et donc TCP/IP) explose.
longtemps dans les mmoires pour plusieurs raisons. C'est d'abord l'un des premiers grands efforts en matire de normalisation du monde des rseaux. Les constructeurs ont maintenant tendance faire avec TCP/IP, mais aussi le WAP, l'UMTS etc. ce qu'il devait faire avec OSI, savoir proposer des normalisations ds le dpart. OSI marquera aussi les mmoires pour une autre raison : mme si c'est TCP/IP qui est concrtement utilis, les gens ont tendance et utilisent OSI comme le modle rseau de rfrence actuel. En fait, TCP/IP et OSI ont des structures trs proches, et c'est surtout l'effort de normalisation d'OSI qui a impos cette "confusion" gnrale entre les 2 modles. On a communment tendance considrer TCP/IP comme l'implmentation relle de OSI.
Le modle TCP/IP
1 - Introduction
2 - Description du modle 2.1 - Un modle en 4 couches 2.2 - La couche hte rseau 2.3 - La couche internet 2.4 - La couche transport 2.5 - La couche application 3 - Comparaison avec le modle OSI et critique 3.1 - Comparaison avec le modle OSI 3.2 - Critique 4 - Discussion autour de la documentation 5 - Suivi du document
1 - Introduction
TCP/IP dsigne communment une architecture rseau,
mais cet acronyme dsigne en fait 2 protocoles troitement lis : un protocole de transport, TCP (Transmission Control Protocol) qu'on utilise "pardessus" un protocole rseau, IP (Internet Protocol). Ce qu'on entend par "modle TCP/IP", c'est en fait une architecture rseau en 4 couches dans laquelle les protocoles TCP et IP jouent un rle prdominant, car ils en constituent l'implmentation la plus courante. Par abus de langage, TCP/IP peut donc dsigner deux choses : le modle TCP/IP et la suite de deux protocoles TCP et IP.
2 - Description du modle
Le modle TCP/IP peut en effet tre dcrit
comme une architecture rseau 4 couches :
Le modle OSI a t mis ct pour faciliter la comparaison entre les deux modles.
2.2 - La couche hte rseau Cette couche est assez "trange". En effet, elle
semble "regrouper" les couches physique et liaison de donnes du modle OSI. En fait, cette couche n'a pas vraiment t spcifie ; la seule contrainte de cette couche, c'est de permettre un hte d'envoyer des paquets IP sur le rseau. L'implmentation de cette couche est laisse libre. De manire plus concrte, cette implmentation est typique de la technologie utilise sur le rseau local. Par exemple, beaucoup de rseaux locaux utilisent Ethernet ; Ethernet est une implmentation de la couche hte-rseau.
couche ralise l'interconnexion des rseaux (htrognes) distants sans connexion. Son rle est de permettre l'injection de paquets dans n'importe quel rseau et l'acheminement des ces paquets indpendamment les uns des autres jusqu' destination. Comme aucune connexion n'est tablie au pralable, les paquets peuvent arriver dans le dsordre ; le contrle de l'ordre de remise est ventuellement la tche des couches suprieures.
Du fait du rle imminent de cette couche dans l'acheminement des paquets, le point critique de cette couche est le routage. C'est en ce sens que l'on peut se permettre de comparer cette couche avec la couche rseau du modle OSI.
implmentation officielle : le protocole IP (Internet Protocol). Remarquons que le nom de la couche ("internet") est crit avec un i minuscule, pour la simple et bonne raison que le mot internet est pris ici au sens large (littralement, "interconnexion de rseaux"), mme si l'Internet (avec un grand I) utilise cette couche.
2.4 - La couche transport Son rle est le mme que celui de la couche transport du
modle OSI : permettre des entits paires de soutenir une conversation.
Officiellement, cette couche n'a que deux implmentations : le protocole TCP (Transmission Control Protocol) et le protocole UDP (User Datagram Protocol). TCP est un protocole fiable, orient connexion, qui permet l'acheminement sans erreur de paquets issus d'une machine d'un internet une autre machine du mme internet. Son rle est de fragmenter le message transmettre de manire pouvoir le faire passer sur la couche internet. A l'inverse, sur la machine destination, TCP replace dans l'ordre les fragments transmis sur la couche internet pour reconstruire le message initial. TCP s'occupe galement du contrle de flux de la connexion.
couche immdiatement suprieure la couche transport, tout simplement parce que les couches prsentation et session sont apparues inutiles. On s'est en effet aperu avec l'usage que les logiciels rseau n'utilisent que trs rarement ces 2 couches, et finalement, le modle OSI dpouill de ces 2 couches ressemble fortement au modle TCP/IP.
haut niveau, comme par exemple Telnet, TFTP (trivial File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), HTTP (HyperText Transfer Protocol). Le point important pour cette couche est le choix du protocole de transport utiliser. Par exemple, TFTP (surtout utilis sur rseaux locaux) utilisera UDP, car on part du principe que les liaisons physiques sont suffisamment fiables et les temps de transmission suffisamment courts pour qu'il n'y ait pas d'inversion de paquets l'arrive. Ce choix rend TFTP plus rapide que le protocole FTP qui utilise TCP. A l'inverse, SMTP utilise TCP, car pour la remise du courrier lectronique, on veut que tous les messages parviennent intgralement et sans erreurs.
chose suivante : le modle OSI faisait clairement la diffrence entre 3 concepts principaux, alors que ce n'est plus tout fait le cas pour le modle TCP/IP. Ces 3 concepts sont les concepts de services, interfaces et protocoles. En effet, TCP/IP fait peu la distinction entre ces concepts, et ce malgr les efforts des concepteurs pour se rapprocher de l'OSI. Cela est d au fait que pour le modle TCP/IP, ce sont les protocoles qui sont d'abord apparus. Le modle ne fait finalement que donner une justification thorique aux protocoles, sans les rendre vritablement indpendants les uns des autres.
mode de connexion. Certes, les modes orient connexion et sans connexion sont disponibles dans les deux modles mais pas la mme couche : pour le modle OSI, ils ne sont disponibles qu'au niveau de la couche rseau (au niveau de la couche transport, seul le mode orient connexion n'est disponible), alors qu'ils ne sont disponibles qu'au niveau de la couche transport pour le modle TCP/IP (la couche internet n'offre que le mode sans connexion). Le modle TCP/IP a donc cet avantage par rapport au modle OSI : les applications (qui utilisent directement la couche transport) ont vritablement le choix entre les deux modes de connexion.
3.2 - Critique Une des premires critiques que l'on peut mettre tient
au fait que le modle TCP/IP ne fait pas vraiment la distinction entre les spcifications et l'implmentation : IP est un protocole qui fait partie intgrante des spcifications du modle.
Une autre critique peut tre mise l'encontre de la couche hte rseau. En effet, ce n'est pas proprement parler une couche d'abstraction dans la mesure o sa spcification est trop floue. Les constructeurs sont donc obligs de proposer leurs solutions pour "combler" ce manque. Finalement, on s'aperoit que les couches physique et liaison de donnes sont tout aussi importantes que la couche transport. Partant de l, on est en droit de proposer un modle hybride 5 couches, rassemblant les points forts des modles OSI et TCP/IP :