Skip to main content

Modèle OSI Sommaire Histoire | Aperçu | Présentation de la norme | Limitations du modèle et utilisations étendues | Le monde IP et le modèle OSI | Le modèle TCP/IP | Universalité du modèle abstrait OSI | Quelques protocoles | Liens externes | Notes et références | Menu de navigationReprésentation du Protocole TCP/IP sur le modèle OSIIntroduction aux réseaux informatiques, modèle OSI et TCP/IPInterview de Charles Bachman sur "Oral History""De Paul OTLET à INTERNET en passant par HYPERTEXTE"« TCP/IP Internet Protocol »norme ISO 7498:1984X.200Liste de mnémoniques, section « Modèle OSI »m

Modèle OSI


anglaisréseautous les systèmes informatiquesmodèleordinateursISOInternational Organization for Standardizationannées 1970DSACII-Honeywell-Bullinformatique distribuéeMitra 15Mini 6DecnetDECSNAIBMHubert Zimmermann1971INRIALouis PouzinDatagrammeCIIInternational Organization for StandardizationVinton Cerfbases de donnéesCharles Bachman1975PTTdatagrammeréseau CycladesTranspacTCP/IPInternetArpanetNCPInternetsystèmes ouverts1994normeréseauxnormeordinateurnormeRNISATMprotocoleinterfacesystème d'exploitationapplicationdonnéesxDSLSSLTCPATMRNISUMTSTCPUDPsomme de contrôleIP version 4IP version 6UDPICMPTCPmodèle Internet












Modèle OSI




Un article de Wikipédia, l'encyclopédie libre.






Sauter à la navigation
Sauter à la recherche




Diagramme du modèle OSI.


