La question de ce module Comment fonctionne et de quoi est fait un ordinateur capable de traiter de l’information avec des algorithmes ?

La réponse de ce module A base de trois technologies … Des transistors (pour le processeur et la mémoire vive) => Leçons 1 (Architecture) & 2 (Hiérarchie) Des disques et autres flashes (pour les mémoires mortes) => Leçons 2 (Hiérarchie) & 3 (Stockage) Des réseaux (pour les communications entre machines et utilisateurs) => Leçon 4 (Réseaux) … qui demandent un permis de conduire La sécurité informatique => Leçon 5 (Sécurité)

Leçon III.4: Réseaux Informatiques Faculté Informatique et Communications Ph. Janson, W. Zwaenepoel, A. Ailamaki

Où en sommes-nous ? Ordinateur “Von Neumann” Leçon 1 Leçon 2 Stockage = transmission dans le temps Processeur Mémoire Mémoire Processeur Leçon 3 Ctrl/Addr/Mmry bus Ctrl/Addr/Mmry bus E/S E/S Comme on le voit sur cette planche, outre le processeur et la mémoire centrale, toute machine de Von Neumann comprend aussi des mémoires de masse (disques, SSD, carte Flash, ou autres) qui, selon les principes d’hiérarchie et de virtualisation vus à la leçon précédente, contiennent toutes les informations qui ne trouvent pas place en mémoire centrale, et surtout retiennent toutes ces informations même lors de l’arrêt de la machine. Par ailleurs de telles machines seraient bien inutiles si elles ne pouvaient pas communiquer avec leurs utilisateurs: les machines réputées comme postes de travail (consoles, desktops, laptops, tablettes, palmtops, smart phones, GPS et autres gadgets et systèmes embarqués, etc.) disposent donc aussi d’une interface utilisateur. Les machines à la réputation de serveurs n’ont pas nécessairement une telle interface utilisateur. Par contre postes de travail aussi bien que serveurs ont aujourd’hui obligatoirement une interface réseau pour leur permettre de communiquer entre elles. Le fonctionnement des interfaces utilisateurs dépend éminemment de la nature de ces interfaces: auditif, visuel, tactile, gestuel, ou plus généralement combinant plusieurs de ces modalités. L’étude de ce fonctionnement, si passionante et variée soit-elle, dépasserait le cadre de ce cours. Cette leçon se bornera donc à l’étude du fonctionnement des mémoires de masse et des réseaux. Beaucoup des principes de fonctionnement de toutes ces interfaces dites d’entrées/sorties de la machine sont d’ailleurs communs aux interfaces utilisateurs et aux interfaces réseaux. Communication = transmission dans l’espace Front-end Back-end (Avant-plan Arrière-plan) Back-end Front-end (Arrière-plan Avant-plan) Leçon 4

La raison d’être des réseaux En fait une raison d’être similaire à celle du stockage: La raison d’être du stockage est de répondre à la question Où et comment stocker des données de façon à pouvoir les retrouver plus tard? espace temps Quand et comment envoyer des données de façon à pouvoir les recevoir à distance? La raison d’être des réseaux est de répondre à la question ci-dessus Remarquez la dualité des questions Le but de cette leçon va en fait être de répondre à une seule et même question aussi bien pour les mémoires de masse que pour réseaux: Où, quand, et comment stocker des données (dans le cas des mémoires) ou les envoyer (dans le cas des réseaux) de telle façon à pouvoir les retrouver ultérieurement (dans le cas des mémoires) ou les recevoir à destination (dans le case des réseaux).

Plan de la leçon Le besoin de structure dans la transmission des données Types de structures: protocoles, messages, couches, encapsulation Structures d’Internet: topologie, interfaces, commutation, routage, protocoles Évolution des paradigmes de réseaux

Le besoin de structure dans la transmission de données Imaginons un signal arrivant d’un réseau, sans aucune structure Comment savoir si c’est un signal électrique réel ou juste du bruit ? Comment le convertir en un signal numérique binaire ? Comment savoir où il commence et où il finit ? Comment savoir d’où il vient ? Comment interpréter ce qu’il contient ? Autant essayer de capter un message extra-terrestre Rien que pour extraire un signal numérique d’un signal électrique analogique il faut déjà des conventions – voir module 2. Même quand on a récupéré le signal numérique il faut encore un tas de conventions pour en comprendre le sens. Ces conventions sont ce qu’on appelle des protocoles de communication.

Plan de la leçon Le besoin de structure dans la transmission des données Types de structures: protocoles, messages, couches, encapsulation Structures d’Internet: topologie, interfaces, commutation, routage, protocoles Évolution des paradigmes de réseaux

Les protocoles – Le pourquoi Un protocole = une règle qui gouverne une communication Exemple Oral Ecrit Où commence et où finit une communication ? Elle est délimitée par deux silences … ou par l’enveloppe d’un envoi postal Mais qu’est-ce qu’un silence ou l’enveloppe d’un envoi informatique ? D’où vient-elle et à qui s’adresse-t-elle ? De l’orateur à son interlocuteur … ou du signataire au destinataire d’un courrier Mais comment identifier un émetteur ou un récepteur informatique ? Dans quel langage est-elle exprimée ? Un langage commun aux interlocuteurs… ou à l’expéditeur et aux destinataires Mais comment des ordinateurs peuvent-ils savoir et se mettre d’accord ? Et si la communication est perturbée ? Un interlocuteur demande “Pardon?” … ou un destinataire demande une explication Mais comment peut faire un ordinateur en cas d’erreur ? A qui le tour de communiquer ? À chacun son tour de parler … mais on peut échanger des courriers simultanés Mais comment un ordinateur sourd et aveugle peut-il savoir ?

Les messages – Le comment des protocoles Début et fin Toute communication est faite de messages délimités par des marqueurs (sur les lignes de transmission) ou … un pointeur + longueur (au sein d’un ordinateur) L pointeur + longueur marqueur longueur L message marqueur

Les messages – Le comment des protocoles Séquencement Une communication peut se composer de plusieurs messages “On sonne à la porte je te rappelle …” ou “Nous verrons cela à la prochaine leçon…” Un abonnement à un journal ou un magazine Un envoi tellement gros que l’expédier en un colis est trop lourd pour la poste Un fichier est tellement long que l’expédier en une fois saturerait une ligne Un message peut inclure un numéro de séquence longueur no. seq. message

