La couche protocoles du réseau

La couche 3 contient les protocoles, qui rendent le réseau utilisable. Au fil des ans, IPX/SPX, SNA, et TCP/IP ont été les protocoles utilisés sur OS/400, i5/OS, ou IBM i. IPX/SPX a été le protocole des réseaux Novel pendant des années et, bien qu’il y soit encore

supporté, il a été le dernier à être ajouté et le premier à être supprimé de l’OS/400. IPX n’a été supporté que pendant quelques releases. SNA a été supporté dès le début et, bien que le support SNA natif soit limité à des adaptateurs réseau de 100 Mb/s et plus lents (qui ne sont plus commercialisés), SNA continue à être pris en charge dans l’IBM i aujourd’hui. Cependant, c’est le protocole réseau TCP/IP qui s’impose.

TCP/IP occupe les couches 3, 4 et 5 du modèle de réseau OSI. Les couches 6 et 7 (présentation et application) contiennent des choses que nous associons couramment avec TCP/IP, comme FTP, HTTP et Telnet, mais elles ne font pas partie du protocole : elles ne comptent sur lui que pour fonctionner.

Par manque de place, nous n’expliquerons pas entièrement les réseaux IP, nous nous contenterons de couvrir quelques éléments de base. Dans le réseau TCP/IP, l’adresse est toujours accouplée avec un masque subnet. Chaque hôte d’un réseau IP a une adresse écrite sous la forme de quatre chiffres décimaux allant de 0 à 255 et séparés par un point ; comme 192.168.0.1. Il faut savoir que les masques et adresses subnet, bien qu’écrits en nombres décimaux, sont en réalité binaires. Le nombre décimal maximum de 255 représente huit bits binaires tous mis à 1 et avec quatre nombres (appelés octets), vous voyez donc rapidement qu’il y a un total de 32 bits dans l’adresse. Le masque subnet est de même longueur. Le masque subnet sépare les bits dans l’adresse qui représentent le numéro du réseau et ceux qui représentent le numéro de l’hôte. Écrivez l’adresse réseau et le masque subnet en binaire l’un au-dessus de l’autre. Tous les bits d’adresse qui correspondent aux 1 dans le masque subnet représentent le numéro du réseau, et ceux qui correspondent aux 0 sont la portion hôte de l’adresse.

Confusion terminologique ? Quand un réseau n’en est-il pas un ? Dans l’univers physique, nous pourrions considérer qu’un réseau Ethernet est un réseau, tout comme un réseau sans-fil. Nous aurions raison pour les deux. Avec un réseau TCP/IP, Ethernet et le sans-fil peuvent tous deux faire partie du même réseau, mais aussi être des réseaux différents, selon le mode d’attribution des adresses.

Dans le cas d’un réseau TCP/IP, la seule vraie différence est de savoir si deux hôtes peuvent communiquer directement ou s’ils doivent emprunter un routeur (ou passerelle). Nous avons déjà parlé des trames Ethernet. Vous vous rappelez sûrement qu’elles contiennent des données. Les données ne sont pas spécifiques à un protocole, et, pour la couche Ethernet, c’est juste des données. Et donc vous devez les ouvrir pour savoir ce qu’il y a à l’intérieur. N’avons-nous pas dit que chaque carte Ethernet n’a qu’une adresse MAC, pas une adresse Ethernet ? Mais alors comment un hôte TCP/IP sait-il de quelle manière envoyer des données à un hôte TCP/IP ?

La table ARP. L’hôte à l’adresse 192.168.1.1 veut communiquer avec l’hôte à l’adresse 192.168.1.2. TCP/IP envoie une requête spéciale connue sous le nom d’ARP (Address Resolution Protocol) à tous les participants du réseau (une requête broadcast). La requête demande à tous ceux qui ont l’adresse 192.168.1.2 de répondre. Dans la trame de réponse, l’adresse MAC de l’envoyeur est incluse, et cette adresse MAC et l’adresse IP sont désormais placées dans la table ARP de l’hôte. Quand l’hôte 192.168.1.1 transmet des données à l’adresse 192.168.1.2, il place les données IP à l’intérieur de la trame Ethernet et les adresses pour l’adresse MAC qui correspond à l’adresse IP 192.168.1.2 et les envoie. Sur le réseau physique, personne ne peut dire que la trame contient TCP/IP, et peu importe, parce que l’hôte de destination ouvre la trame et lit les données, puis les transmet à la couche 3 et à TCP/IP. Mais que se passe-t-il quant l’hôte 192.168.1.1 a besoin de communiquer avec l’hôte à 10.1.1.1 ?

