NDA: Article écrit en Mars 1995, publié dans ST Magazine n° 94 en Mai 95

Lorsque je vous invitais, il y a un an déjà, à prendre le train de l’Internet en marche, je ne m’attendais pas moi même à un développement aussi rapide en France. Le nombre de prestataires de services grand public (World-Net, FranceNet, Pressimage…) augmente tous les mois alors que les prix se font de plus en plus abordables. Les entreprises françaises sont de plus en plus connectées et tout le monde en parle: Internet est en passe de faire partie de notre vie quotidienne au même titre que le Minitel. Minitel, qui au passage, prend un sérieux coup de vieux!

LE PROTOCOLE DU FUTUR

Bien sûr, le réseau Internet n’est pas le seul. En France, un autre grand réseau est Transpac. Et puis, il y a les réseaux privés comme celui de CompuServe et ce “Marvel” [NDA: nom de code de ce qui deviendra MSN, avant que MSN ne passe à l’Internet…] que Microsoft déploie actuellement sur le monde entier. Finalement il y a les réseaux locaux des entreprises, institutions et universités. 

Tous ces réseaux ont la fâcheuse tendance à ne pas être compatibles entre eux. Il est impossible de relier directement l’un d’eux à un autre et de voir ainsi, une machine reliée au premier échanger des données avec une machine sur le second. La cause en est que le format des données et le protocole utilisé pour leur transmission est différent sur chaque réseau. Ce ne sont que quelques conventions, et pourtant chaque propriétaire de réseau se réserve jalousement l’exclusivité de son protocole… Bien évidemment, ça n’arrange rien à l’interconnexion de ces réseaux.

Pour palier au problème, on utilise des “gateways” entre les différents réseau. Ces machines traduisent les données dans un sens et dans l’autre. Les performances globales sont tout simplement affligeantes et la plupart du temps, les capacités de chaque réseau sont limitées par celles de l’autre.

Pourtant il existe une exception notoire: le protocole TCP/IP. Ce protocole peut être utilisé sur un réseau local (du plus simple reliant un ordinateur à une imprimante jusqu’au réseau d’entreprise à 5000 postes ou plus) mais également sur un réseau de grande envergure. De plus, ce protocole est libre d’utilisation, très bien documenté et livré en standard avec un certain nombre de machines en particulier tous les systèmes UNIX. Que demander de plus? C’est ainsi que des dizaines de milliers d’entreprises, d’universités et d’institutions sont équipées d’un réseau local fonctionnant sous TCP/IP. Et bien sûr, le protocole étant là pour ça, les universités et les institutions, suivies des entreprises ont relié leurs réseaux locaux entre eux. Depuis, le phénomène à fait boule de neige et l’agglomération de réseaux interconnectés à donné naissance à l’Internet.

Internet tire son nom de IP. En effet IP veut dire Internet Protocol. C’est grâce à IP que n’importe quel ordinateur dans le monde peut être identifié par une adresse unique. Chaque ordinateur peut ainsi échanger des données avec précisément n’importe quel autre ordinateur qui l’intéresse, pour peu qu’il soit relié au réseau.

Vous l’avez sans doute compris, toute personne créant un réseau local doit dorénavant sérieusement considérer l’adoption de TCP/IP afin de pouvoir se relier facilement au monde extérieur dès que le besoin s’en fait sentir (si ce besoin n’est pas déjà omniprésent!) Exit donc les protocoles propriétaires tels que ceux de Novell, Lantastic, IBM ou Microsoft [NDA: d’ailleurs, cinq ans plus tard, on en entendra effectivement plus parler!]. TCP/IP est la norme de fait. [NDA: ça parait tellement évident aujourd’hui! :)]

Ne pensez pas non plus y échapper. Il est proche, le temps où vous aurez plusieurs ordinateurs à la maison, le temps ou la télévision par câble diffusera des programmes informatiques, le temps ou votre ordinateur servira de visiophone, le temps ou votre immeuble sera construit pré-cablé et directement relié à Internet. Tout cela existe déjà mais n’est pas encore très répandu et généralement légèrement hors de prix. Ceci dit, comment croyez vous que tout cela va communiquer? Il devient important qu’il soit aussi facile de relier des ordinateurs en réseau que de brancher des appareils électriques sur le 220V. Eh bien si le 220V / 50 Hz est la norme électrique, TCP/IP sera très probablement la norme de réseau.

Dans l’immédiat, si vous utilisez un réseau local comme ITOS présenté dans le numéro 93 ou encore si vous vous connectez sur Internet par modem, c’est déjà TCP/IP qui régit les informations qui y transitent. Nous mettrons cela en pratique dès le mois prochain…