Les messages – Le comment des protocoles Adressage émetteur et récepteur Chaque message contient les adresses de l’émetteur et du récepteur src dest longueur no. seq. message

Les messages – Le comment des protocoles Syntaxe et sémantique Chaque message contient un champ indiquant le langage (type d’application) du message src dest longueur no. seq. type message

Les messages – Le comment des protocoles OK ou erreur et retransmission Chaque message peut contenir un code de détection d’erreur (CRC) CRC = cyclic redundancy check = un “résumé mathématique” du message en quelques (n) octets La probabilité que deux messages aient le même résumé = 1 / 28n (faible si n est assez grand) Si le message envoyé et / ou son résumé subissent une erreur de transmission le message et le résumé reçus ne “colleront” plus ensemble => le récepteur en déduit une erreur de transmission src dest longueur no. seq. type message CRC

Les messages – Le comment des protocoles OK ou erreur et retransmission Chaque message peut contenir un code de détection d’erreur (CRC) et un champ indiquant s’il s’agit d’un message OU … d’un acquittement négatif “Il me manque le message no. seq., retransmettre SVP” L’émetteur peut aussi renvoyer automatiquement après un “time-out” sans acquittement src dest longueur no. seq. type msg message CRC src dest longueur no. seq. type nacq CRC

Les messages – Le comment des protocoles OK ou erreur et retransmission Chaque message peut contenir un code de détection d’erreur (CRC) et un champ indiquant s’il s’agit d’un message OU … d’un acquittement positif “Bien reçu et bien compris jusque et y compris message no. seq.” OK pour envoyer le / les N message(s) suivant(s) [N = fenêtre d’envoi] src dest longueur no. seq. type msg message CRC src dest longueur no. seq. type acq CRC Dernier message acquitté Dernier message envoyé Dernier message acceptable

Les messages – Le comment des protocoles Résumé – En-tête Tous les champs de “contrôle” sont regroupés dans ce qu’on appelle l’en-tête ou “header” Cette enveloppe est ajoutée avant expédition et retirée après réception … comme pour un courrier postal src dest longueur no. seq. type msg / n/acq message CRC entête message CRC

Les couches = L’abstraction des protocoles A chaque niveau son protocole – Exemple téléphonique Application La conversation entre interlocuteurs Transport La connexion électronique entre Natels Réseau Le routage entre antennes via commutateurs Lien La connexion entre votre Natel et sa station GSM Physique La conversion audio-tactile entre vous et votre Natel => Chaque couche gère et abstrait les phénomènes de son niveau pour affranchir les autres couches de ces détails

Les couches = L’abstraction des protocoles Communication “logique” Machine 1 Machine 2

Les couches = L’abstraction des protocoles Communication “physique” Machine 1 Machine 2

Les couches = L’abstraction des protocoles Communication via antennes et commutateurs (= routeurs) Machine 1 Routeur Machine 2

L’encapsulation = l’emboitement des protocoles A chaque couche son protocole A chaque protocole son entête A l’émission: La couche de protocole N: Prend le paquet venant de la couche N+1 (y compris les entêtes des couches N+1, N+2, …) Y ajoute un nouvel entête pour sa propre couche Passe le paquet A la couche N-1 si N>1 Ou la transmet au réseau si N=1

Le principe d’encapsulation - Transmission Application données Couche 5 Couche 4 Couche 3 Couche 2 Couche 1

Le principe d’encapsulation - Transmission Application données Couche 5 e5 données Couche 4 Couche 3 Couche 2 Couche 1

Le principe d’encapsulation - Transmission Application données Couche 5 e5 données Couche 4 e4 e5 données Couche 3 Couche 2 Couche 1

Le principe d’encapsulation - Transmission Application données Couche 5 e5 données Couche 4 e4 e5 données Couche 3 e3 e4 e5 données Couche 2 Couche 1

Le principe d’encapsulation - Transmission Application données Couche 5 e5 données Couche 4 e4 e5 données Couche 3 e3 e4 e5 données Couche 2 e2 e3 e4 e5 données Couche 1

Le principe d’encapsulation - Transmission Application données Couche 5 e5 données Couche 4 e4 e5 données Couche 3 e3 e4 e5 données Couche 2 e2 e3 e4 e5 données Couche 1 e1 e2 e3 e4 e5 données

L’encapsulation = l’emboitement des protocoles A chaque couche son protocole A chaque protocole son en-tête A la réception: La couche de protocole N: Reçoit le paquet Du réseau si N=1 De la couche N-1 si N>1 Interprète et enlève l’entête de sa propre couche Passe le paquet à la couche N+1 (y compris les entêtes des couches N+1, N+2, …)

Le principe d’encapsulation - Réception Application Couche 5 Couche 4 Couche 3 Couche 2 Couche 1 e1 e2 e3 e4 e5 données

Le principe d’encapsulation - Réception Application Couche 5 Couche 4 Couche 3 Couche 2 e2 e3 e4 e5 données Couche 1 e1 e2 e3 e4 e5 données

Le principe d’encapsulation - Réception Application Couche 5 Couche 4 Couche 3 e3 e4 e5 données Couche 2 e2 e3 e4 e5 données Couche 1 e1 e2 e3 e4 e5 données

Le principe d’encapsulation - Réception Application Couche 5 Couche 4 e4 e5 données Couche 3 e3 e4 e5 données Couche 2 e2 e3 e4 e5 données Couche 1 e1 e2 e3 e4 e5 données

Le principe d’encapsulation - Réception Application Couche 5 e5 données Couche 4 e4 e5 données Couche 3 e3 e4 e5 données Couche 2 e2 e3 e4 e5 données Couche 1 e1 e2 e3 e4 e5 données

Le principe d’encapsulation - Réception Application données Couche 5 e5 données Couche 4 e4 e5 données Couche 3 e3 e4 e5 données Couche 2 e2 e3 e4 e5 données Couche 1 e1 e2 e3 e4 e5 données

Pause

