Le Web

a) Mise en service d'ARPANET : 1969 ; proposition de Tim Berners-Lee : 1989 ; navigateur Mosaic : 1993 ; création du W3C : 1994.

b) Le CERN est le laboratoire européen de physique des particules, situé près de Genève, à la frontière franco-suisse. Des chercheurs du monde entier y travaillent et devaient partager leurs documents à distance. Tim Berners-Lee imagine des documents reliés par des liens hypertextes, consultables depuis n'importe quel ordinateur du réseau.

c) Les dates contredisent le camarade : ARPANET, ancêtre d'Internet, fonctionne dès 1969, le Web est proposé en 1989, soit vingt ans plus tard. Ce ne sont pas non plus les mêmes objets : Internet est le réseau qui relie les machines, le Web est une application qui l'utilise, comme le courriel. Le Web a besoin d'Internet, mais Internet existe sans le Web.

a) Le protocole est écrit avant :// : https. Les échanges entre le navigateur et le serveur sont chiffrés, et le certificat atteste que le serveur possède bien ce domaine.

b) Le nom de domaine va de :// jusqu'au premier / seul : www.parc-exemple.fr. Son domaine de premier niveau, lu à droite, est .fr.

c) Le chemin va du premier / jusqu'au ? : /randonnees/liste.php, c'est-à-dire le fichier liste.php du dossier randonnees.

d) Après ?, les paramètres sont séparés par & : massif = ecrins et duree = 3. Le programme liste.php s'en sert pour choisir les randonnées à afficher.

e) #carte est une ancre : le navigateur fait défiler la page jusqu'à l'élément nommé « carte ». Elle n'est pas envoyée au serveur.

a) Tout s'est bien passé : 200 (OK).

b) La ressource demandée n'existe plus : 404 (Not Found).

c) L'erreur vient du serveur lui-même : 500 (Internal Server Error).

d) La ressource a changé d'adresse de façon définitive : 301 (Moved Permanently) ; le navigateur suit la nouvelle adresse sans intervention.

e) Le premier chiffre donne la famille de la réponse : 2 = succès, 3 = redirection, 4 = erreur liée à la demande du client, 5 = erreur du serveur. En b), la demande porte sur une page inexistante : l'erreur est côté client (4xx), même si le lien est mal entretenu. En c), la demande est correcte mais le serveur échoue : erreur côté serveur (5xx).

a) La première ligne donne la méthode POST et la ressource /inscription. L'en-tête Host désigne le serveur : club-echecs-exemple.fr.

b) Deux paramètres : pseudo = lea_k et niveau = debutant. Avec la méthode POST, ils sont placés dans le corps de la requête, après la ligne vide, et non dans l'URL.

c) Le navigateur renvoie au serveur le cookie session que ce site lui a déposé plus tôt. Le serveur reconnaît ainsi le même visiteur d'une page à l'autre, alors que chaque requête HTTP est indépendante.

d) Oui. Avec HTTP, la requête entière (en-têtes et corps) circule en clair sur le réseau. Le fait que les données ne soient pas dans l'URL ne les protège pas : quiconque capte le trafic du Wi-Fi peut lire le pseudo et même le cookie de session. Seul HTTPS chiffrerait ces échanges.

a) Les données du formulaire apparaissent dans l'URL, après le ? : le formulaire utilise la méthode GET.

b) On garde le même domaine et le même chemin, puis on écrit les trois paramètres séparés par & :
https://www.mediatheque-exemple.fr/catalogue?auteur=Sand&type=theatre&page=2
L'ordre des paramètres n'a pas d'importance.

c) Le ? n'apparaît qu'une seule fois : il sépare le chemin des paramètres. Les paramètres suivants sont séparés par &. Ici, le serveur lit un seul paramètre, auteur, de valeur « Sand?type=theatre » : la recherche échoue ou renvoie un mauvais résultat.

d) Avec GET, l'identifiant et le mot de passe seraient écrits dans l'URL : ils resteraient dans l'historique, pourraient être partagés en copiant le lien et apparaîtraient dans les journaux du serveur. On utilise donc POST, et en HTTPS.

a) Pour chaque mot, on liste les pages qui le contiennent :
volcan → P1, P2, P4 ; lave → P1, P3 ; Islande → P1, P2 ; Auvergne → P3, P4 ; randonnée → P1, P4.

b) On garde les pages communes aux deux listes : {P1, P2, P4} et {P1, P2} ont en commun P1 et P2.

c) {P1, P3} et {P3, P4} n'ont en commun que P3.

d) P2 reçoit 7 liens, P1 seulement 2 : P2 est jugée plus populaire. Ordre affiché : P2, puis P1.

e) Le Web compte des milliards de pages : les explorer à chaque requête prendrait des heures. L'index est construit à l'avance ; y chercher un mot est quasi instantané, ce qui permet de répondre en une fraction de seconde. En contrepartie, une page très récente peut ne pas encore y figurer.

a) Un cookie est interne s'il appartient au domaine du site visité. session_id et theme ont le domaine journal-exemple.fr : ils sont internes. _trk appartient à pub-regie-exemple.com, un autre domaine : c'est un cookie tiers, déposé par une publicité ou un script intégré à la page.

b) session_id disparaît à la fermeture du navigateur : il sert à reconnaître la visite en cours (connexion au compte, par exemple). theme dure 180 jours : il mémorise une préférence d'affichage (mode sombre, par exemple).

c) La régie publicitaire place ses contenus sur de nombreux sites. Sur chacun, le navigateur lui renvoie le même cookie _trk : la régie reconnaît le même identifiant et reconstitue la liste des sites visités par Inès, pour lui proposer des publicités ciblées.