TCP/IP, MAIS ENCORE?

TCP/IP est en fait couramment (mais abusivement) utilisé pour désigner l’ensemble des protocoles de l’Internet. Eh oui, non seulement IP ne fait pas le boulot tout seul et se fait aider par TCP (Transmission Control Protocol) mais TCP lui même ne servirait à rien s’il n’y avait pas encore d’autres protocoles plus évolués qui effectuaient des tâches utiles. Parmi ces protocoles il y a SMTP (Simple Mail Transfer Protocol), NNTP (Net News Transfer Protocol), FTP (File Transfer Protocol), etc… Ensuite il y a aussi des protocoles qui adressent IP sans passer par TCP. Exemple: NFS (Network File System). Bref, il y a la une belle soupe d’acronymes que nous allons tenter d’éclaircir.

Le principe clef que vous devez saisir est l’architecture par couches. Prenons un exemple d’architecture par couches plus proche de nous: lorsqu’un programme affiche une boîte de dialogue GEM sur l’écran de votre Atari, il se passe beaucoup de choses avant d’avoir le résultat escompté. (Heureusement, le microprocesseur sait exécuter toutes ces choses assez vite pour ne pas que ça se voie!) En effet, un programme affichant une boite de dialogue sur l’écran va demander à la couche AES du système d’exploitation (le TOS) de s’en charger. L’AES se charge de dessiner un a un chaque élément de la boite de dialogue: un rectangle ici, un texte là, etc… mais l’AES ne sachant pas lui même faire les dessins, il demande à la couche VDI du TOS. Le VDI s’occupe lui de dessiner la boite ou les lettres composant un texte. Mais pour ce faire, le VDI peut par exemple avoir besoin de savoir quelle est la résolution courante et si telle ou telle couleur est disponible, il peut aussi avoir besoin de cacher temporairement la souris pour ne pas faire de bavures à l’écran. Ces choses là, c’est pas le boulot du VDI, c’est pourquoi il demande aux couches BIOS et XBIOS de s’en charger. En gros, ça s’arrête là, le BIOS est la couche de plus bas niveau (celle qui fait les trucs les moins évolués) du TOS.

Dans le cas d’un accès à un fichier par contre, le programme fera appel à la couche GEMDOS qui décomposera le travail en tâche élémentaires qu’elle chargera le BIOS d’exécuter. On voit ici que deux services différents (affichage d’une boîte de dialogue et opération de fichier) sont gérés par des couches indépendantes du système d’exploitation mais qu’en fin de compte ces couches finissent par faire appel à une couche de base: le BIOS.

En ce qui concerne les protocoles de l’Internet, la situation est très similaire: la couche de plus bas niveau est IP. Les autres couches lui donnent un bloc de données binaires et une adresse IP de destination, par exemple 194.2.145.155: il en résulte un paquet de données. Tout ce que sait faire IP est d’acheminer ce paquet vers la machine de destination. Sachant que cette machine de destination peut se trouver n’importe où dans le monde et que IP y arrive à tous les coups (sauf très gros problème), c’est déjà pas mal!

Au dessus de IP, il y a principalement TCP. TCP reçoit des données d’une autre couche encore plus évoluée. TCP découpe ces données en paquets et les transmet à IP. IP les achemine vers la machine destination ou un autre IP les reçoit et les passe à la couche TCP de la machine de destination. Celle-ci remet les paquets dans l’ordre (eh oui, ils peuvent prendre des chemins différents sur Internet) et vérifie que les données n’ont pas subi d’erreurs durant la transmission puis les transmet à la couche de niveau supérieur appropriée (selon la nature des données).

Parallèlement à TCP, il existe d’autres protocoles comme UDP par exemple. Ils sont utilisés par exemple lorsqu’on a pas besoin de numéroter les paquets pour les remettre dans l’ordre, ce qui économise de la place.

A ce moment se pose la question suivante: qui envoie des données à TCP? (ou UDP, mais on va se limiter à TCP pour l’instant hein!) Eh bien, là, il y a un certain nombre de possibilités, selon ce qu’on veut transmettre. On veut transmettre des fichiers? On fait appel à FTP (File Transfer Protocol). On veut transmettre du courrier électronique (e-mail)? On fait appel à SMTP (Simple Mail T.P.). Des news: NNTP (Net News T. P.). Pour les connexions interactives, le protocole est telnet (tiens, en voilà un qui ne se finit pas par TP!)