Plan de la leçon Le besoin de structure dans la transmission des données Types de structures: protocoles, messages, couches, encapsulation Structures d’Internet: topologie, interfaces, commutation, routage, protocoles Évolution des paradigmes de réseaux

Structure d’Internet – Topologie Internet est composé de Réseaux domestiques Wi-Fi & câbles Ethernet Réseaux d’entreprises EPFL, CHUV Intranets de sociétés Migros, Coop Réseaux nationaux (ISP) Swisscom, Sunrise Intranets de multinationales Nestlé, IBM …….. Réseaux internationaux “Backbones” chez nous EPFL CHUV COOP COOP COOP Swisscom Sunrise IBM US IBM UK IBM CH IBM JP Backbone1 Backbone2

Structure d’Internet – Protocoles 5. Application Terminal interactif ex. SSH Transfert de fichiers ex. FTP Courrier électronique SMTP Navigation sur la toile HTTP Bottin Internet DNS Etc. …. 4. Transport TCP SSL / TLS UDP 3. Réseau IP (adressage et routage) 2. Lien CSMA / CD PPP “Trunk lines” 1. Physique Wi-Fi Ethernet CATV ADSL Au niveau physique on trouve par exemple les normes ADSL ou les câbles de télévision pour les réseaux à grande distance (WAN), Ethernet pour les réseaux locaux (LAN) filaires, et Wi-Fi pour les LAN sans fil. Au niveau lien on trouve par exemple les normes PPP pour les WAN et CSMA-CD pour les LAN. Au niveau réseau on trouve la norme IP, IPv4 encore très courant mais en récession progressive devant IPv6 (qui inclut IPv4 pour des raisons de coexistence et donc de rétro-compatibilité évidentes). Au niveau transport on trouve par exemple les normes UDP, TCP, et SSL (qui est une version sécurisée de TCP) Enfin au niveau 5 on trouve les protocoles applicatifs DNS pour le bottin de l’Internet, SSH pour la simulation d’un terminal, FTP et NFS pour le transfert de fichiers, , SMTP, POP, et IMAP pour le courrier électronique, HTTP pour la toile, etc. Voyons dans les planches suivantes certains de ces protocoles, surtout leurs aspects de nomenclature, d’adressage, et de routage.

Couches 1 & 2: Interface physique & lien Comment fait un ordinateur pour émettre / recevoir ? Une partie logicielle Implémentation des protocoles de couches 1 & 2 Une partie matérielle Dans le temps, une carte réseau Maintenant, une simple puce Emission: transforme les bits d’un message en mémoire en signaux électroniques sur le réseau Réception: transforme les signaux électroniques du réseau en les bits composant un message en mémoire

Couche 3: Commutation par circuits Le cas de la téléphonie, radio, TV Le débit est quasiment constant débit temps

Couche 3: Commutation par circuits Le cas de la téléphonie, radio, TV On établit et on réserve une connexion électronique dédiée entre émetteur et récepteur(s) La connexion est “occupée” pendant tout le temps de la transmission, y compris les silences débit circuit avec un débit D réservé D temps

Couche 3: Commutation par circuits Le cas de la téléphonie, radio, TV SDM = circuit physique (téléphonie) TDM = canal temporel (GSM / Natel) FDM = canal de fréquence (radio, TV) La couche 3 constitue le coeur des réseaux informatiques, où se trouvent ce qu’on appelle des routeurs, l’équivalent informatique des anciens centraux téléphoniques ou des centres de tri postal responsables du routage du trafic au travers de ces réseaux. Le fonctionnement des routeurs informatiques est cependant beaucoup plus proche de celui des tris postaux que de celui des centraux téléphoniques. Dans un ancien central téléphonique tel que celui représenté sur cette planche, le routage ou commutation du trafic se faisait “par circuits”. Sur base du numéro de téléphone formé par un abonné les centraux téléphoniques établissaient litéralement un circuit électrique de bout en bout, connectant la ligne de l’abonné appelant à celle de l’abonné appelé par le travers d’un ou plusieurs centraux intermédiaires. Pendant toute la durée de la conversation, les lignes des deux abonnés ainsi que toute les lignes intermédiares étaient bloquées (occupées) par le circuit commuté de bout en bout. C’est ce qu’on appelait le multiplexage de circuits dans l’espace physique (SDM = space-division multiplexing). Plus tard ces circuits ont été virtualisés, soit sous forme de petites fenêtres temporelles se répétant régulièrement sur les lignes physiques (TDM – time-division multiplexing ), soit sous forme de bandes de fréquence allouées sur les lignes physiques (FDM = frequency-division multiplexing). Mais dans tous les cas le circuit, physique ou virtuel était occupé pendant tout le temps de la conversation. Dans tous les cas la réservation du circuit le bloque (ligne occupée)

Couche 3: Commutation Le cas de l’informatique Le débit est saccadé, comportant des rafales à haut débit séparées par des “silences” débit temps

Couche 3: Commutation par paquets Le cas de l’informatique débit Réserver des circuits à haut débit serait inefficace Réserver des circuits à faible débit serait lent On ne réserve pas de circuits mais on transmet les messages (= paquets) avec haut débit Et les lignes et commutateurs restent disponibles pour d’autres paquets pendant les “silences” Quel débit choisir? En tout cas, inefficace temps

Couche 3: Commutation par paquets Le cas de l’informatique C’est le modèle de la poste et non de la téléphonie => Des paquets peuvent se perdre ou arriver en désordre Les protocoles (ex. retransmission) sont là pour accomoder ces “hoquets” et cela marche même en téléphonie (Skype) B A A B C C B B B C D C Dans les réseaux informatiques, comme dans les tris postaux, le routage procède par paquets. Au lieu qu’une communication de bout en bout monopolise un circuit (réel ou virtuel), elle est divisée en une succession de messages (lettres dans le cas postal) ou paquets qui portent chacun une adresse de destination et sont acheminés tant bien que mal par les routeurs intermédiaires vers ladite destination. Comme illustré sur la planche, il se peut donc qu’un paquet (en noir) adressé à C lui soit délivré en retard, après un paquet (en jaune) originalement envoyé après lui. Il est même possible qu’un paquet soit complétement perdu, comme cela arrive à la poste. Au vu de la capacité des lignes et des routeurs modernes, il s’avère contre toute intuition que ce mode de commutation par paquets est tellement plus efficace que la commutation par circuits qui est bloquante, que tout le trafic téléphonique moderne est aujourd’hui acheminé par les réseaux informatiques. Quelques lignes téléphoniques locales installées depuis des années existent encore et sont évidemment toujours bloquées pendant une conversation mais dès le premier routeur, le contenu des conversations est converti en paquets et acheminé par un réseau informatique vers leur destination, où les paquets sont réassemblés avant d’être éventuellement délivrés de nouveau par une ligne physique bloquante. Les réseaux informatiques pouvant retarder ou perdre des paquets, il arrive que des conversations soient hachées ou coupées mais c’est suffisemment rare pour être acceptable. D B

