Un câble, d'un côté quelqu'un qui envoit du courant par intermittence, de l'autre quelqu'un qui regarde quand il y a du courant. C'est le principe du télégraphe, avec le code Morse. Et ça s'adapte vraiment parfaitement aux ordinateurs. Les ordinateurs peuvent même faire mieux : ils ont des métronomes (dans le domaine informatique on parle d'horloges) qui battent très précisément la mesure ; à chaque tic, ils peuvent envoyer ou pas le courant, ça fait un bit d'information à chaque fois.
Nous ne rentrerons pas dans les détails de la réalisatoin physique : ça peut aller d'une bête paire de fils sur à peine plus d'un mètre à un faisceau de fibres optiques, en passant par un câble coaxial. Ça peut également être des ondes radio, ou bien le fait de dire ou de ne pas dire bip sur une ligne téléphonique. Bref, il y a plein de manières pour deux ordinateurs de se dire 0 ou 1.
Ça, c'est bien pour relier deux ordinateurs. Mais comment faire s'il y en a plusieurs ? Tirer un câble entre chaque paire n'est pas envisageable. La solution la moins coûteuse, et donc celle qui a été rapidement préférée, est d'utiliser un seul câble qui connecte tous les ordinateurs. Quand un ordinateur veut parler, il parle à tous les autres, et il faut inventer des moyens pour que deux ne parlent pas en même temps. Le système de ce genre le plus répandu consiste en un câble coaxial où tous les ordinateurs sont branchés en sérié ; plus récemment on a adopté une structure en étoile autour d'un appareil bon marché appelé hub, plus efficace et plus robuste que la structure en série.
Plusieurs ordinateurs, c'est bien, mais relier beaucoup d'ordinateur, c'est mieux. La technologie des câbles impose des limites de longueur, et il est rarement possible de relier directement un câble coaxial de réseau domestique à un faisceau de fibres optiques transatlantique. La solution consiste alors à avoir une machine branchée sur les deux (ou plus) réseaux, avec pour tâche de faire suivre l'information de l'un à l'autre ; quand un ordinateur d'un réseau veut parler à un ordinateur de l'autre réseau, il adresse son message à cette machine, avec une étiquette indiquant le destinataire. On appelle une telle machine un routeur.
Pour les réseaux locaux (les LAN quand on veut faire moderne), la technologie employée est ethernet. Elle fonctionne soit avec un câble coaxial en série, soit avec un câble simple (à huit fils dont peu sont vraiment utilisés) organisé en étoile autour d'un hub. Avec ethernet, les données sont envoyées par blocs appelés trames qui font au plus environ 1,5 ko. Il n'y a pas de système pour s'assurer a priori que deux ordinateurs sur le câble ne parlent pas en même temps : la détection se fait a posteriori par le fait que le signal est alors incompréhensible ; les deux ordinateurs réémettent alors après un délai aléatoire, qui sera probablement différent ; en pratique, ce système marche plutôt bien.
Au début de chaque trame ethernet, ou trouve ce qu'on appelle un
entête : quelques octets réservés par le protocole ethernet
lui-même pour son fonctionnement interne. Toutes les cartes réseau ethernet
possèdent une adresse
MAC depuis l'usine (mais
les cartes modernes permettent de la changer), qui est code unique de six
octets. Par exemple sas.eleves a pour adresse MAC
52:54:00:62:1b:66. Dans l'entête ethernet, on trouve l'adresse
MAC de l'ordinateur auquel la trame est adressée (ainsi que celle de
l'ordinateur qui envoit). En temps normal, le filtrage se fait directement
au niveau de la carte réseau, de sorte que parmi les ordinateurs sur un même
câble, seul celui qui est concerné voit effectivement un message.
Dans l'entête ethernet, on trouve également un numéro de protocole. C'est un petit nombre, sur deux octets, qui décrit très brièvement ce qu'on prévoit de faire avec les données de la trame. L'IANA tient à jour une table des numéros ethernet attribués. Ainsi, le système d'exploitation de l'ordinateur qui a reçu la trame peut immédiatement appeler le bon sous-système, ou ignorer la trame s'il ne sait pas quoi en faire. Pour illustrer, quand on utilise ethernet pour faire passer de l'« Internet », le numéro est 513. Ce mécanisme de numéros décrivant le genre d'utilisation d'un système est très général, et on le retrouve à tous les niveaux des protocoles Internet.
Quand on utilise une ligne téléphonique, le protocole employé est le Point to Point (PPP). Il a des mécanismes différents parce qu'il ne relie que deux ordinateurs, mais sous des contraintes différentes (ligne moins fiable et temps de latence supérieur).
Mettez une lettre à la poste. Si le destinataire habite dans la même ville, elle lui sera distribuée directement. S'il habite dans une ville voisine, le facteur transmet la lettre à son collègue de cette ville. S'il habite plus loin, le facteur transmettra la lettre au centre de tri dont il dépend. Et à son tour, le centre de tri va faire suivre la lettre à qui de droit. La lettre va donc passer par différentes étapes où elle sera redirigée en fonction de l'adresse qui est écrite dessus.
Les réseaux informatiques, dès qu'ils dépassent les quelques dizaines de machines qu'on peut brancher sur un même câble, fonctionnent de la même manière : les données sont découpées en paquets, qui jouent le rôle de notre enveloppe. Quand il n'est pas possible de transmettre le paquet directement à son destinataire, il est transmis à un ordinateur (défini dans la configuration du réseau) appelé routeur. Cet ordinateur est censé être capable de faire suivre le paquet ; ça suppose par exemple qu'il est relié par un autre câble à un autre réseau.
Pour pouvoir marcher, ce système a besoin que les ordinateurs soient dotés d'une adresse qui reflète leur position dans le réseau global. L'adresse MAC ne convient pas pour cette tâche, d'une part parce que elle est (plus ou moins) immuable et ne correspond en rien à la position sur le réseau (un portable qu'on débranche d'un endroit et rebranche a un autre ne change pas d'adresse MAC), et d'autre part parce qu'on souhaite que ça fonctionne avec différents types de connexion (les modems pour les connexions PPP, par exemple, n'ont pas d'adresse MAC). On invente alors un nouveau système d'adresses, indépendant du protocole utilisé pour connecter les ordinateurs.
Ce qui fait Internet, c'est IP (et l'on découvre que le titre de cette section est un pléonasme). Ce protocole décrit la structure des adresses utilisée, la manière d'écrire ces adresses dans les paquets, et les moyens d'assurer leur bonne circulation.
Nous utilisons actuellement la version 4 d'IP, ce qu'on indique parfois par IPv4. Dans cette version, les adresses sont constituées de 32 chiffres binaires (bits), ce qu'on écrit généralement sous la forme de quatre nombres entre 0 et 255. Par exemple, l'adresse IP de sas.eleves est 129.199.129.11. Une nouvelle version d'IP, IPv6, est progressivement mis en place ; les adresses y font 128 bits, et sont écrites en hexadécimal ; l'ENS n'est pas reliée en IPv6, mais si vous voulez un exemple, 2001:660:3001:4002:2C0:4FFF:FE4E:41D3 est l'adresse IPv6 du serveur web de Renater.
Tout ordinateur relié à Internet possède (au moins) une adresse IP, et il est le seul à la posséder (dans Internet). Ces adresses sont structurées en réseaux et sous-réseaux, en fixant les chiffres de gauche à droite. Ainsi, toutes les adresses en 129.199.x.y sont dans l'ENS, et celles en 129.199.129.y sont plus particulièrement dans la salle S. De l'extérieur, quelqu'un qui veut envoyer un paquet à 129.199.129.1 a seulement à savoir qu'il doit l'envoyer à l'ENS. C'est ensuite à nos routeurs de finir le travail.
Les paquets IP comportent tous l'adresse IP de l'expéditeur, celle du destinataire, une somme de contrôle qui permet de vérifier qu'il est intact, et un numéro de protocole indiquant à quoi va servir ce paquet. Ils comportent également un compteur qui limite le nombre de routeurs par lequel il peut passer (de manière à ce qu'un paquet perdu ne reste pas éternellement à circuler entre des routeurs mal configurés), ainsi que quelques autres options. Un des principes d'Internet, c'est que les routeurs font le strict minimum : ils doivent se contenter de faire suivre les paquets sans les altérer (sauf le compteur ; si un paquet a atteint la limite, le routeur l'arrête et envoit un paquet à l'expéditeur pour signaler l'erreur). Un des autres principes est que tous les ordinateurs sont égaux : du point de vue du protocole, rien ne distingue le super ordinateur central de la NASA de votre petit PC personnel ; en particulier, rien ne distingue un serveur d'un poste client.
IP est conçu sur un principe de best effort (meilleur effort) : les infrastructures (les routeurs) font leur possible pour faire parvenir vos paquets, mais sans aucune garantie. Un paquet peut disparaître sans laisser de trace, ou bien se perdre au mauvais endroit (mais il n'ira en général pas bien loin), ou encore être retardé et arriver après un paquet pourtant parti plus tard. Il arrive même qu'un paquet arrive en plusieurs exemplaires. Bien sûr, en général, les paquets arrivent bien, et dans l'ordre. Ce principe du meilleur effort a l'avantage d'être simple et léger ; il est ensuite possible de concevoir un système d'accusés de réception et de numéros d'ordre pour assurer la fiabilité de la transmission.
C'est bien gentil de dire que votre ordinateur peut envoyer des paquets qui arriveront (peut-être) à n'importe quel ordinateur dans le monde, mais vous, ce qui vous intéresse, c'est de surfer sur le web et d'envoyer du courrier en même temps, et que les informations arrivent. Pourtant, le web et le courrier électronique ne sont pas toujours dans le même logiciel : il faut donc que plusieurs applications puissent se partager le réseau, et que l'une n'aille pas recevoir les données de l'autre.
Quand on programme une application réseau, on amierait en général avoir une sorte de tuyau : tout ce qu'on dit d'un côté, l'application à l'autre bout le reçoit, dans l'ordre, sans perte, et une seule fois, et inversement, on reçoit tout ce qu'elle dit. Si les ordinateurs aux deux bouts sont d'accord, un tel tuyau peut être simulé : on découpe ce qui doit passer dans le tuyau en morceaux assez petits pour tenir dans des paquets, et on les expédie avec un numéro d'ordre ; à l'autre bout, l'ordinateur répond par un paquet accusant la réception, et utilise les numéros pour remettre de l'ordre. Si on constate qu'un accusé de réception tarde, on réexpédie le paquet incriminé, au pire il arrivera en double et ce n'est pas grave.
Tant qu'on en est à rajouter des numéros aux paquets, on peut ajouter encore quelques informations. Par exemple l'identité du programme qui l'a envoyé, ou l'identité du programme qui doit le recevoir. Avec tout ça, on peut concevoir des connexions réseau : un tuyau virtuel entre un ordinateur et un autre, avec une extrémité qui envoit des paquets, attend des accusés de réception, et réexpédie les paquets qui se perdent, et l'autre extrémité qui reçoit les paquets et les remet dans l'ordre. Quand un paquet arrive sur un ordinateur, le système réseau consulte son contenu pour voir ses références, et trouve dans ses tables à quelle connexion il appartient.
Tout ceci est normalement fait par le système d'exploitation des ordinateurs, et caché aux programmes. Les programmes, eux, se contentent de réclamer une connexion, et ensuite d'utiliser le tuyau. Les données passent, ils n'ont pas à se soucier de toute la machinerie interne.
Sur internet, le protocole qui sert à établir des connexions est TCP. Pour distinguer les connexions, TCP utilise un numéro de port, un petit nombre (entre 1 et 65535), qu'on peut voir un peu comme le casier d'un élève, alors que l'adresse IP correspond à « 45 rue d'Ulm ». Une connexion est identifiée par quatre données :
Chaque paquet échangé dans le cadre d'une connexion rappelle ces quatre références. On peut remarquer que sur un ordinateur donné, le même port peut participer à plusieurs connexions. De fait, ça arrive assez souvent, mais jamais aux deux extrémités à la fois (même si rien ne l'interdit fondamentalement).
Les connexions TCP sont toujours doubles : dans un sens et dans l'autre entre les mêmes extrémités.
Du point de vue du programme, une connexion est un objet sur lequel on peut lire et écrire des données. Sous Unix, ça se présente presque de la même manière qu'un fichier. Le système d'exploitation sait à quel programme chaque connexion active « appartient », et fait tout le nécessaire.
Comme dans toutes relations de couple, aux débuts d'une connexion, il faut que l'un des deux fasse le premier pas, alors que l'autre se contente d'attendre. En informatique, l'extrémité de la future connexion qui attend s'appelle un serveur (eh oui, c'est le contraire du restaurant, où le serveur vient à votre table prendre la commande), tandis que l'extrémité qui fait le premier pas (qui envoit le premier paquet) s'appelle le client. Après l'échange de quelques paquets (trois, avec TCP) pour vérifier qu'il y a bien un serveur au port demandé, pour se mettre d'accord sur la taille des paquet, etc., la connexion est établié.
Une fois que c'est fait, il n'y a du point de vue du réseau plus de différence entre les deux extrémités. Cependant, le dialogue entre les programmes ne sera probablement pas symétrique : une fois une connexion établie entre votre navigateur web et Google, c'est bien votre navigateur web qui va poser une question à Google et non l'inverse. Il arrive néanmoins que ça finisse par être symétrique, en particulier dans le cas de dialogue en direct (avec ytalk par exemple) ou de jeux en réseau sans serveur central.
L'important est que les deux extrémités se comprennent. Pour ça, elles doivent encore une fois coder leurs données d'une certaine manière : encore un protocole. Cette manière n'est d'ailleurs pas la même s'il s'agit de web, de mail, ou d'autres activités tout aussi passionnantes.
Les plus attentifs doivent se poser une question : il y a sur l'ordinateur de Google (dont l'adresse IP est 216.239.59.99) 65535 ports différents, comment notre navigateur web a-t-il deviné le quel contacter ? La réponse est simple : le web, c'est sur le port 80. Pourquoi 80 ? C'est comme ça. Les services importants ont des numéros de port qui leur sont dédiés, l'IANA les recense. Les services moins répandus prennent un port plus ou moins au hasard, en espérant ne pas entrer en conflit avec un autre service, et comme c'est la même personne qui écrit les programme client et serveur c'est le même qui est utilisé des deux côtés.
Sous Unix, il faut des droits spéciaux pour créer un serveur sur un port en
dessous de 1024, ce qui permet d'être sûr, quand on donne son mot de passe à
SSH (port 23) ou à IMAP (port 143), d'être bien en train de parler au
programme autorisé. Au dessus de 1024, c'est libre. Certains se rappellent
peut-être que le serveur web des élèves était
http://www.eleves.ens.fr:8080/. Ceci veut dire
qu'il était sur le port 8080 au lieu du 80 habituel, justepent parce qu'il
aurait fallu des droits supplémentaires pour avoir 80.
Pour le client, c'est en général plus simple : le programme laisse le système d'exploitation choisir un port inutilisé. Certains programmes forcent l'utilisation d'un port en dessous de 1024 pour prouver qu'ils ne sont pas n'importe quel utilisateur, mais cette pratique tombe en désuétude au profit de méthodes cryptographiques.
Se rappeler les adresses IP, ce n'est pas facile. Et ce sera encore pire avec IPv6. Mais le problème n'est pas nouveau : on a le même avec les numéros de téléphone, et pour le résoudre on a inventé l'annuaire. L'annuaire pour Internet s'appelle le DNS, et fonctionne bien entendu en réseau.
À l'échelle d'un site, ou d'un fournisseur d'accès, il y a un (ou plusieurs)
ordinateur, que tous les autres connaissent par son adresse IP, et sur
lequel tourne un programme qui écoute sur le port 53 et qui se charge de
répondre aux questions du genre « quelle est l'adresse IP de
www.google.com ? ».
Ce programme n'a en général pas la réponse, mais il a l'adresse d'autres
ordinateurs à qui demander, qui eux-mêmes peuvent ne pas savoir mais avoir
l'adresse d'autres ordinateurs, etc. Le système est hiérarchique. Il y a à
la racine quelques ordinateurs (une douzaine) qui savent qui s'occupe des
.com, qui s'occupe des .org, qui s'occupe des
.fr, etc. Dans le cas des .fr, il y a encore
quelques ordinateurs, gérés par des organismes français (enfin, pas tous),
qui savent à qui s'adresser pour chaque domaine. Et ainsi de suite.
Par exemple, pour connaître l'adresse de sas.eleves.ens.fr, il
faut commencer par interroger l'un des serveurs racine, par exemple
198.41.0.4, qui répond qui'il ne sait pas, mais que les .fr
sont gérés par 192.93.0.1, 193.51.208.13, et quelques autres. Si on
interroge l'un d'entre eux, on apprend qu'il ne sait pas non plus, mais il
nous informe que ens.fr est géré par 129.199.96.11 (on
reconnaît le 129.199 : c'est un ordinateur de l'ENS) et quelques autres.
Enfin, on interroge 129.199.96.11, et on obtient la réponse, à savoir
129.199.129.1
Bien sûr, tous les programmes pour faire ça sont déjà écrits : quand on programme une nouvelle application réseau, il suffit d'utiliser la bonne fonction de la bibliothèque standard.