Et finalement… qui envoie des fichiers à FTP? des messages à SMTP? des news à NNTP? et des commandes ou des écrans d’informations à telnet? Eh bien, c’est un programme d’application. Par exemple il existe sur Mac un programme qui s’appelle Fetch et qui après avoir laissé l’utilisateur choisir le fichier qui l’intéresse sur la machine qui l’intéresse (parmi tous les serveurs FTP du monde), se charge de recevoir le fichier que lui ramène le protocole FTP et de le sauver sur le disque dur local. J’ai pris cet exemple sur Mac parce que sur ATARI, tous les programmes de type fetch s’appellent FTP exactement comme le protocole FTP ce qui embrouille un peu, avouez-le. Ceci dit, ça reste cohérent.

Ouf, voilà déjà les principaux protocoles d’explicités. Il en existe encore beaucoup d’autres servant à synchroniser les horloges des ordinateurs, imprimer des fichiers à distance, partager des disques durs, obtenir l’adresse IP d’une machine en fonction de son nom en lettres (DNS), exécuter des programmes à distance, ouvrir les fenêtres d’un programme sur un autre écran que celui de l’ordinateur sur lequel il s’exécute (un certain X-Windows)… bref, il y en a facilement plus d’une centaine, mais l’essentiel se trouve ci-dessus.

Vous trouverez quelque part sur ces pages un schéma récapitulant les différentes couches du TOS d’une part et de l’Internet d’autre part. Toutes les couches qui se touchent s’échangent des données entre elles. Tant que nous sommes dans cette analogie: toutes les couches du TOS sont déjà en mémoire dans votre ATARI… à l’exception de GDOS ou SpeedoGDOS qui peut être chargé en option. Pour les protocoles de l’Internet, contrairement à UNIX, le TOS n’intègre aucune des couches nécessaires. Tout est en option, ou plutôt, il faudra charger un ou plusieurs programmes implémentant ces couches en mémoire avant de pouvoir espérer communiquer. Un exemple est KA9Q-NOS.PRG: ce programme comprend tous les protocoles et toutes les applications dont il a besoin, c’est à dire qu’il inclue aussi bien IP que TCP que FTP que l’équivalent de Fetch sur Mac. C’est un peu comme Script qui intègre son propre gestionnaire d’imprimante - grosso modo, son propre GDOS.

LA COUCHE ULTIME: SLIP (ou PPP)

Détrompez-vous, ce paragraphe n’a rien à voir avec la lingerie. En fait, nous devons mentionner ici les problèmes posés par l’utilisation de différents médias de transmission des paquets générés par IP. En effet, il existe une multitude de possibilités pour relier physiquement les ordinateurs d’un réseau. Nous ne les citerons pas toutes mais voici quelques exemples: pour un réseau local de quelques dizaines de postes, on choisira des câbles coaxiaux fins - on dit aussi Ethernet 10 Base 2 - le débit est alors de 10 Mbits par seconde. Pour un gros réseau d’entreprise, on prendra du coaxial mais la taille au dessus ou des paires torsadées munies de prises RJ45 (10-Base-T). Finalement pour relier les réseaux locaux entre eux, rien ne vaut une bonne fibre optique pour atteindre quelques Gigabits par seconde. Pour traverser les océans, on peut bien sûr utiliser des satellites. Et nous dans tout ça… eh bien nous relions notre Atari au réseau par une simple ligne téléphonique en utilisant un modem.

Chaque média physique a ses propres caractéristiques et IP ne saurait toutes les prendre en compte. Une différence fondamentale est par exemple que dans le cas où vous utilisez une ligne téléphonique: d’un côté il y a votre Atari et de l’autre côté, il y a un autre ordinateur. Basta. Il n’y a personne d’autre sur ce media. Il s’agit là d’une liaison série - on peut aussi dire une liaison point à point. Par contre, dans le cas d’un réseau local sur câble coaxial: on peut " greffer " des dizaines d’ordinateurs sur le même câble coaxial. Bonjour l’embrouille s’ils se mettent tous à “parler” en même temps!

Dans le premier cas, on utilisera donc un petit protocole très simple: SLIP comme Serial Line Internet Protocol ou PPP comme Point to Point Protocol, les deux étant plus ou moins équivalents mais PPP étant mieux adapté lors d’une utilisation avec un modem. Dans le deuxième cas, on utilisera des protocoles autrement plus complexes: les protocoles Ethernet (si vous voulez vous faire mousser, prononcez iivernett à l’américaine!)