Couche 3 – Adressage et routage IP Chaque machine a une adresse IP unique Deux versions: IPv4: 32 bits - 232 (~4.109) systèmes interprétés comme R.A = un abonné A (24-8 bits) sur un réseau R (8-24 bits) IPv6: 128 bits - 2128 (~256.109.109.109.109) systèmes L’entête de tout paquet IP contient l’adresse IP de la source et l’adresse IP de la destination Routage Comment trouver la route la plus rapide de A à B ? Chaque routeur contient une table de routage indiquant La direction à prendre vers chaque destination possible La distance jusqu’à cette destination (en nombre de sauts)

Couche 3 – Exemple de routage IP B E

Couche 3 – Exemple de table de routage IP (A) dest direction distance B D 2 C 1 E A D C B E

Couche 3 – Exemple de table de routage IP (D) dest direction distance A 1 B C A/E 2 E A D C B E

Couche 3 – Exemple de table de routage IP (C) dest direction distance A 1 B A/E 3 D 2 E A D C B E

Couche 3 – Exemple de routage IP de A à B (1) dest direction distance B D 2 C 1 E A D C B E

Couche 3 – Exemple de routage IP de A à B (2) dest direction distance A 1 B C A/E 2 E A D C B E

Couche 3 – Calcul des tables de routage IP Décentralisation totale – aucune autorité centrale contrairement aux réseaux téléphoniques Le routage se fait par “ouï-dire” mais résulte en un calcul distribué des “plus courts chemins” Chaque noeud annonce à ses voisins la “longueur” des chemins qu’il connaît Chaque noeud retient le chemin le plus court parmi ceux annoncés par ses voisins Les routeurs n’ont ni notion ni connaissance d’aucune connexion

Couche 3 – Exemple de calcul de tables de routage IP (1) “je suis A” A D “je suis A” “je suis A” C B E

Couche 3 – Exemple de calcul de tables de routage IP (2) dest direction distance A 1 “je suis A” A D “je suis A” “je suis A” C B dest direction distance A 1 E dest direction distance A 1

Couche 3 – Exemple de calcul de tables de routage IP (3) dest direction distance A 1 A D je suis à distance 1 de A C X B X je suis à distance 1 de A je suis à distance 1 de A dest direction distance A 1 E dest direction distance A 1

Couche 3 – Exemple de calcul de tables de routage IP (4) dest direction distance A 1 A D je suis à distance 1 de A C B dest direction distance A 1 dest direction distance A D 2 E dest direction distance A 1

Couche 4 – TCP (Transport Control Protocol) Connexion TCP Ports TCP TCP Protocole d’échange de messages classique entre messages de connexion et messages de déconnexion Seuls les ordinateurs aux extrémités d’une connexion en ont conscience et connaissance Intelligence à la périphérie = argument de “bout-en-bout” (end-to-end) Contrairement aux centraux téléphoniques, les routeurs ne sont pas “encombrés” de connexions Les implementations de TCP sur chacun des ordinateurs en bout de la connexion gérent le séquencement des messages, le contrôle de flux, le recouvrement d’erreurs, etc. entre des ports TCP correspondant à différentes applications. SSL (Secure Session Layer) / TLS (Transport Layer Security) Version de TCP sécurisée cryptographiquement (v. Leçon 14) Application 1 Application 1 Application 2 Application 2 A la couche 4 le protocole TCP (Transmission Control Protocol) vise précisément à faire tout le travail nécessaire pour offrir l’apparence de connexions de transport alors que le protcole IP ignore tout de ces connexions (contrairement à un central téléphonique). TCP va donc réguler le flot de paquets à travers le réseau IP de façon (1) à ne pas déborder les routeurs par lequels passent ces paquets (2) à répéter les paquets qui se perdraient néanmoins (3) à réordonner les paquets qu’IP délivrerait à destination dans le désordre (4) à tronçonner et réassembler à la réception les messages qui seraient trop grands pour passer dans un seul paquet IP et (5) à délivrer les emssages reçus à la bonne application, reflétée par des sous-adresses appelées ports. SSL (Secure Session Layer)m aussi standardisée sous le nom de TLS (Transport Layer Security) est une version sécurisée de TCP – voir leçon 13.

Couche 5 – Le bottin Internet = DNS (Domain Name System) L’assignation de noms est hiérarchique mais également totalement décentralisée DNS traduit noms en adresses, p.ex. www.epfl.ch en son adresse IP (Root) ch search tel map epfl www google com ibm zurich w3 edu mit alum org w3c etc. La couche 5 inclut le protocole DNS (Domain Name System) qui définit la notion et la structure des noms utilisés sur Internet Les ordinateurs se contactent – comme les humains au téléphone – par adresses numériques (IP) Mais les utilisateurs derrière les ordinateurs réfèrent les uns aux autres et aux serveurs en termes de noms généralement alphabétiques, p.ex. www.epfl.ch – exactement comme les utilisateurs du téléphone Le DNS est un service de « bottin » offert par une myriade de serveurs dans le monde qui permet d’obtenir l’adresse IP correspondant à un « domain name » tel que www.epfl.ch Le DNS définit un nombre de Top-Level Domains (TLDs) com, edu, gov, mil, net, org, … , ainsi que chaque pays représenté par 2 lettres (p.ex. CH) Chaque TLD peut alors définir et gérer ses propres sous-domaines – et ainsi de suite … Chaque niveau de domaine connaît au moins un serveur pour chacun de ses sous-domaines, un serveur pour son domaine supérieur hiérarchique, et un serveur de TLD Chaque serveur DNS peut être répliqué par mesure de fiabilité Le protocole DNS permet alors à n’importe quel client de trouver récursivement l’adresse de n’importe quel serveur ou autre client à condition de connaître l’adresse IP d’un serveur DNS Réseau interne privé inconnu du DNS public

