Le World Wide Web
Qu’est-ce que le web ?
Le Web (ou World Wide Web) est une des applications du réseau Internet qui permet le partage de documents liés entre eux et appelés “pages Web”.
Une page Web peut contenir du texte, des images, des programmes, des liens vers d’autres pages web…
Afin d’afficher une page Web, le navigateur (client) doit en récupérer tous les éléments depuis le(les) ordinateur(s) (serveur(s)) où ils se trouvent.
Le Web est inventé le 12 mars 1989 au CERN, près de Genève, par le Britannique Tim Berners-Lee et le Belge Robert Cailliau, plusieurs années après Internet.
Mais son utilisation par le grand public ne commence réellement qu’en 1994, lors de la fondation du W3C (WWW Consortium) par le CERN et le MIT qui s’occupe de la normalisation et des développements du web.
L’application « web » est répartie sur le client et le serveur qui dialoguent selon un protocole appelé HTTP.
Le Web, et les couches sur lesquelles il s’appuie, sont modélisables de manière assez fidèle au modèle OSI :
N° |
Couche |
Norme |
7 | Application (Application) |
Web |
6 | Présentation (Presentation) |
HTML / XML |
5 | Session (Session) |
HTTP / HTTPS |
4 | Transport (Transport) |
TCP |
3 | Internet |
IP |
2 | Liaison de données (Data link) |
Ethernet / xDSL |
1 | Physique (Physical) |
RJ45 / RJ11 / RJ12 Câbles Cat. 5 et + |
Qu’est-ce qu’un serveur HTTP ?
HTTP est un protocole de communication entre deux logiciels, situé sur la couche application du modèle TCP/IP.
Il permet à un client (typiquement un navigateur web) de récupérer des documents hypermédia (comme HTML) auprès d’un serveur web.
- le client : un logiciel de type navigateur web (Firefox, Chrome, Edge, …) installé sur la machine de l’utilisateur.
- le serveur : un logiciel appelé serveur web, qui reste en permanence à l’écoute des demandes qui lui parviennent.
Le protocole fonctionne par l’intermédiaire de requêtes émises par le client et de réponses fournies par le serveur.
Le serveur web fait essentiellement 3 choses :
- Écouter les requêtes HTTP entrantes,
- Gérer cette demande,
- Renvoyer une réponse HTTP au logiciel qui a envoyé la requête.
Les principaux logiciels de serveur HTTP sur le Web sont :
- Apache
- NGinx
- Microsoft IIS
- Cloudflare
source : https://w3techs.com/technologies/cross/web_server/ranking
Communication HTTP
Dans une communication HTTP, Client et Serveur réalisent chacun des tâches bien définies :
Client (navigateur) | Serveur web |
|
|
Pour faire l’affichage de la page, le navigateur se base sur :
- les valeurs par défaut du navigateur,
- les préférences de l’utilisateur fixées dans le navigateur,
- les valeurs fixées dans le document ou les feuilles de styles.
L’affichage peut parfois commencer avant que toutes les ressources ne soient chargées, mais il faut utiliser du code (JavaScript, …) pour cela.
Une page web moderne peut nécessiter près de 100 requêtes : la page info.blaisepascal.fr par exemple, en nécessite plus de 50.
URL
L’utilisateur souhaite consulter une page web : il utilise un navigateur et saisi dans la barre d’adresse l’URL (Uniform Resource Locator) de cette page.
Par exemple :
http://info.blaisepascal.fr/nsi-serveur-http
Un URL est composé de plusieurs informations :
exemples | valeur par défaut | ||
Comment ? | nom du protocole | http:// ou https:// pour une communication chiffrée |
http:// |
Ou ? | nom d’hôte (ou adresse IP sur le réseau) de la machine sur laquelle le serveur est lancé |
info.blaisepascal.fr ou bien 217.160.0.206 |
|
port que le serveur « écoute » | :80 ou encore :8080 | :80 | |
Quoi ? | ressource à obtenir un nom de fichier (.html, .php , …) |
/index.php ou encore /animaux/lion.html |
défini par dans la configuration du serveur souvent /index.html ou /index.php |
paramètres |
?user=Marcel&pays=France |
Remarque : par défaut, le serveur web HTTP utilise le port 80. Si aucun port n’est spécifié dans la barre d’adresse du navigateur, c’est ce port qui est automatiquement interrogé.
Requête HTTP
A partir de l’URL donné par l’utilisateur, le navigateur élabore une requête HTTP :
- la ligne de requête découpée en méthode URL Version
exemple : GET / HTTP/1.1- méthode GET, pour obtenir une ressource
- URL racine (/) du site web
- version du protocole HTTP : 1.1
- méthode GET, pour obtenir une ressource
- les champs de l’en-tête permettant de préciser la demande.
- Le nom de l’hôte (Host)
- Le navigateur web (User-Agent)
- Les types de donnée qu’il accepte (Accept)
- Les langages préférés (Accept-Language)
- L’encodage des caractères préféré (Accept-Encoding)
- …
- une ligne vide ;
- le corps de la requête (éventuellement).
Exemple de requête HTTP :
GET / HTTP/1.1 Host: info.blaisepascal.fr User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive Cookie: ......... Upgrade-Insecure-Requests: 1 Cache-Control: max-age=0
Remarque : cette requête ne contient pas de données : elle ne fait que demander (méthode GET) une ressource.
Réponse HTTP
Le serveur web renvoie alors une réponse HTTP de la forme suivante :
- la ligne de status découpée en Version Code Signification ;
Le serveur peut utiliser une version différente du protocole HTTP.
Le code renvoyé indique si tout s’est bien passé ou si au contraire une erreur s’est produite (voir codes de status) - les champs de l’en-tête où l’on apprend le type de serveur, la date, le type MIME de la réponse, sa longueur, etc. ;
- une ligne vide ;
- les données (fichiers .html , images, Javascript, …).
Exemple de réponse HTTP :
HTTP/2.0 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 23736 Connection: keep-alive Keep-Alive: timeout=15 Date: Sat, 04 Jan 2020 15:30:55 GMT Server: Apache Vary: Accept-Encoding,Cookie Content-Encoding: gzip X-Powered-By: PHP/7.2.25 Pragma: no-cache Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 P3P: CP="ALL DSP NID CURa ADMa DEVa HISa OTPa OUR NOR NAV DEM" X-Pingback: http://info.blaisepascal.fr/xmlrpc.php Link: <http://info.blaisepascal.fr/wp-json/>; rel="https://api.w.org/", <http://info.blaisepascal.fr/>; rel=shortlink
Méthodes HTTP
Les méthodes disponibles pour HTTP sont les suivantes : GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH.
- GET permet d’obtenir une ressource.
- PUT, DELETE et PATCH permettent de modifier des données sur le serveur : il est évidemment nécessaire d’être authentifié pour réaliser ces changements et le serveur doit être configuré pour autoriser ces changements.
- HEAD permet d’obtenir seulement l’en-tête de la réponse.
- POST permet d’envoyer une ressource au serveur : cette méthode est souvent utilisée lors du remplissage d’un formulaire.
Codes de status (ou codes d’état)
Les codes de statuts commencent par 100, 200, 300, 400 ou 500.
- 200 et suivants indiquent une réussite.
- 300 et suivants indiquent un déplacement de la ressource demandée.
- 400 et suivants indiquent une erreur du client : requête mal formulée ou ressource inexistante (la fameuse erreur 404)
- 500 et suivants indiquent une erreur du serveur.
HTTP est sans état, c’est-à-dire qu’il n’y a pas de lien entre deux requêtes réalisées sur la même connexion. Cela pose problème en particulier sur des sites de commerce en ligne avec un panier d’achat que l’on remplit au fur et à mesure.
Mais HTTP n’est pas sans session : on ajoute des cookies au flux HTTP, que l’on stocke sur le client, ce qui permet de maintenir une session pour l’utilisateur et donc de remplir le panier d’achat !
Versions HTTP
HTTP a connu plusieurs révisions :
- Version 1.0 : chaque requête/réponse doit faire l’objet de l’établissement puis de la fermeture d’une connexion TCP/IP.
- Version 1.1 : plusieurs requêtes peuvent se succéder au sein de la même connexion TCP/IP (keep-alive) mais si une requête n’aboutit pas, elle ralentit les suivantes. Une technique d’optimisation consiste à ouvrir plusieurs connexions TCP/IP en parallèle sur le même site mais les navigateurs modernes limitent le nombre de connexions parallèles à 6.
- Version 2.0 : plusieurs requêtes en parallèle gérées au sein de la même connexion TCP/IP. Possibilité de push (les données sont envoyées au client alors qu’il ne les a pas encore demandées). Compression des en-têtes.
Ces révisions permettent d’accélérer le chargement des pages web qui ont une certaine tendance à l’embonpoint !
De plus, les données sont mises en cache dans le navigateur. Cela permet de ne pas les recharger auprès du serveur, lorsqu’on utilise les boutons Précédent et Suivant du navigateur par exemple (code d’état 304 Not Modified).
Sécurité
HTTP transmet le texte brut. Pour que les données soient transmises de manière sécurisée (chiffrées), on utilise le protocole HTTPS (HyperText Transfer Protocol Secure).
Lorsque la communication avec un site WEB est sécurisée, la barre d’adresse commence par un cadenas :
HTTPS est une association de HTTP et de SSL. SSL (Secure Socket Layer) vient en complément de TCP/IP. Ses avantages sont :
- la confidentialité : on ne peut pas espionner les données. La connexion est chiffrée.
- l’intégrité des données : on ne peut pas les modifier.
- l’authentification : on est sûr de l’identité du client et du serveur grâce à des certificats présents dans le navigateur, fournis par des sociétés tierces à qui on fait implicitement confiance.
L’évolution récente de SSL est TLS (Transport Layer Security) qui accompagne la version 2 de HTTP. De plus en plus de sites WEB basculent en HTTPS sous la pression des navigateurs internet. En effet, au lieu d’indiquer simplement qu’un site en HTTPS est sécurisé avec le fameux cadenas, les navigateurs indiquent que les sites HTTP ne sont pas sécurisés. Il faut bien se rappeler que seule la communication est sécurisée : rien ne nous assure que les données confidentielles fournies au site sont elles-mêmes protégées sur le serveur.
Analyse des requêtes
La plupart des navigateurs évolués possèdent des outils de développement :
- console : visualisation des requêtes
- inspecteur : visualisation du code
- …
Sources : https://cache.media.eduscol.education.fr/file/NSI/77/1/RA_Lycee_G_NSI_ihm_interaction_client_serveur_1170771.pdf
https://perso.univ-lyon1.fr/olivier.gluck/Cours/Supports/LIFASR2/LIFASR2-CM4.pdf