d) Les cookies de session et de préférence d'affichage sont nécessaires au service demandé. _trk, cookie publicitaire, exige le consentement préalable (loi Informatique et Libertés et RGPD). Si Inès bloque les cookies tiers, le navigateur refuse de stocker et de renvoyer _trk ; session_id et theme continuent de fonctionner.

1. On lit la colonne « Liens vers » : A reçoit les liens de C et D, soit 2 ; B reçoit celui de A, soit 1 ; C reçoit ceux de A, B et D, soit 3 ; D n'en reçoit aucun. Selon ce critère, C est la plus populaire.

2. Parts données au premier tour : A (score 1, 2 liens) donne 0,5 à B et 0,5 à C ; B donne 1 à C ; C donne 1 à A ; D donne 0,5 à A et 0,5 à C.
A = 1 + 0,5 = 1,5 ; B = 0,5 ; C = 0,5 + 1 + 0,5 = 2 ; D = 0.

3. 1,5 + 0,5 + 2 + 0 = 4. C'est général : chaque page distribue exactement tout son score, rien n'est créé ni perdu, donc le total reste égal au total de départ, 4 × 1 = 4.

4. Deuxième tour, à partir de A = 1,5, B = 0,5, C = 2, D = 0 :
A reçoit 2 de C et 0 de D : A = 2 ; B reçoit 1,5 ÷ 2 = 0,75 : B = 0,75 ; C reçoit 0,75 de A, 0,5 de B et 0 de D : C = 1,25 ; D = 0.
Vérification : 2 + 0,75 + 1,25 + 0 = 4. D reste à 0 : aucune page ne pointe vers elle, elle ne reçoit donc jamais rien, et à partir du deuxième tour elle n'a plus rien à distribuer. Les scores de A et C varient encore : les vrais moteurs répètent le calcul jusqu'à ce qu'il se stabilise (ici vers A = C = 1,6 et B = 0,8).

5. Avec le décompte simple, la page du webmestre gagne 50 liens et passe devant toutes les autres. Avec le score du document 2, les 50 pages vides ne reçoivent aucun lien : comme D, leur score tombe à 0 dès le premier tour, et elles ne transmettent plus rien ensuite. La page du webmestre profite de leurs parts au premier tour seulement : dès le deuxième tour, elle ne garde que ce que lui apportent les liens venus de vraies pages populaires (et retombe à 0, comme D, si aucune ne pointe vers elle). Ce qui compte n'est pas le nombre de liens, mais la popularité des pages qui les donnent.

1. Chaque fichier fait l'objet d'une requête : 1 page + 2 feuilles de style + 5 images + 2 scripts = 10 requêtes. Elles visent 3 domaines : www.rando-exemple.fr, img.rando-exemple.fr et stats.mesure-exemple.com.

2. Pages et styles : 36 + 18 + 7 = 61 Ko. Images : 240 + 315 + 128 + 96 + 410 = 1 189 Ko. Scripts : 152 + 44 = 196 Ko.
Total : 61 + 1 189 + 196 = 1 446 Ko.

3. 1 446 Ko = 1 446 000 octets = 1 446 000 × 8 = 11 568 000 bits. Le débit est 4 Mbit/s = 4 000 000 bits par seconde.
Durée : 11 568 000 ÷ 4 000 000 = 2,892 s, donc plus de 2,8 s. Et c'est un minimum, puisqu'on a négligé l'établissement des connexions.

4. Seconde visite : 36 Ko = 36 000 × 8 = 288 000 bits, soit 288 000 ÷ 4 000 000 = 0,072 s.
Gain : (2,892 − 0,072) ÷ 2,892 × 100 ≈ 97,5 %. Le cache évite de retélécharger les fichiers qui n'ont pas changé.

5. accueil.php est un programme : le serveur l'a exécuté pour fabriquer la page, puis n'a envoyé que le HTML produit ; le code PHP ne quitte jamais le serveur. Le navigateur interprète le HTML et le CSS, et exécute les scripts app.js et stats.js (côté client). stats.js vient d'un domaine tiers : la société de mesure d'audience apprend que l'internaute a visité cette page, ce qui relève du pistage et suppose, s'il n'est pas limité à une mesure strictement nécessaire, son consentement.

1. Avec HTTP, tout circule en clair : l'espion connaît le site, la page, le contenu reçu et surtout l'identifiant et le mot de passe de Tom. Il peut se connecter au forum à sa place, et essayer le même mot de passe sur d'autres comptes si Tom le réutilise.

2. Avec HTTPS, la requête et la réponse (chemin, formulaire, contenu) sont chiffrées : seul le serveur de la banque peut les déchiffrer. En revanche, avant tout échange chiffré, le navigateur doit trouver l'adresse IP du serveur (requête DNS) et annoncer à quel site il se connecte : ces informations d'acheminement circulent avant le chiffrement, d'où un domaine et un volume visibles.

3. Le domaine s'arrête au premier / seul : www.banque-exemple.fr.compte-securite.net. On le lit de droite à gauche : domaine de premier niveau .net, puis compte-securite. Le vrai domaine est compte-securite.net ; « www.banque-exemple.fr » n'en est qu'un sous-domaine choisi pour tromper.

4. Le cadenas prouve seulement que les échanges sont chiffrés et que le certificat correspond au domaine affiché, ici compte-securite.net. Un escroc peut facilement obtenir un certificat pour son propre domaine. Le cadenas ne dit rien de l'identité réelle ni de l'honnêteté du site : c'est une page d'hameçonnage.

5. Par exemple : activer le mode « HTTPS uniquement » du navigateur, qui aurait bloqué ou signalé la connexion 1 ; ne jamais cliquer sur un lien reçu pour se connecter, mais taper soi-même l'adresse de la banque ; utiliser un mot de passe différent pour chaque site.