Passerelles et routes. Quand TCP/IP détermine que la destination d’un paquet n’est pas sur le réseau IP local, il explore la table de routage locale pour décider la marche à suivre. La table de routage peut contenir trois types de routes. Le premier type est celui des routes hôtes. Ces routes sont les plus spécifiques parce qu’elles ordonnent à IP d’envoyer les données pour des hôtes spécifiques au travers d’une passerelle précise. TCP/IP considère ces routes en premier ; s’il ne trouve pas de correspondance, d’autres routes sont considérées. Le deuxième type est celui des routes réseau. Ces routes indiquent que tous les réseaux ou tous les groupes de réseaux peuvent être atteints par l’intermédiaire d’une certaine passerelle. TCP/IP considère ces routes comme secondaires. Enfin, il y a les routes par défaut, parfois appelées passerelles en dernier ressort. Tous les paquets dans lesquels la destination ne correspond pas à une route hôte ou réseau sont transmis à la passerelle par défaut. Celle-ci utilise ensuite ses tables de routage pour retransmettre les données à la prochaine passerelle jusqu’à ce qu’elles parviennent à destination.

Livraison des données. Des mécanismes intégrés dans TCP/IP assurent la bonne destination des données, mais certains mécanismes ne sont pas toujours utilisés – par exemple, l’accusé de réception. Quand des données sont transmises par le protocole TCP, celui-ci répètera les données si aucun accusé de réception n’est reçu. S’il y a trop de retentatives, la connexion est terminée et une erreur est envoyée. Vous avez probablement vu cela quand votre session 5250 vers l’IBM i échoue. C’est vrai, il est important que, par exemple, des écrans 5250 arrivent à destination, complets et d’un seul tenant.

Données non livrées. Dans des paquets UDP (User Datagram Protocol), les données sont envoyées sans accusé de réception. UDP est souvent utilisé quand les données font partie d’un flux vocal comme la radio Internet. Si un petit nombre de paquets ne parviennent pas à destination, votre cerveau complète les syllabes ou notes manquantes. Si le réseau devait retransmettre ces paquets ratés, ils arriveraient dans le flux audio hors séquence et seraient discordants.

Données perdues. Si des erreurs dans les tables de routage provoquent des boucles sur le réseau ou si les réseaux sont mal configurés, les données devront peut-être franchir trop de tronçons. TCP/IP protège aussi contre cette anomalie. L’en-tête de paquet IP contient un compteur TTL (Time to Live) qui démarre à 32. Chaque fois qu’un routeur le touche, le compteur est décrémenté. Si le TTL est décrémenté jusqu’à zéro, le paquet est abandonné pour empêcher le bouclage infini des données et l’engorgement des réseaux.

Numéros d’adresses IP. Certains d’entre nous mémorisent trop d’adresses IP, pourtant rien ne nous y oblige. Le Domain Name System, ou DNS, nous permet d’utiliser des noms dont l’ordinateur tirera l’adresse IP. Si vous tapez www.ibm.com [2] dans votre navigateur, il reconnaît que cette adresse n’est pas une adresse IP valide et l’envoie au serveur DNS. (Considérez DNS comme un répertoire téléphonique sur Internet.) DNS renvoie l’adresse IP au navigateur, puis celui-ci envoie la requête à l’adresse et attend une réponse. Sur une page très active, cette opération peut survenir des dizaines de fois pour tous les petits éléments, et la situation empire en présence de publicités et d’écrans spontanés.

Techniquement parlant, DNS ne fait pas partie de votre réseau physique, mais c’est un composant critique du réseau TCP/IP. Il est donc important que les serveurs DNS soient rapides et efficaces.