Couche 5 – La toile = HTTP (Hyper-Text Transfer Protocol) et HTML (Hyper-Text Markup Language) Permet de manipuler des ‘ressources’ au moyen de 8 messages différents dont 4 principaux: POST crée - ou ajoute une information à - une ressource PUT crée ou met à jour une ressource GET lit et renvoie le contenu d’une ressource DELETE élimine une ressource Ces ressources sont désignées par des URI (Universal Resource Identifier) http : // hôte [ : port ] / [ chemin-arborescent [ ? requête ] ] HTTPS indique l’usage de HTTP sur SSL / TLS => sécurité Le contenu des messages est exprimé en format HTML HTTP (Hyper-Text Transfer Protocol) est le protocole applicatif de la toile qui permet à un client d’interroger un serveur du web. HTTP propose essentiellement 4 types de messages différents: POST qui crée - ou ajoute une information à - une ressource du serveur PUT qui crée ou met à jour une ressource sur le serveur GET qui lit et renvoie le contenu d’une ressource stockée sur le serveur DELETE qui supprime une ressource du serveur Les ressources sur la toile sont désignées par des URI (Universal Resource Identifier) de la forme http : // serveur [ : port ] / [ chemin-arborescent de la ressource visée [ ? requête ] ] Serveur est le serveur abrittant la resource visée. Port est l’adresse l’application servant la ressource (par défaut 80 pour les services web ordinaires) Le chemin arborescent est le nom de la resource sous lequel elle est identifiée par le serveur, souvent le nom d’un fichier ou d’une base de données correspondante. Requête est le ou les paramètres de la requête spécifique adressée a la ressource visée.

Couche 5: applications e-mail – SMTP (Simple Mail Transfer Protocol) POP (Post Office Protocol) & IMAP (Internet Message Access Protocol) SMTP permet le transfert de mails d’expéditeur à destinataire via des serveurs de courriel (MTA) La boîte aux lettres du destinataire réside sur un serveur sur lequel le destinataire est supposé se ‘loguer’ directement pour relever son courrier (ex. webmail) POP permet à un utilisateur d’avoir 2 boîtes aux lettres L’une sur son propre PC et l’autre sur le serveur – comme une Case Postale POP permet à l’utilisateur de vidanger la boîte de son serveur sur celle de son PC IMAP permet à un utilisateur de maintenir les 2 boîtes aux lettres synchronisées Ceci permet de maintenir des classeurs, carnet d’adresses, et agendas synchronisés et d’y avoir accès de n’importe quelle station sur le réseau B.A.L. Mail Transfer Agent local Mail Transfer Agent local B.A.L. Une des applications importantes de la couche 5 est le courrier électronique. Le protocole SMTP (Simple Message Transfer Protocol) permet le transfert de mails d’expéditeur à destinataire. Par contre pour relever son courrier, le destinataire est supposé consulter sa boite aux lettres directement sur le serveur qui la détient. Si ce destinataire préfère lire son courrier sur son propre PC, portable, tablette, ou smart phone, il doit au préalable aller le repêcher et le télécharger du serveur sur son poste de travail préféré. Il a pour cela le choix entre deux protocoles applicatifs différents: POP (Post Office Protocol) et IMAP (Internet Message Access Protocol). POP permet à un utilisateur d’avoir deux boîtes aux lettres, l’une sur son poste de travail et l’autre sur le serveur – comme une Case Postale. POP permet à l’utilisateur de vidanger la case postale de son serveur sur la boite aux lettres de son poste de travail. IMAP permet à un utilisateur de maintenir les deux boîtes aux lettres synchronisées. Ceci permet de maintenir des classeurs, carnet d’adresses, et agendas synchronisés et d’y avoir accès de son serveur, de son poste de travail ou même de n’importe quelle client sur le réseau.

Plan de la leçon Le besoin de structure dans la transmission des données Types de structures: protocoles, messages, couches, encapsulation Structures d’Internet: topologie, interfaces, commutation, routage, protocoles Évolution des paradigmes de réseaux

A quoi servent les réseaux informatiques ? Communication machine-machine Communication homme-machine Collaboration homme-homme Production d’information Consommation d’information Traitement de l’information Stockage de l’information Les réseaux informatiques remplissent trois rôles différents et complémentaires: L’information vitale à la société moderne est souvent stockée et traitée en des endroits différents Les réseaux sont essentiels pour permettre aux ordinateurs traitant l’information de communiquer avec les ordinateurs stockant l’information => Communication de machine à machine L’information vitale à la société moderne est souvent stockée et traitée loin des utilisateurs qui en ont besoin Les réseaux sont donc essentiels pour permettre aux utilisateurs qui en ont besoin de communiquer avec les ordinateurs qui stockent et traitent l’information => Communication d’utilisateur à machine L’information vitale à la société moderne est normalement stockée et traitée par et pour une multitude d’utilisateurs Les réseaux sont essentiels pour permettre aux utilisateurs produisant de l’information de communiquer avec les utilisateurs consommant de l’information => Communication d’utilisateur à utilisateur Stockage de l’information Traitement de l’information

