L’émergence de l’Internet public

Histoire d’une naissance

Comme cela a été précisé dans ce livre avec le chapitre Les réseaux dédiés au transport de données, les sociétés désirant échanger des données utilisaient des systèmes, des machines et des langages issus de fabricants et concepteurs différents, ce qui limitait bien souvent la communication au périmètre restreint à un site pour le moins ou plusieurs sites mais dépendant d’un même client. Avec X.25 et ATM l’interconnexion était devenue possible via le développement en parallèle avec des réseaux somme toute toujours différents.

Le partage d’informations, autrement que par courrier ou conférences, entre les différentes organisations liées à la recherche scientifique n’étaient pas non plus encore imaginé ou à l’ordre du jour, de même que la possibilité de créer des "banques" de données pouvant accueillir et sauvegarder des informations communes ou particulières. Délai des échanges et partage des données n’allaient pas dans le sens d’un développement rapide de la connaissance.

Le premier organisme gouvernemental qui s’intéressa aux interconnexions fut le Département de la Défense américain...

Les organismes normalisateurs de l’Internet

L’ISOC (Internet Society) est l’organisme non gouvernemental fédérateur de tous les aspects liés à la standardisation, le pendant de l’UIT en quelque sorte et à la distribution des adresses d’accès à Internet. Le système d’adressage étant complètement différent de ce qui a été vu jusqu’à présent avec le monde de la téléphonie historique. Cette organisation dirigée par l’IAB (Internet Architecture Board) chapeaute :

L’évolution vers la commercialisation

Les fournisseurs d’accès Internet, FAI (ou ISP - Internet Service Provider en anglais) dont la tâche est "relativement simple", il suffit de posséder un, plusieurs équipements de type routeurs de services capables d’analyser l’adresse de l’utilisateur demandeur, pour en vérifier les droits d’accès ce qui est un minimum si l’on veut que cela rapporte quelque chose et l’adresse demandée pour pouvoir diriger les requêtes d’accès. L’abonnement payé par l’usager garantit a priori l’accès au backbone Internet. Les FAI passent en général des accords mutuels d’interconnexion de et vers leurs propres abonnés. De plus, ceux-ci fournissent souvent des services de messagerie électronique, de stockage de données, voire pour certains la distribution de chaînes de télévision.

Les fournisseurs de contenu qui, comme leur dénomination l’indique, possèdent des bases de données plus ou moins spécialisées dans un domaine d’activité scientifique ou autre auxquelles les usagers de l’Internet veulent accéder en utilisant le "browser" (navigateur) installé sur leur ordinateur. Ces requêtes bien connues aujourd’hui utilisent un protocole d’application...

Qu’est-ce qu’IP ?

Tout d’abord c’est un protocole de routage, c’est-à-dire qu’il est chargé, à partir d’un système d’adressage particulier assigné à chaque hôte d’un réseau, de fournir à certains systèmes intermédiaires de ce réseau, les routeurs IP (comme cela a été illustré dans la figure explicitant le modèle en pile de protocoles), le moyen d’aiguiller les paquets de données que ce protocole IP aura lui-même formés, d’un hôte origine à un hôte destinataire.

Ces routeurs IP disposent de tables de routage, équivalentes au traducteur des commutateurs du RTC. Ces tables peuvent être constituées manuellement à l’initiative du configurateur de réseau ou dynamiquement par l’usage de protocoles particuliers réservés aux organes de type routeur leur permettant de "découvrir" leur environnement d’adressage IP et de s’échanger leurs informations de routage. Ces protocoles ne seront pas étudiés mais au mieux évoqués dans cet ouvrage.

TCP : un protocole sécurisant

Un petit rappel sur la position de la couche de transport, donc de TCP dans le modèle OSI :

La couche "Transport" se situe entre "Applications" (incluant les couches 5 à 7 OSI) et couche de "Réseau" (X.25 ou IP dans ce livre) et dialogue directement d’hôte émetteur à hôte récepteur, les équipements intermédiaires tels que routeurs et/ou commutateurs de paquets n’ont aucun regard sur cette couche et donc sur les informations de transport apportées par TCP.

Dans le modèle en pile TCP/IP, TCP offre un service de transport en mode "connecté", c’est-à-dire qu’avant de faire passer des données après l’encapsulation vers la couche réseau, TCP, comme X.25 s’assurera de la possibilité d’un dialogue avec la couche TCP correspondante de l’hôte destinataire. Le dialogue TCP est basé sur une relation de type client/serveur, c’est-à-dire qu’un client (l’émetteur d’une requête) attend une réponse d’un serveur. Le client est toujours l’hôte à l’initiative d’une demande d’ouverture de dialogue pair à pair. Bien sûr la plupart des hôtes sont à la fois client et serveur en fonction du dialogue, notamment bidirectionnel, à organiser.

1. Établissement du dialogue

Cette phase d’établissement de dialogue porte le nom de procédure "Three-way Handshake" (poignée de mains à trois phases) et se déroule en trois temps comme le montre l’ordinogramme suivant :

Connect request : demande de connexion.

Connect indication : indication de demande de connexion.

Connect response : réponse positive à la demande de connexion.

Connect confirmation : confirmation de l’acceptation de la demande de connexion.

Seq x : numéro de séquence x (valorisé par la couche TCP de l’émetteur).

Seq y : numéro de séquence y (valorisé par la couche TCP du destinataire de la requête).

ACK (x + 1) : accusé de réception de la séquence x et "prêt à recevoir la séquence x+1.

ACK (y + 1) : accusé de réception de la séquence...