Le modèle OSI (de l'anglais Open Systems Interconnection) est une norme de communication, en réseau, de tous les systèmes informatiques. C'est un modèle de communications entre ordinateurs proposé par l'ISO (International Organization for Standardization en français Organisation Internationale de Normalisation) qui décrit les fonctionnalités nécessaires à la communication et l'organisation de ces fonctions.




Sommaire





  • 1 Histoire


  • 2 Aperçu


  • 3 Présentation de la norme

    • 3.1 Concepts et terminologie : services, protocoles et interfaces


    • 3.2 Architecture en couches

      • 3.2.1 Caractérisation résumée des couches


      • 3.2.2 Quelques précisions



    • 3.3 Les fonctions communes

      • 3.3.1 Fiabilisation des communications


      • 3.3.2 Fonctions de transformation




  • 4 Limitations du modèle et utilisations étendues


  • 5 Le monde IP et le modèle OSI


  • 6 Le modèle TCP/IP


  • 7 Universalité du modèle abstrait OSI


  • 8 Quelques protocoles


  • 9 Liens externes


  • 10 Notes et références




Histoire |


Le modèle OSI a été conçu dans les années 1970, sur fond de rivalités entre trois architectures de conceptions différentes : la DSA lancée par CII-Honeywell-Bull innove dans l'informatique distribuée en mettant en avant les mini-ordinateurs Mitra 15 puis Mini 6, tandis que Decnet, de DEC, et SNA d'IBM donnent une plus grande place au site central, contrôlant l’ensemble des ressources matérielles et logicielles, les utilisateurs y accédant pour une "session" via des terminaux passifs.


Hubert Zimmermann est recruté en 1971 à l'INRIA par Louis Pouzin pour développer le Datagramme, technologie qui suscite un enthousiasme international[1], appuyée par la CII[2]. Responsable et secrétaire[3] du groupe de travail "Architecture informatique", au sein de l'International Organization for Standardization, il est le concepteur de la première version de l’architecture OSI, selon Vinton Cerf[1], avec le renfort du spécialiste des bases de données Charles Bachman[4]. Dès 1975, les PTT ont en effet combattu le datagramme et le réseau Cyclades[5], pour lui préférer Transpac[6].


C'est en mars 1978 que Charles Bachman présente son modèle de communication en 7 couches dans le document ISO/TC97/SC16/N34.
Les grands opérateurs télécoms européens, alors tous publics, la combattent. C'est à cause de ce retard et de son contexte trop peu ouvert, que la norme OSI sera supplantée par TCP/IP dans le domaine de l'Internet naissant puisqu'il sera adopté par le réseau Arpanet le 1er janvier 1983 (en remplacement du protocole NCP[7]).
L'OSI devient une norme en 1984 : la norme ISO 7498:1984[8] du 15 novembre 1984 qui sera révisée en 1994 sous la norme ISO/IEC 7498-1:1994, à un moment où il lui manque encore une vraie couche Internet[9] ;



Aperçu |


La norme complète, de référence ISO 7498, est globalement intitulée « Modèle basique de référence pour l'interconnexion des systèmes ouverts (OSI) » et est composée de 4 parties :


  1. Le modèle de base (ref. 7498-1)

  2. Architecture de sécurité (ref. 7498-2)

  3. Dénomination et adressage (ref. 7498-3)

  4. Cadre général de gestion (ref. 7498-4)

La version de cet article ainsi que les articles consacrés à chacune des couches du modèle se concentrent sur la partie 1, révision de 1994. L'UIT-T en a approuvé le texte à l'identique sous le numéro de recommandation X.200[10] en 1994.


Le texte de la norme proprement dite est très abstrait car il se veut applicable à de nombreux types de réseaux. Pour la rendre plus compréhensible, en plus de présenter la norme, cet article fait des liens avec les réalisations concrètes telles qu'on les trouve dans un ordinateur, c’est-à-dire des piles protocolaires concrètes (un « système réel » au sens de la section 4). De plus, la norme n'indique pas de mécanismes propres à assurer les fonctions définies alors que cet article le fait. Les exemples de services et surtout de protocoles sont pris dans le monde IP (probablement le plus connu mais aussi le plus éloigné de l'esprit de la norme), le monde RNIS (y compris la seconde génération, plus connue sous le nom ATM) et parfois le monde OSI (qui ne fait pas que des modèles). Les combinaisons offertes par le modèle sont beaucoup plus nombreuses que celles réalisées dans des piles de protocoles existantes, on ne peut donc pas donner d'exemple réel pour toutes les fonctions.



Présentation de la norme |


L'objectif de cette norme est de spécifier un cadre général pour la création de normes ultérieures cohérentes. Le modèle lui-même ne définit pas de service particulier et encore moins de protocole.



Concepts et terminologie : services, protocoles et interfaces |


Le modèle est essentiellement une architecture en couches définies et délimitées avec les notions de service, de protocole et d'interface.


  • Un service est une description abstraite de fonctionnalités à l'aide de primitives (commandes ou événements) telles que demande de connexion ou réception de données.

  • Un protocole est un ensemble de messages et de règles d'échange réalisant un service.

  • Une interface (« point d'accès au service » dans la norme) est le moyen concret d'utiliser le service. Dans un programme, c'est typiquement un ensemble de fonctions de bibliothèque ou d'appels systèmes. Dans une réalisation matérielle, c'est par exemple un jeu de registres à l'entrée d'un circuit.

Les détails d'un service varient bien sûr d'une architecture de réseau à l'autre. La classification la plus grossière se fait selon que le service fonctionne en mode connecté ou non. Malgré cette variabilité, les fonctions communes ont des noms conventionnellement constants. Ces noms ne proviennent toutefois pas directement de ISO 7498-1.



connection.request 

est une demande de connexion sortante, i.e. à l'initiative d'une entité locale.


connection.indication 

correspond à l'événement « Une demande de connexion entrante a été reçue. »


connection.response 

est l'indication d'acceptation ou de rejet de la connexion


connection.confirmation 

correspond à l'événement « La réponse du demandé a été reçue. » C'est un acquittement.


data.request, data.indication et data.confirm 

sont le pendant pour les données.

Les données fournies à une primitive de service sont appelées (N)-SDU (« Service Data Unit ») où N est l'indication de la couche, son numéro dans la norme, parfois une lettre tirée du nom de la couche. Les messages d'un protocole sont appelés PDU (« Protocol Data Unit »).



Architecture en couches |



































Modèle OSI


PDU
Couche
Fonction
Couches hautes

Donnée
7
Application
Point d'accès aux services réseau
6
Présentation
Gère le chiffrement et le déchiffrement des données, convertit les données machine en données exploitables par n'importe quelle autre machine
5
Session
Communication Interhost, gère les sessions entre les différentes applications

Segment (en) / Datagramme
4
Transport
Connexion de bout en bout, connectabilité et contrôle de flux ; notion de port (TCP et UDP)
Couches matérielles

Paquet
3
Réseau
Détermine le parcours des données et l'adressage logique (adresse IP)

Trame
2
Liaison
Adressage physique (adresse MAC)

Bit
1
Physique
Transmission des signaux sous forme numérique ou analogique

Le modèle comporte sept couches succinctement présentées ci-dessus de bas en haut et détaillées dans leurs articles respectifs. Ces couches sont parfois réparties en deux groupes.


Les quatre couches inférieures sont plutôt orientées communication et sont souvent fournies par un système d'exploitation et par le matériel.


Les trois couches supérieures sont plutôt orientées application et plutôt réalisées par des bibliothèques ou un programme spécifique. Dans le monde IP, ces trois couches sont rarement distinguées. Dans ce cas, toutes les fonctions de ces couches sont considérées comme faisant partie intégrante du protocole applicatif.


Par ailleurs, les couches basses sont normalement transparentes pour les données à transporter, alors que les couches supérieures ne le sont pas nécessairement, notamment au niveau présentation.


Dans une telle architecture, une « entité » de niveau (N+1) envoie des données avec la primitive « data.request » à l'entité de niveau (N) en lui fournissant comme données un (N+1)-PDU qui sera à son tour encapsulé dans un (N)-PDU. Côté récepteur, chaque entité analyse l'enveloppe protocole correspondant à sa couche et transmet les données à la couche supérieure sous la forme d'une primitive « data.indication ».


Certaines fonctions comme la détection des erreurs de transmission, leur correction et le contrôle de flux peuvent être présentes dans plusieurs couches. Ces fonctions sont décrites globalement plus loin.



Caractérisation résumée des couches |


La caractérisation donnée ici est tirée du chapitre 7 de ISO 7498-1. La description originelle donne en plus, pour chaque couche, les fonctions de manipulation de commandes ou de données significatives parmi celles décrites plus bas.


  1. La couche « physique » est chargée de la transmission effective des signaux entre les interlocuteurs. Son service est limité à l'émission et la réception d'un bit ou d'un train de bit continu (notamment pour les supports synchrones (concentrateur)).

  2. La couche « liaison de données » gère les communications entre 2 machines directement connectées entre elles, ou connectées à un équipement qui émule une connexion directe (commutateur).

  3. La couche « réseau » gère les communications de proche en proche, généralement entre machines : routage et adressage des paquets (cf. note ci-dessous).

  4. La couche « transport » gère les communications de bout en bout entre processus (programmes en cours d'exécution).

  5. La couche « session » gère la synchronisation des échanges et les « transactions », permet l'ouverture et la fermeture de session.

  6. La couche « présentation » est chargée du codage des données applicatives, précisément de la conversion entre données manipulées au niveau applicatif et chaînes d'octets effectivement transmises.

  7. La couche « application » est le point d'accès aux services réseaux, elle n'a pas de service propre spécifique et entrant dans la portée de la norme.

Il existe différents moyens mnémotechniques pour les retenir plus facilement[11].



Quelques précisions |


Lorsque les services réseau et transport fonctionnent tous les deux en mode connecté, il n'y a pas toujours de distinction claire entre ces deux services. Il y a toutefois deux cas où cela est très simple :


  • Si le service réseau n'autorise qu'une seule connexion entre deux machines : dans ce cas, les connexions de niveau transport sont nécessairement multiplexées sur une connexion de niveau réseau et la distinction est nette.

  • Si les services des deux couches relatifs à la correction des erreurs sont différents : ces fonctions peuvent n'être présentes que dans une seule des deux couches.


Les fonctions communes |



Fiabilisation des communications |


L'un des rôles majeurs des couches 2 à 4, présentes dans nombre de piles protocolaires, est la construction d'une connexion exempte d'erreurs de transmission. Cela signifie que les données transmises sont reçues sans corruption, perte, réordonnancement ni duplication. Cela implique qu'au moins une couche, et en pratique plusieurs, fasse de la détection d'erreur, de la correction d'erreur ou de la retransmission de données et du contrôle de flux.


Détection d'erreurs 

repérage des PDU dont au moins un bit a changé de valeur lors du transfert.

Correction des erreurs 

Compensation des erreurs soit par correction des données à l'aide de code correcteurs d'erreurs ou par destruction du PDU erroné et demande de retransmission.

Contrôle de flux 

Synchronisation des communications destinée à empêcher qu'un interlocuteur reçoive plus de PDU qu'il ne peut en traiter.

Les contrôles de flux des couches 2 et 3 peuvent sembler redondants, mais ce n'est pas nécessairement le cas. En effet, le contrôle de flux au niveau 2 garantit l'asservissement seulement sur une ligne. Mais si une machine est dotée de plusieurs interfaces, c'est le cas notamment de tous les routeurs, et qu'il n'y a pas de contrôle de flux sur au moins une des interfaces, il y a un risque de saturation dans l'entité de niveau réseau. Ce cas se présente en particulier dans les réseaux X.25 où le contrôle de flux est une option, négociée à l'ouverture de la connexion.



Fonctions de transformation |


En plus de la structure en couche, le modèle définit aussi une série de mécanismes standards de manipulation de commandes ou de données, utilisées pour la réalisation d'un service. Cette section définit les plus courantes. Ces transformations sont décrites par paire d'opérations inverses l'une de l'autre.


Multiplexage et démultiplexage de connexion 

Utilisation d'une connexion de niveau N pour transporter les PDU de plusieurs connexions de niveau N+1. Symétriquement, démultiplexer consiste à séparer les (N+1)-PDU entrants par connexion. Par exemple, ce mécanisme est prévu dans les réseaux ATM par la « couche » AAL 3/4.

Éclatement et recombinaison 

Opérations similaires dans lesquelles les (N+1)-PDU sont répartis sur plusieurs connexions de niveau N. Cela est utilisé en particulier par les utilisateurs d'accès RNIS pour augmenter le débit disponible.

Segmentation et réassemblage 

Lorsque le service fourni par la couche (N) fixe une limite de taille sur les données trop petites par rapport au service de la couche (N+1), la couche (N+1) découpe les (N+1)-SDU en plusieurs fragments correspondant chacun à un (N+1)-PDU avant envoi. À la réception, la couche (N+1) concatène les fragments pour retrouver le (N+1)-SDU initial. Cela est massivement utilisé dans les réseaux ATM et dans SSL/TLS. Pour IP, cette fonction est traditionnellement appelée « fragmentation ».


Limitations du modèle et utilisations étendues |


Cette section illustre quelques cas où une architecture réseau ne peut entrer complètement dans le cadre du modèle OSI.


Le modèle prévoit que dans une pile concrète, il y ait un et un seul protocole par couche. Il y a toutefois des cas où cela est quasi impossible, en particulier lors de l'interconnexion de réseaux hétérogènes, c’est-à-dire utilisant des jeux de protocoles différents. Par exemple, un tunnel simple permet de relier 2 réseaux homogènes en traitant un réseau d'un autre type comme une connexion point à point. C'est cette technique qui est utilisée pour relier temporairement une machine isolée à Internet (hors-lignes xDSL) : Un modem gère une connexion téléphonique entre 2 machines distantes, donc une connexion de niveau 3 dans la pile RNIS, et l'utilise pour transmettre des trames PPP, protocole de niveau 2 alors que dans une pile canonique, cela serait des PDU de niveau transport (4).


Il y a aussi des situations où 2 protocoles de même niveau sont utilisés simultanément, car la combinaison du service fourni et du service attendu de la couche inférieure l'exige. Ainsi, dans le monde IP, les protocoles SSL et TCP fournissent tous deux un service de communication point à point entre processus, SSL pouvant se substituer à TCP, mais le seul protocole standard réalisant le service attendu par SSL pour fonctionner est TCP. On superpose donc SSL sur TCP.


Dans certaines architectures réseau, le service offert aux machines d'extrémité n'est pas suffisant pour satisfaire les besoins internes au réseau. Par exemple, dans un réseau ATM, le service réseau est en mode connecté. Il faut donc une pile protocolaire capable de transporter la signalisation (les messages de gestion des connexions) mais le service offert par cette pile n'est pas accessible aux machines d'extrémité. Pour modéliser cela, on superpose au découpage « horizontal » en couche, un découpage « vertical » en « plan » dans lequel les piles protocolaires sont indépendantes. Ainsi, un modèle de réseau ATM est constitué de 3 plans : le plan usager pour les données ordinaires, le plan de contrôle pour le transport de la signalisation et un plan de gestion pour la supervision interne au réseau. Les réseaux téléphoniques (réseaux fixes RNIS et réseaux UMTS) ont aussi un découpage en plan similaire.



Le monde IP et le modèle OSI |


S'il y a bien une correspondance grossière entre les protocoles de la pile IP et les couches du modèle, on ne peut pas considérer que la pile IP soit vraiment compatible avec le modèle OSI. En particulier, la séparation des couches dans la pile IP est nettement plus approximative. En voici 2 illustrations.


Pour être conforme au modèle, un protocole d'une pile ne doit pas dépendre des protocoles des autres couches, mais uniquement du service fourni. À titre d'exemple de non-conformité, considérons la détection des erreurs dans une pile IP. Les 2 protocoles TCP et UDP ont dans leur en-tête une somme de contrôle pour la détection des erreurs. Le calcul de cette somme fait intervenir une partie de l'en-tête IP. Les protocoles TCP et UDP ne sont donc pas indépendants de IP. Cela se remarque notamment au fait que lors de passage de IP version 4 à IP version 6, il faut redéfinir la façon de calculer ces sommes de contrôle alors que les protocoles eux-mêmes n'ont pas réellement changé.


Lorsqu'un datagramme UDP, protocole de niveau transport en principe, arrive à une adresse (paire <adresse IP, numéro de port>) alors qu'il n'a pas de processus destinataire, l'erreur est signalée à l'émetteur en lui envoyant un paquet ICMP indiquant « port inaccessible ». Or ICMP est en principe un protocole de niveau réseau. La machine recevant ce paquet doit donc examiner la partie donnée de ce paquet pour déterminer le processus devant recevoir la notification d'erreur. Différence de protocole et perte de transparence des données sont 2 cas de mauvaise séparation des couches. Notons à cette occasion que TCP utilise en revanche un mécanisme normal pour cette situation : la levée de l'indicateur RST dans le message d'erreur.



Le modèle TCP/IP |


Le modèle TCP/IP (appelé aussi modèle Internet), qui date de 1976, a été stabilisé bien avant la publication du modèle OSI en 1984. Il présente aussi une approche modulaire (utilisation de couches) mais en contient uniquement quatre :


  1. Application

  2. Transport

  3. Internet

  4. Accès réseau

Aujourd'hui, c'est le modèle TCP/IP, plus souple, qui l'emporte sur le marché. Le modèle OSI, plus rigoureux, est principalement utilisé pour certaines applications critiques, ou pour ses fonctionnalités permettant de garantir une qualité de service.



Universalité du modèle abstrait OSI |


Le découpage en 7 couches du modèle OSI reste cependant apprécié par les ingénieurs réseau, car il organise les discussions et concepts en permettant d'étager les normes inhérentes aux services applicatifs. On trouve souvent une correspondance avec le modèle abstrait OSI, ce qui lui confère une véritable universalité. Ainsi le Web qui dessert mondialement tout internaute, et considéré comme le nec plus ultra des réseaux Internet (TCP/IP), est découpable comme suit:





























Couche
Norme
7
Application
Web
6
Présentation
HTML / XML
5
Session
HTTP / HTTPS
4
Transport
TCP
3
Réseau
IP
2
Liaison
Ethernet / xDSL
1
Physique
RJ45 / RJ11 / RJ12

Câbles Cat. 5 et +



Quelques protocoles |


7 Couche application


BGP • BitTorrent • CANopen • CLNP • DHCP • DNS • FTP • FTPS • FXP • Gopher • HTTP • HTTPS • IMAP • IPFS • IPP • IRC • IS-IS • LDAP • LMTP • Modbus • NFS • NNTP • NTP • OSPF • POP3 • RDP • RELP • RFB • RIP • RPC • RTP • RTSP • SFTP • SILC • SIMPLE • SIP • SMB • SMTP • SNMP • SOAP • SSH • STOMP • TACACS • TACACS+ • TCAP • Telnet • TFTP • VoIP • WebDAV • XCAP • XMPP • µTP • Web • WebSocket

6 Couche de présentation


AFP • ASCII • ASN.1 • HTML • NCP • SSP • TDI • TLS • Unicode • UUCP • Videotex • XDR • XML

5 Couche de session


AppleTalk • NetBios • RPC

4 Couche de transport


DCCP • SCTP • SPX • TCP • UDP

3 Couche de réseau


ARP • DHCP (en tant que service) • EIGRP • ICMP • IGMP • IP • Ipv4 • Ipv6 • IPX • NetBEUI • WDS

2 Couche de liaison de données


Anneau à jeton • ATM • BitNet • CAN • Ethernet • FDDI • Frame Relay • HDLC • LocalTalk • MPLS "2,5" • PPP • PPPoE • SPB • X.21 • X.25

1 Couche physique


1000BASE-T • 100BASE-TX • 10BASE-T • 10BASE2 • 10BASE5 • ADSL • Bluetooth • Câble coaxial • Codage Manchester • Codage Miller • Codage NRZ • CSMA/CA • CSMA/CD • DSSS • EIA-422 • EIA-485 • FHSS • HomeRF • IEEE 1394 (FireWire) • IrDA • Paire torsadée • PDH • RNIS • RS-232 • RS-449 • SDH • SDSL • SONET • T-carrier • Thunderbolt • USB • V.21-V.23 • V.42-V.90 • VDSL • Wi-Fi • Wireless USB


Liens externes |


.mw-parser-output .autres-projets ulmargin:0;padding:0.mw-parser-output .autres-projets lilist-style-type:none;list-style-image:none;margin:0.2em 0;text-indent:0;padding-left:24px;min-height:20px;text-align:left.mw-parser-output .autres-projets .titretext-align:center;margin:0.2em 0.mw-parser-output .autres-projets li afont-style:italic

Sur les autres projets Wikimedia :




  • (en) ISO : http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip Le texte de la norme, partie 1 seulement, en PDF compressé au format ZIP


  • (en) OSI : http://www.acm.org/sigs/sigcomm/standards/iso_stds/OSI_MODEL/ Texte brut extrait des parties 1 et 3 de la norme

  • Représentation du Protocole TCP/IP sur le modèle OSI

  • Introduction aux réseaux informatiques, modèle OSI et TCP/IP


Notes et références |



  1. a et b"D’une informatique centralisée aux réseaux généraux : le tournant des années 1970", par Valérie Schafer, historienne, le 10 février 2009 sur Interstices [1]


  2. Entretien avec Louis Pouzin, par Isabelle Bellin, sur Interstices [2]


  3. "Le réseau CYCLADES et Internet : quelles oportunités pour la France des années 1970 ?" Séminaire Haute Technologie du 14 mars 2007 du Comité d'histoire du Ministère des finances [3]


  4. .Interview de Charles Bachman sur "Oral History"


  5. "De Paul OTLET à INTERNET en passant par HYPERTEXTE" uhb.fr, septembre 1997


  6. "La France en réseaux (1960-1980)", par Valérie Schafer


  7. (en) « TCP/IP Internet Protocol »


  8. norme ISO 7498:1984


  9. "Des logiciels partagés aux licences échangées", sous la direction de : Camille Paloque-Berges et Christophe Masutti, dans "Histoires et cultures du Libre"


  10. X.200 itu.int


  11. Voir le document Liste de mnémoniques, section « Modèle OSI » sur Wikibooks.



  • Portail de l’informatique
  • Portail d’Internet
  • Portail des télécommunications



Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Modèle_OSI&oldid=161865006 ».













Menu de navigation



























(RLQ=window.RLQ||[]).push(function()mw.config.set("wgPageParseReport":"limitreport":"cputime":"0.336","walltime":"0.460","ppvisitednodes":"value":1993,"limit":1000000,"ppgeneratednodes":"value":0,"limit":1500000,"postexpandincludesize":"value":70869,"limit":2097152,"templateargumentsize":"value":22018,"limit":2097152,"expansiondepth":"value":12,"limit":40,"expensivefunctioncount":"value":1,"limit":500,"unstrip-depth":"value":0,"limit":20,"unstrip-size":"value":7186,"limit":5000000,"entityaccesscount":"value":1,"limit":400,"timingprofile":["100.00% 325.569 1 -total"," 27.37% 89.124 1 Modèle:Portail"," 19.47% 63.373 1 Modèle:Références"," 19.44% 63.288 13 Modèle:Lang"," 11.87% 38.631 1 Modèle:Catégorisation_badges"," 11.50% 37.431 1 Modèle:Lien_web"," 10.32% 33.598 1 Modèle:Palette"," 9.67% 31.467 1 Modèle:Autres_projets"," 7.83% 25.478 1 Modèle:Palette_Modèle_OSI"," 7.29% 23.731 1 Modèle:Suivi_des_biographies"],"scribunto":"limitreport-timeusage":"value":"0.087","limit":"10.000","limitreport-memusage":"value":3003012,"limit":52428800,"cachereport":"origin":"mw1256","timestamp":"20190817011358","ttl":2592000,"transientcontent":false););"@context":"https://schema.org","@type":"Article","name":"Modu00e8le OSI","url":"https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI","sameAs":"http://www.wikidata.org/entity/Q93312","mainEntity":"http://www.wikidata.org/entity/Q93312","author":"@type":"Organization","name":"Contributeurs aux projets de Wikimu00e9dia","publisher":"@type":"Organization","name":"Wikimedia Foundation, Inc.","logo":"@type":"ImageObject","url":"https://www.wikimedia.org/static/images/wmf-hor-googpub.png","datePublished":"2002-05-13T10:51:42Z","dateModified":"2019-08-16T10:18:07Z","image":"https://upload.wikimedia.org/wikipedia/commons/8/8d/OSI_Model_v1.svg","headline":"norme de communication, en ru00e9seau, de tous les systu00e8mes informatiques"(RLQ=window.RLQ||[]).push(function()mw.config.set("wgBackendResponseTime":115,"wgHostname":"mw1249"););

Popular posts from this blog

Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

199年 目錄 大件事 到箇年出世嗰人 到箇年死嗰人 節慶、風俗習慣 導覽選單