Vous connaissez maintenant tous les protocoles qui entrent en jeu lors d’un transfert de fichier d’un bout à l’autre du monde. Reportez vous au schéma pour un petit exemple illustré… Bien sûr l’exemple est très simple et les données n’y passent que par deux routeurs (ou gateways si vous préférez) intermédiaires. Typiquement, le nombre de routeurs traversés lorsqu’on communique sur Internet sera d’une vingtaine.

Transfert de fichier couche par couche, routeur par routeur…

SOCKETS

Nous allons maintenant aborder un dernier point extrêmement important. En effet, les machines reliées à un réseau ne se contentent que très rarement de communiquer avec un seul correspondant à la fois. Même votre Atari relié par modem au net peut communiquer avec plusieurs autres machines simultanément: un ftp aux Etats-Unis, un autre en Finlande, la consultation des news sur un serveur à Paris et un petit telnet à Amsterdam. Les 4 correspondants vont renvoyer des paquets IP à votre Atari. C’est bien. IP va les transmettre à TCP. Jusque là, pas de problème. Mais après, comment la couche TCP de votre ATARI va-t-elle savoir à quel protocole envoyer chaque paquet: FTP, NNTP, Telnet? Et a son tour, comment la couche FTP sait-elle quelle connexion ftp (EU ou Finlande) est concernée?

Pour différencier les connexion simultanées, TCP ajoute un numéro de port (port number ou socket number) à chaque paquet qu’il émet. A la réception de tels paquets, il peut ainsi déterminer de quelle connexions il s’agit. Votre connexion ftp aux E.U. pourra par exemple se voir attribuer le numéro 50 000 et celle en Finlande le numéro 50 001. Le telnet aura par exemple le numéro 50 005.

Lorsque votre ATARI reçoit donc des paquets ayant pour numéro de destination 50 001, il saura qu’ils concernent la connexion FTP avec le serveur en Finlande. Mais pour établir la connexion avec ce serveur, comment fait votre ATARI pour envoyer le premier paquet? Il connaît l’adresse du serveur ftp par exemple 128.214.6. 100 pour nic.funet.fi mais quel numéro de port demander?

En fait, il existe des numéros prédéfinis appelés “well known sockets” qui permettent d’établir des connexion avec tous les services génériques. Pour appeler un serveur FTP, il suffit ainsi de demander le socket 21. [NDA: la liste des Well Known Port Numbers(comme il faut désormais les appeler) est maintenue à jour par l’IANA.]

Parfois, on veut faire appel à un service non standardisé. Il n’y a alors pas de “well known socket” et c’est a nous de le préciser. Pour demander l’établissement d’une connexion telnet avec un serveur répondant au socket 3000 on tapera par exemple telnet madlab.sprl.umich.edu 3000. 

En résumé chaque connexion “virtuelle” entre deux machines sur l’Internet est identifié par 4 informations: 

  • l’adresse IP de la machine source, 
  • l’adresse IP de la machine destination, 
  • le port utilisé sur la machine source 
  • le port utilisé sur la machine destination. 

Si vous lancez deux sessions FTP connectées toutes deux au même serveur FTP, les deux adresses source seront identiques (l’adresse IP de votre ATARI), les deux adresses destination seront identiques (l’adresse de la machine hébergeant le serveur FTP), les deux ports destination seront identiques (21 pour le serveur FTP) et seul les numéros de port source seront différents, par exemple 50 000 et 50 002. Notez que 50 000 et 50 002 ne sont pas des “well known sockets” mais cela n’a aucune importance puisque personne ne cherchera jamais à entrer en contact avec vos clients FTP mis à part le serveur FTP demandé, mais lui il sait à qui s’adresser, puisque le socket source est indiqué dans le paquet de demande de connexion!

EN PRATIQUE

Le mois prochain nous mettrons en pratique très précisément les notions vues ci-dessus. En effet, nous utiliserons KA9Q-NOS -fourni sur la disquette du mois prochain- pour nous connecter à l’Internet par modem. Nous pourrons alors utiliser ces protocoles sans trop nous en soucier pour accomplir des tâches utiles comme des transfert de fichiers, mais nous pourrons aussi - et c’est le but de cette initiation - examiner en temps réel quelle est l’activité des différentes couches de protocole au cours de la communication.

Comments from long ago:

Comment from: assissila

c est un un bon cour de reseau mai je cherche de cours plus details qui prend les protocoles de reseau

2009-09-11 18-00

Comment from: Moussa kre Mahamat Kachallah

ce vrmnt genial
mrci bocup

2012-07-03 02-56