Homme-machine 1 – Terminaux et centres de données «glasshouse light dimmers» Les utilisateurs se connectaient à un seul ordinateur central via des terminaux dépourvus d’intelligence Tout traitement se passait sur l’ordinateur central ‘60 Front-end Application Dans la nuit des temps informatiques (1945-1970), les processeurs, mémoires centrales, et mémoires de masse étaient tellement onéreux qu’il était exclu de donner à chaque utilisateur un ordinateur personnel. “Toute” l’informatique était concentrée dans des centres de données, où les utilisateurs devaient aller déposer leurs programmes et leurs données sous forme de cartes perforées et reprendre bien plus plus tard leurs résultats sous forme imprimée. Le chargement des programmes et des données “, leur stockage sur mémoires de masse, le traitement des données par les programmes, ainsi que l’impression des résultats était entièrement effectués par les gigantesques et coûteuses machines des centres de données. Ce n’est que vers 1970, à l’avènement des tout premiers réseaux, que les utilisateurs ont reçus des terminaux dépourvus de la moindre mémoire et du moindre processeur pour pouvoir soumettre leurs requêtes et recevoir leurs résultats à distance sans se déplacer jusqu’aux centres de données. Les terminaux étant dépourvus le mémoire et de processeur, tout le traitement des entrées/sorties des utilisateurs (“front-end”), les applications et la gestion des données stockées (“back-end”) se faisait au centre de données. Back-end

Machine-machine 1 – Réseaux de centres de données Des centres de données sont interconnectés pour échanger données et charges de travail ’70 (ARPAnet) Front-end Back-end Front-end Back-end Vers 1975, des centres de données de plus en plus importants ayant vu le jour, un désir et un besoin de les interconnecter pour leur permettre de communiquer ont émergé. Ainsi sont nés les premiers réseaux machine-à machine qui utilisaient initialement des modems sur des lignes de téléphone capables de transmettre quelques 2400 bits / seconde.

Homme-machine 2 – Clients et serveurs Les terminaux sont devenus des PCs intelligents qui réalisent une partie du traitement Les utilisateurs ont accès à plusieurs serveurs ‘80 Front-end de l’application Back-end de l’application Dès 1980 sont apparus les premiers ordinateurs personnels (PCs). Cette révolution a rapidement vu s’opérer un changement considérable dans la façon dont les réseaux ont été utilisés. Les terminaux ont progressivement disparus. Ils ont été remplacés par des ordinateurs personnels qui dans un premier temps étaient utilisés soit pour communiquer avec les centres de données en simulant des terminaux (pour continuer à bénéficier de toutes les applications qui avaient été conçues pour servir des terminaux), soit pour du traitement de texte ou de la tabulation de données locales. L’intérêt d’échanger par e-mail des données locales aux PCs a cependant rapidement encouragé une restructuration des applications telle que leur cœur et leur back-end gérant les données stockées dans les centres de données sont restés l’apanage de ces centres; par contre la partie «front-end», interface de ces applications avec les utilisateurs a quitté les centres de données et s’est déployée vers les PCs. Ainsi s’est développé le paradigme encore omni-présent des réseaux clients-serveurs, où les PCs (clients) supportent une large part du travail de saisie des données et d’affichage des résultats, et ont à leur disposition une panoplie de méthode logicielles leur permettant d’écahnger fichiers, courrier électronique, etc. avec les serveurs «re-lookés» des centres de données.

Machine-machine 2 – Traitement distribué pré-web Les applications de traitement sont elles-mêmes distribuées entre plusieurs serveurs qui coopèrent chacun selon leur spécificité pour résoudre des problèmes distribués ’80 (DCS, Corba) Back-end de l’application Front-end de l’application Applications distribuées Vers le milieu des années ‘80 le paradigme des clients-serveurs a lui-même subi une évolution similaire à celle subie 10 ans plus tôt par les centres de données originels: Exactement comme il s’est avéré désirable vers 1975 de connecter les centres de données en réseaux, il s’est avéré désirable vers 1985 de permettre aux serveurs “re-lookés” du paradigme client-serveur de communiquer entre eux non seulement pour échanger des données mais même pour se répartir les charges de travail, se seconder, se compléter l’un l’autre et harmoniser leurs fonctions respectives pour les intégrées dans des applications vastes et complexes impliquant une multitude de composants matériels et logiciels distribués de par le monde. Ainsi est née un premier paradigme de traitement distribué.

Homme-homme – Réseaux de pairs «peer-to-peer» Les utilisateurs aussi communiquent entre eux souvent au travers d’un ou plusieurs serveurs, p.ex. e-mail, réseaux sociaux, etc. mais parfois même directement, p.ex. «file sharing» ‘90 Front-end de l’application Back-end de l’application optionnel Vers la fin des années ‘90 un nouveau et important paradigme a vu le jour: celui des réseaux de pair-à-pair, d’égal-à-égal, ou de client-à-client. Depuis les débuts des courriers électroniques dans les années 70, les utilisateurs ont utilisé des réseaux pour communiquer entre eux mais ces communications se faisaient par l’intermédiaire de serveurs, des serveurs de courrier en l’occurrence. Dans le paradigme pair-à-pair (peer-to-peer) la notion de serveur intermédiaire s’estompe fortement, voire complètement. Un serveur est parfois impliqué dans l’établissement de la connexion entre clients mais une fois la connexion établie, le serveur se retire du jeu et les clients communiquent directement, comme dans les réseaux de communication téléphonique qui passent aujourd’hui presque tous par l’Internet et sont le plus bel exemple de réseaux pair-à-pair, bien au-delà du réseau skype qui est lui un cas pair-à-pair extrême mais encore loin de l’échelle des réseaux téléphoniques classiques. Une autre type de réseau pair-à-pair, plus ancien mais moins respectable que la téléphonie, est représenté par une série de réseaux d’échange de fichiers, en soi rien d’offusquant sauf que les fichiers distribués par ces réseaux sont souvent des copies illégales ou piratées de clips musicaux ou vidéos. De tels réseaux ont adopté le paradigme pair-à-pair précisément pour éviter de devoir stocker de tels fichiers illégaux sur des serveurs centraux qui peuvent facilement être idnetifiés, localisés, déconnectés du réseau, et poursuivis pour violation de droits d’auteurs ou autres chefs. Dans les réseaux pair-à-pair les fichiers sont stockés sous forme de multiples copies ou fragments de copies distribués et échangés librement entre des dizaines voire des centaines de milliers de clients de par le monde, rendant bien entendu irréaliste l’idée de tous les déconnecter et les poursuivre.

Homme-machine 3 – Web 1.0 «back to the future» Clients navigateurs légers et applications sur serveurs web La gestion centralisée d’un ‘zoo’ de PCs est un cauchemar Les centres de données rêvent de PC-terminaux simples et standardisés Les navigateurs apportent une solution universelle idéale ‘90 (Web 1.0) Serveurs web au centre de l’application (= “middle tier”) Navigateurs front-end de l’application Back-end de l’application La seconde moitié des années ‘90 a aussi vu l’avènement d’un paradigme important pour son époque et toujours bien présent quoique stagnant: celui de la toile originale (world-wide web restrospectivement designé sous l’expression Web 1.0). Ce paradigme a en fait représenté une évolution fondamentalement bénéfique, bien que se résumant en quelque sorte à un pas en arrière. A l’époque originelle des réseaux de terminaux, toute l’informatique était l’apanage des centres de données. L’avènement des PCs et du paradigme client-serveur a bouleversé cet univers bien réglé ou les centres de données décidaient, possédaient, et controlaient tout. Tout d’un coup les utilisateurs pouvaient acheter leurs propres PCs et dicter aux centres de données ce qu’ils attendaient des serveurs. Par ailleurs l’entretien et le dépannage par les centres de données d’un zoo toujours plus chaotique d’applications diverses sur les PCs a commencé à coûter très cher à ces centres de données. Exactement pour la même raison que le paradigme NAS n’a jamais vraiment décollé, le paradigme client-serveur a commencé a trouver ses détracteurs dans les centres de données qui ont recherché des solutions visant à unifier, homogénéiser, et brider le nombre et le choix des applications sur les PCs. L’invention de la toile au CERN au début des années ‘90 a amené une solution de rêve à ce problème. La technologie de la toile allait permettre de limiter les PCs à une seule application: le navigateur et la toile ferait le reste, mettant à disposition des PCs toutes les données du monde à travers un seule application définie par les règles de la toile. Il suffisait d’insérer entre les PCs et les serveurs d’antant des serveurs traduisant les langages des anciens serveurs en le seul langage de la toile, et le tour était joué. Ce paradigme a rendu d’immenses service et ne disparaitra probablement plus jamais – nous l’employons tous chaque fois que nous cliquons sur un lien sur la toile.

en utilisant des protocoles «web» entre homme-machine-machine-homme Machine-machine 3 – Web 2.0 Non seulement les utilisateurs mais aussi les serveurs peuvent communiquer entre eux en utilisant des protocoles «web» entre homme-machine-machine-homme 2000 (Web 2.0) Front-end de l’application Back-end de l’application Applications client-serveur Applications “peer-to-peer” Applications web distribuées Le problème de cette solution miracle est qu’elle offre un nouveau modèle de paradigme pour la communication machine-utilisateur mais n’apporte aucune solution à la question perenne de la communication machine-machine pour le traitment d’applications complexes constituées de multiples fragments de logiciels tournant sur une multitude de serveurs distribués de par le monde. Cette question a trouvé sa réponse vers les années 2000 en la technologie dite Web 2.0, une extension de la technolgie de la toile Web 1.0 permettant à des serveurs de communiquer non seulement avec des utilisateurs clients mais aussi avec d’autres serveurs tout en restant dans le cadre général des technologies de la toile Web 1.0. Ensemble les technologies Web 1.0 et 2.0 permettent aujourd’hui de traiter de façon intégrée toutes les communications machine-utilisateur, machine-machine, et utilisateur-utilisateur (pair-à-pair).

Homme-machine-homme – Un «cloud» pour mobiles «back to the future again» – le centre de données est le réseau Les serveurs sont virtualisés et concentrés sur de gigantesques centres de données «lights-out» publics ou privés, situés au cœur du «cloud», en des endroits discrets voire secrets, et fonctionnant comme des services publics faisant partie intégrante de l’infrastructure Front-end de l’application Front-end de l’application Observez La mutation X Back-end de l’application Back-end de l’application La révolution suivante date des dix dernières années qui ont vu s’imposer deux nouvelles révolutions. D’une part le nombre de smart phones vendus dans le monde a dépassé le nombre de PCs. Depuis ce jour l’évolution de la toile est dominée par le besoin de servir les utilisateurs de smart phones (et aujourd’hui de tablettes) bien plus que celui de servir les utilisateurs de PCs. Toutes les technologies Web 1.0 et 2.0 évoluent maintenant vers ce paradigme du client mobile: machine-utilisateur, machine-machine, et utilisateur-utilisateur, mais où utilisateur ne signifie plus PC mais bien tablette ou téléphone portable. D’autre part on a assisté à l’avènement de ce qu’on appelle le paradigme du “cloud computing” (traitement dans le cyber-nuage) qui se conjugue parfaitement et renforce l’avènement des téléphones mobiles. Les lois physiques ayant pratiquement mis un terme au doublement de la vitesse des circuits intégrés tous les 18-24 mois, la seule façon de continuer à doubler la capacité des processeurs à la même fréquence est de doubler le nombre des processeurs par circuit intégré. Mais si un tel doublement sert bien les serveurs qui savent toujours que faire de processeurs supplémentaires, il sert moins bien les clients, surtout les clients mobiles qui ont une taille et une alimentation électrique (batterie) limitées. Avec ces développements technologiques, il redevient de plus en plus rentable et effectif de re-concentrer tout le traitement d’applications dans de gigantesques centres de données d’envergure planétaire, profondément et intimement intégrés à l’infrastructure informatique globale (le cyber-nuage), et de ne laisser aux clients portables que le rôle d’interface utilisateur. Les paradigmes mobile et cloud se renforcent mutuellement en ce que le cloud, qui capitalise sur le nouveau rapport performance/coût des avancées technologiques, et les postes mobiles, qui se débarassent de la charge applicative au profit de serveurs centraux, se retrouvent en un modèle qui rend le contrôle des données et des applications importantes aux infrastructures centrales. A part quelques jeux, quelle application mobile sérieuse peut encore se passer du cloud? La plupart requièrent au moins de massives données centrales constamment actualisées, p.ex. Google Maps, ou même un traitement en ligne trop lourd pour un portable. Le paradigme résultant est que les clients mobiles sont certes bien plus intelligents et bien plus puissants que les terminaux d’antant, mais ils sont auusi moins puissants que les postes de travail conventionnels et immobiles. Comme les terminaux d’antant ils délèguent une grosse partie de leurs charges de travail au cloud, qui est certes distribué et lui aussi bien plus puissant que les centres de données d’antant mais joue en fait le même rôle central sous une toute autre apparence. L’Internet compte aujourd’hui 5 fois plus de «smart phones» que de PCs l’usage et le développement du web sont désormais dominés par les mobiles (et les tablettes)

Homme-machine – «Edge computing for real-time IoT» «back to the future again» – clients-serveurs intelligents co-situés Ces objets intelligents disposent de leur propre capacité de calcul. Ils intègrent front-end & back-end de leur application et ne dépendent de serveurs externes que pour des communications accessoires (e.g.GPS) Application front & back Application front & back La révolution suivante date des dix dernières années qui ont vu s’imposer deux nouvelles révolutions. D’une part le nombre de smart phones vendus dans le monde a dépassé le nombre de PCs. Depuis ce jour l’évolution de la toile est dominée par le besoin de servir les utilisateurs de smart phones (et aujourd’hui de tablettes) bien plus que celui de servir les utilisateurs de PCs. Toutes les technologies Web 1.0 et 2.0 évoluent maintenant vers ce paradigme du client mobile: machine-utilisateur, machine-machine, et utilisateur-utilisateur, mais où utilisateur ne signifie plus PC mais bien tablette ou téléphone portable. D’autre part on a assisté à l’avènement de ce qu’on appelle le paradigme du “cloud computing” (traitement dans le cyber-nuage) qui se conjugue parfaitement et renforce l’avènement des téléphones mobiles. Les lois physiques ayant pratiquement mis un terme au doublement de la vitesse des circuits intégrés tous les 18-24 mois, la seule façon de continuer à doubler la capacité des processeurs à la même fréquence est de doubler le nombre des processeurs par circuit intégré. Mais si un tel doublement sert bien les serveurs qui savent toujours que faire de processeurs supplémentaires, il sert moins bien les clients, surtout les clients mobiles qui ont une taille et une alimentation électrique (batterie) limitées. Avec ces développements technologiques, il redevient de plus en plus rentable et effectif de re-concentrer tout le traitement d’applications dans de gigantesques centres de données d’envergure planétaire, profondément et intimement intégrés à l’infrastructure informatique globale (le cyber-nuage), et de ne laisser aux clients portables que le rôle d’interface utilisateur. Les paradigmes mobile et cloud se renforcent mutuellement en ce que le cloud, qui capitalise sur le nouveau rapport performance/coût des avancées technologiques, et les postes mobiles, qui se débarassent de la charge applicative au profit de serveurs centraux, se retrouvent en un modèle qui rend le contrôle des données et des applications importantes aux infrastructures centrales. A part quelques jeux, quelle application mobile sérieuse peut encore se passer du cloud? La plupart requièrent au moins de massives données centrales constamment actualisées, p.ex. Google Maps, ou même un traitement en ligne trop lourd pour un portable. Le paradigme résultant est que les clients mobiles sont certes bien plus intelligents et bien plus puissants que les terminaux d’antant, mais ils sont auusi moins puissants que les postes de travail conventionnels et immobiles. Comme les terminaux d’antant ils délèguent une grosse partie de leurs charges de travail au cloud, qui est certes distribué et lui aussi bien plus puissant que les centres de données d’antant mais joue en fait le même rôle central sous une toute autre apparence. L’Internet comptera de plus en plus d’intelligences artificielles exigeant des temps de réaction qui excluent de communiquer avec des centres de données

Résumé historique des paradigmes de réseaux informatiques ‘60 - Homme-machine 1 – Terminaux et centres de données ‘70 - Machine-machine 1 – Réseaux de centres de données ‘80 - Homme-machine 2 – Clients et serveurs Machine-machine 2 – Traitement distribué pré-web ‘90 - Homme-homme – Réseaux de pairs Homme-machine 3 – Web 1.0 Clients navigateurs légers 2000 - Machine-machine 3 – Web 2.0 Traitement distribué post-web 2010 - Homme-machine-homme – Un «cloud» pour mobiles 2020 - Homme-machine 4 – Edge computing ? Axe historique ARPAnet – 29 octobre 1969 (Arrivée des PCs) Internet s’impose – les années 90 Le nombre des mobiles dépasse celui des PCs Des objets super-intelligents s’affranchissent du cloud computing Cette planche résume cette évolution des trois types de réseaux: en bleu les réseaux utilisateur-machine, en rouge les réseaux machine-machine, et en vert les réseaux utilisateur-utilisateur. Les paradigmes en caractères italiques légers méritent certes d’être mentionnés pour leur importance historique mais ont aujourd’hui disparu ou été marginalisés. Le paradigmes en caractères ordinaires est encore tout à fait d’actualité. Les paradigmes en caractères gras et soulignés sont la norme actuelle (les 3 premiers), encore en évolution ou même émergeant (le dernier). Les flèches remontant au paradigme originel symbolisent le fait qu’en dépit d’évolutions technologiques aussi profondes qu’impressionnantes, des paradigmes modernes sont en fait revenus sous d’autres déguisements au paradigme original pour une série d’avantages qu’il présentait, comme les suivantes vont mettre en évidence en esquissant brièvement les caractéristiques et différences entre ces différents paradigmes successifs. La partie droite de la planche établit un parallèle entre ces paradigmes et quelques réseaux et standards célèbres dans l’histoire des réseaux. => Mort ou renaissance de la démocratie ?

Un zoo d’applications Manipulant un ou plusieurs types de données (texte, graphique, image, animation, audio, video, etc.) Offrant une variété de connectivités 1-à-1 1-à-plusieurs (e-mail, blogs, twitter, facebook) plusieurs-à-plusieurs (chat, skype, wikis…) De façon synchrone ou asynchrone Avec ou sans enregistrement d’un journal (log) Laissant producteurs d’information la pousser (= Push, p.ex. spam…) ou consommateurs la tirer (= Pull, p. ex. RSS…) Avec ou sans réplique locale (p.ex. POP vs. IMAP) Avec ou sans possibilité de contribuer à la structure et l’indexation (delicio.us, wikipedia, google…) Avec ou sans possibilité de voter / décider (doodle, surveymonkey…)