HTTPS RESEAUX ET SECURITE

Objectifs du cours HTTP et réseaux et prérequis

Bienvenue pour ce nouveau cours concernant le protocole HTTP et plus largement le communication réseau et la
sécurité. Dans ce cours, nous allons comprendre ensemble la place fondamentale de ce protocole dans tout échange se
passant sur le web et apprendre comment il fonctionne et comment il s’intègre dans une suite plus complète de
protocoles qui permettent aux échanges réseaux d’exister.
Avant tout, je tiens à préciser que ce cours va être en essence plus théorique que les précédents car la plupart des
fonctionnalités de HTTP sont mises en place et utilisées automatiquement autant au niveau du client que du serveur.
Pour autant, il reste très intéressant de bien comprendre comment fonctionne HTTP car cela devrait débloquer de
nombreuses clefs de compréhension pour la suite de votre carrière de développeur.
Il n’est pas strictement nécessaire de connaitre un quelconque langage informatique pour attaquer ce cours. Cependant,
avoir une connaissance préalable de la relation client-serveur et comprendre dans son ensemble à quel moment et
pourquoi on utilise les principaux langages comme HTML, CSS, JavaScript et PHP peut aider à rentrer plus facilement dans
ce cours et à en tirer pleinement parti.

Pédagogie et méthodologie du cours

Ce cours HTTP et réseaux va être plus théorique que les autres présents sur ce site et introduit de nombreuses nouvelles
notions et des modèles abstraits dont il n’est pas forcément évident de comprendre l’intérêt au premier abord.
Nous allons donc dans ce cours essayer d’être le plus progressif possible et de bien expliquer, notamment dans les
premières leçons, certains concepts fondamentaux afin d’ensuite pouvoir se diriger vers de nouvelles notions plus
avancées.

LES CONCEPTS HTTP FONDAMENTAUX

1) Introduction au HTTP, le protocole de transfert hypertexte

Le protocole de transfert hypertexte ou HTTP (HyperText Transfer Protocol) est, avec le langage HTML et les adresses web
l’une des trois fondations qui permettent au World Wide Web tel qu’on le connait aujourd’hui d’exister.
HTTP (HyperText Transfer Protocol ou Protocole de Transfert Hypertexte en français) est un protocole de communication
permettant de récupérer et d’envoyer des ressources hypermédia. Au départ, HTTP a été créé pour permettre de transfert
de documents HTML uniquement puis ses usages se sont rapidement étendus pour permettre de transférer d’autres
types de ressources comme des images, des vidéos ou d’autres types de fichiers.
Un protocole est tout simplement un ensemble de règles. Dans un contexte réseau, un protocole est un ensemble de
règles qui régissent les échanges de données.

Pourquoi apprendre comment fonctionne HTTP ?

Comprendre comment fonctionne HTTP n’est pas obligatoire au sens strict du terme pour développer des pages web.
Cependant, cela vous permettra d’avoir une bien meilleure compréhension du fonctionnement du web en général et de «
ce qu’il se passe en arrière-plan » lors d’un échange web et cela vous aidera également à mieux comprendre certaines
erreurs qui peuvent survenir sur un site et comment les résoudre.
De la même manière, il est intéressant de comprendre le modèle réseau complet qui permet aux informations d’aller
d’un point d’origine à un point d’arrivée dans lequel s’insère HTTP. Cela vous permettra d’avoir une bonne vision
d’ensemble du fonctionnement de l’échange de données entre deux machines.

HTTP, un protocole de transfert client – serveur

Le protocole HTTP est basé sur un modèle client-serveur. Dans les modèles de communication client-serveur, le client est
toujours celui qui demande à accéder (demande de récupérer) une ressource tandis que le serveur est toujours celui qui
va répondre à la demande (qui va « servir » la ressource).
Dans la majorité des cas, le client va être un navigateur. Par exemple, lorsqu’un visiteur cherche à accéder à l’une de nos
pages web, il va taper une URL dans son navigateur. Le navigateur va alors demander au serveur sur lequel est stockée la
page de la lui renvoyer. La demande du client est appelée une requête HTTP.
Un serveur est un ordinateur très puissant donc l’unique rôle est de stocker des ressources et de les servir aux clients
lorsque ceux-ci les demandent. Pour se faire, un serveur doit être toujours allumé et connecté à d’autres serveurs de
manière à pouvoir être accessible.
Notez ici qu’une ressource peut être divisée en plusieurs parties et que chaque partie peut être stockée sur une machine
différente. Au contraire, une même machine peut stocker des ressources appartenant à différents sites. On utilisera
généralement le terme « le serveur » de manière indiscriminée pour désigner une machine à part entière, une partie
d’une machine ou plusieurs machines à partir du moment où leur rôle est de stocker et de servir des ressources.
Les requêtes et les réponses HTTP (qu’on appelle également messages HTTP) sont au cœur du protocole de transfert
hypertexte. Nous étudierons en détail comment elle sont créées et de quoi elles sont composées dans la suite de ce
cours.

1/30
HTTP, un protocole sans état et évolutif
HTTP est l’une des trois inventions majeures qui ont permis la création du web. HTTP est donc présent depuis la création
du web et a su évoluer jusqu’à aujourd’hui pour répondre à l’évolution et à la diversification des usages du web et pour
faire en sorte qu’ils soient possibles.
Au début du web, les pages n’étaient composés que de HTML et ne faisaient pas appel à des ressources externes. Le
client n’avait donc qu’à effectuer une requête au serveur afin que celui-ci lui renvoie le document HTML.
Aujourd’hui, les pages web sont composées de différentes ressources : une structure HTML, des ressources CSS,
JavaScript, des images, vidéos, etc.
Les usages se sont également diversifiés : au départ du web, la seule opération possible en tant qu’utilisateur était la
récupération et la visualisation d’une ressource. Aujourd’hui, on peut également envoyer ou modifier des informations
(via des formulaires HTML notamment).
Tout cela est possible car HTTP a su évoluer et ajouter de nouveaux composants / fonctionnalités pour fournir davantage
de possibilité d’échanges. Toutefois, comme les usages et les capacités du web étaient au départ très limités, les règles
composant HTTP n’ont pas été formulées avec une quelconque idée de performance ou d’optimisation et cela représente
le défi principal de HTTP.
Par exemple, deux des principes de base du HTTP sont qu’une requête ne peut récupérer qu’une seule ressource à la
fois / n’effectuer qu’une action à la fois et que HTTP est un protocole sans état.
Lorsqu’on dit que HTTP est un protocole sans état, cela signifie que HTTP n’a pas besoin que le serveur conserve des
informations sur un client entre deux requêtes. Autrement dit, chaque nouvelle requête peut agir de manière totalement
indépendante et n’a pas de lien à priori avec les requêtes précédentes ou suivantes.
Les pages web actuelles sont composées de nombreuses ressources et vont donc demander au client d’effectuer
plusieurs requêtes. Généralement, le client va demander qu’on lui renvoie le document HTML demandé, puis va
commencer à le lire et va ensuite effectuer de nouvelles requêtes au serveur à chaque fois qu’il va tomber sur une autre
ressource incluse dans le document.
Chaque nouveau jeu de requête-réponse implique un aller-retour des données, ce qui prend du temps et entraine donc
de la latence (un temps d’attente) pour l’utilisateur. Des techniques comme les connexions parallèles, persistantes ou en
pipelines ont été progressivement formulées et implémentées pour résoudre ces problèmes de performance. Nous
étudierons évidemment ces techniques en détail dans la suite du cours.
Pour le moment, contentez-vous de retenir que l’un des enjeux majeurs du HTTP depuis quelques années est un enjeu lié
à l’optimisation des performances pour « rendre le web plus rapide ».

HTTP et les modèles TCP/IP et OSI

HTTP est un protocole qui définit la forme de la communication entre deux machines, c’est-à-dire la syntaxe des
messages envoyés afin que les deux machines puissent effectivement communiquer.
Cependant, HTTP n’indique pas comment les messages doivent transiter pour partir d’une machine A et arriver à une
machine B.
En fait, HTTP est un protocole qui ne sert à définir qu’une partie de la communication entre deux machines et qui s’insère
dans un modèle réseau beaucoup plus large.
Aujourd’hui, il existe deux modèles réseaux de référence : les modèles modèle OSI (Open Systems Interconnection) et
TCP/IP. Ces deux modèles permettent de fournir un cadre global pour la communication entre deux machines.
La chose importante à retenir de ces deux modèles pour le moment est qu’ils définissent tous les deux différentes «
couches » de communication. Grosso-modo, ces deux modèles découpent la communication entre deux machines en
différentes couches qui vont chacune définir les règles d’un point précis de la communication.
Chaque couche va contenir ses propres protocoles et les protocoles d’un modèle réseau ne vont pouvoir appartenir qu’à
une couche précise. L’idée principale derrière de genre de modèle est de pouvoir faire évoluer les différents protocoles
de manière indépendante (sans avoir à modifier l’ensemble du processus de communication) et de nous permettre
d’implémenter tel ou tel protocole de telle couche.
Le modèle OSI par exemple est un modèle théorique composé de 7 couches différentes : application, présentation,
session, transport, réseau, liaison et physique. Les protocoles du modèle OSI vont pouvoir appartenir à l’une ou l’autre de
ces couches.
L’inconvénient du modèle OSI est qu’il reste difficile à appliquer de manière pratique pour le web car certains protocoles
vont « logiquement » couvrir plusieurs couches.
Pour cela, un autre modèle a été formulé : le modèle TCP/IP, encore appelé « modèle Internet ». Ce modèle, composé
uniquement de 4 couches nommées couches application, transport, internet et accès réseau traduit moins fidèlement la
réalité des échanges entre deux machines mais est beaucoup plus pratique à mettre en place. C’est le modèle de
référence utilisé pour les échanges sur le web.
Nous allons étudier chacun de ces deux modèles en détail dans la suite du cours. Pour le moment, vous pouvez retenir
qu’HTTP est un protocole de la couche application dans chacun de ces deux modèles.

HTTP et HTTPS
HTTP est un protocole de transfert de la couche application des modèles OSI et TCP/IP. Ce protocole permet in-fine l’envoi
et la récupération ressources hypermedias.
Il y a quelques années, la plupart des utilisateurs du web ne faisaient pas confiance aux sites et n’osaient pas acheter
sur le web car ils devaient transmettre des informations sensibles comme des numéros de carte bleu.
Netscape a alors inventé un protocole de sécurisation des échanges de données appelées SSL pour Secure Sockets Layer.
L’IETF (groupe chargé de la standardisation de certains protocoles et notamment chargé de l’évolution de HTTP) a
ensuite continué son développement en le renommant TLS (Transport Layer Security).
TLS est aujourd’hui la norme dans le chiffrement / cryptage des échanges de données sur le net. HTTPS est simplement
une variante de HTTP qui implémente ce protocole de sécurisation.
Pour information, un serveur HTTP utilise le port 80 par défaut. Un serveur supportant HTTPS utilisera le port 443 par
défaut. Un « port » permet de distinguer différents interlocuteurs (différents programmes ou applications).

2/30
2) Requête, réponse et session HTTP

HTTP est un protocole qui décrit la façon dont des données doivent être transférées à travers des réseaux.
Le transfert de données se passe en deux temps : tout d’abord, un client (généralement un navigateur) effectue une
requête HTTP (une demande) qui va être transmise à un serveur. Le serveur répond ensuite en renvoyant une réponse
HTTP.
Notez bien que le HTTP n’a pour but que de définir la forme de ces messages et n’a pas pour objet d’indiquer les moyens
de transfert des messages en soi. Cette tâche est laissée à d’autres protocoles qui fonctionnent avec HTTP mais à
d’autres niveaux (d’autres couches) des modèles TCP/IP ou OSI.

Structure générale d’une requête et d’une réponse HTTP

Les requêtes et réponses HTTP partagent une structure similaire. Ces messages sont composés de :
• Une ligne de départ qui permet de décrire la requête et la façon dont elle doit être traitée ou son état de traitement ;
• Un ensemble (facultatif) d’en-têtes HTTP ;
• Une ligne vierge ;
• Un corps de message (facultatif) qui contient des données associées au message HTTP.

Structure détaillée d’une requête HTTP

Une requête HTTP est composée d’une ligne initiale suivie éventuellement d’en-têtes HTTP suivis d’une ligne vierge
suivie éventuellement d’un corps de requête.

La première ligne d’une requête HTTP permet de préciser la requête HTTP. Celle-ci est composée de :
• La méthode de requête utilisée qui sert à indiquer le type de requête effectuée : simple récupération de ressources,
envoi de données sur le serveur, etc. ;
• La cible de la requête (si applicable) qui va généralement prendre la forme d’une URL ou d’un chemin absolu ;
• La version HTTP utilisée pour la requête (qui sert également à indiquer la version attendue pour la réponse).
Sous cette ligne de départ, un ou plusieurs en-têtes HTTP peuvent être ajoutés. Ces en-têtes permettent de préciser la
requête ou d’ajouter des informations de contexte. Les en-têtes vont par exemple nous servir à indiquer la langue
préférée pour une ressource demandée, à indiquer comment la connexion avec le serveur doit être établie, le type et le
poids du corps de requête, etc.
Il existe de très nombreux en-têtes HTTP différents et nous allons étudier les plus communs dans la suite de ce cours.
Dans un message HTTP, chaque en-tête doit être décrit sur une ligne.
Après les lignes d’en-tête, une requête HTTP doit obligatoirement comporter une ligne vierge puis peut enfin comporter
un corps de requête. Le corps de requête permet de transmettre des données au serveur et toutes les requêtes n’en ont
pas.
Par exemple, la plupart des requêtes GET (permettant de récupérer des ressources) n’ont pas besoin d’ajouter un corps. En
revanche, des requêtes comme POST qui servent à envoyer des informations au serveur vont transmettre ces informations
dans le corps de la requête.
Note : depuis HTTP/2, les données sont encodées en binaire et ne sont donc plus lisibles pour un humain.

Types de requêtes et liste des méthodes HTTP

A l’origine, lors de la création de HTTP, le web se limitait à un ensemble de page composées uniquement de HTML et la
seule opération possible pour un client était de récupérer ces documents pour que le visiteur puisse les consulter.
Par la suite, la liste des opérations possibles pour le visiteur s’est étoffée, notamment grâce aux formulaires HTML qui
permettent à un visiteur d’envoyer ou de modifier des informations sur le serveur.
Chaque type d’opération correspond à un type de requête HTTP. Les différents types de requêtes sont eux-mêmes définis
par l’utilisation de méthodes HTTP différentes.
Ces méthodes HTTP permettent d’indiquer au serveur quelle opération le client souhaite effectuer. Le méthode GET par
exemple permet d’indiquer qu’on souhaite récupérer une ressource, tandis que POST est utilisée pour transmettre des
données en vue d’un traitement à une ressource, DELETE est utilisée pour indiquer qu’on souhaite supprimer une
ressource, etc.
HTTP est un protocole très évolutif et de nouvelles méthodes pourront être ajoutées dans le futur sans limitation.
Les méthodes disponibles à l’heure actuelle sont les suivantes :
• GET permet de demander une ressource sans la modifier ;

3/30
• POST permet de transmettre des données dans le but de manipuler une ressource ;
• PUT permet de remplacer ou d’ajouter une ressource sur le serveur ;
• DELETE permet de supprimer une ressource du serveur ;
• HEAD permet de demander des informations sur la ressource sans demander la ressource elle-même ;
• PATCH permet de modifier partiellement une ressource ;
• OPTIONS permet d’obtenir les options de communication d’une ressource ou du serveur ;
• CONNECT permet d’utiliser un proxy comme un tunnel de communication ;
• TRACE permet de tester et d’effectuer un diagnostic de la connexion et demandant au serveur de retourner la requête
reçue.
Voici également un tableau avec les caractéristiques inhérentes à chaque méthode. Ce tableau pourra vous être utile plus
tard.

Source : developer.mozilla.org

Structure détaillée d’une réponse HTTP

Les réponses HTTP sont également composées d’une ligne de départ (qu’on appelle également ligne de statut),
d’éventuels en-têtes HTTP, d’une ligne vierge et d’une éventuel corps de réponse.

La ligne de statut est composée de la version du protocole, d’un code de statut HTTP indiquant l’état de complétion de la
requête, son succès ou son échec et d’un court texte descriptif lié au code de statut.
Les en-têtes HTTP permettent à nouveau d’ajouter des informations de contexte et de préciser la réponse comme la date
d’envoi de la réponse, des informations relatives au serveur, des informations relatives à la connexion ou encore la mise
en place de cookies.
Finalement, la dernière partie d’une réponse HTTP et le corps et là non plus toutes les réponses n’en ont pas. Le corps
d’une réponse HTTP va permettre par exemple de transmettre la ressource demandée par la requête HTTP.

Liste des codes de statut des réponses HTTP

Les codes de statut HTTP permettent de fournir des informations quant à la complétion (succès) ou la non-complétion
(échec) d’une requête. Les statut code HTTP sont très utiles pour le débogage dans le cas où la requête n’aurait pas
abouti et peuvent également être utilisés pour économiser des ressources.
Les codes de statut HTTP se décomposent en 5 grandes familles :
• Un code 1xx indique une réponse provisoire (non implémenté avec HTTP/1.0) ;
• Un code 2xx (200, 201, 202, 204) indique que la requête a été traitée avec succès ;
• Un code 3xx(300, 301, 302, 304) indique que la requête doit être redirigée ;
• Un code 4xx (400, 401, 403, 404) indique une erreur côté client ;
• Un code 5xx (500, 501, 502, 503) indique une erreur côté serveur.
Les codes de statut à connaitre et à comprendre sont les suivants :

200 OK
Le code de statut 200 (OK) indique que la requête a été traitée avec succès. La réponse du serveur est donc envoyée
sans problème.

301 Moved Permanently

Le statut code HTTP 301 (Moved Permanently) indique que la ressource demandée n’est plus disponible à l’URL indiquée
dans la requête mais a été déplacée vers une autre URL (qui est alors indiquée dans un en-tête Location.
Lorsque le client reçoit une réponse avec un code 301, il va généralement effectuer une nouvelle requête avec la
nouvelle URL fournie pour accéder à la ressource initialement demandée.
En tant que développeur, vous serez amené à paramétrer des redirections lors de changements d’URL. En effet, utiliser
des redirections 301 permet notamment de conserver les liens gagnés sur l’URL d’origine. Nous reviendrons sur les
redirections plus tard dans ce cours.

302 Found et 307

Les codes de statut HTTP 302 (Found) et 307 (Temporary Redirect) servent tous les deux à indiquer une redirection
temporaire, c’est-à-dire une redirection qui n’a pas vocation à perdurer dans le temps. On va utiliser les redirections

4/30
temporaires lors de maintenances notamment.

304 Not Modified

Le code de statut 304 (Not Modified) permet à un serveur d’indiquer à un client que la ressource demandée n’a pas été
modifiée depuis la dernière visite et que celui-ci peut donc utiliser une version placée dans son cache local plutôt que de
télécharger à nouveau la ressource à partir du serveur.
Cela permet de réduire la latence et permet donc à l’utilisateur d’obtenir la ressource demandée plus rapidement.

403 Forbidden
Le code de statut 403 (Forbidden) indique que le serveur a bien compris la requête mais refuse de la compléter. Ce statut
peut être renvoyé suite à un certain nombre de tentative de connexion avec des mauvais identifiants par exemple.

404 Not Found

Le code de statut 404 (Not Found) indique que le serveur n’a pas trouvé la ressource demandée et ne peut donc pas
compléter la requête.

500 Internal Server Error

Le code de statut 500 (Internal Server Error) indique que le serveur a rencontré une condition inattendue qui l’a
empêché de répondre à la demande. Le problème n’est cette fois-ci plus situé côté client mais bien côté serveur.

Comment créer une requête ou une réponse HTTP en pratique ou « à quoi ça sert
tout ça » ?
Ce point est important et devrait vous aider à y voir plus clair pour la suite de ce cours : en pratique, vous n’aurez en
tant que développeur ou webmaster que rarement l’occasion de créer un message HTTP.
En effet, les requêtes HTTP sont formulées par le client (c’est-à-dire dans la majorité des cas le navigateur de vos
visiteurs) et vous n’avez donc quasiment aucun contrôle dessus.
D’un autre côté, les réponses HTTP sont quant-à-elles créées par le serveur et vont en grande partie dépendre de la
configuration de celui-ci. En fonction de votre hébergeur et de votre formule d’hébergement, vous allez avoir plus ou
moins de contrôle sur la configuration de votre espace serveur.
L’intérêt principal d’apprendre le fonctionnement d’HTTP et de comprendre comment fonctionne le transfert de données
dans son ensemble n’est pas de pouvoir directement intervenir dessus.
On apprend tout cela car ça aide grandement à comprendre comment fonctionne un site web, comment et pourquoi
optimiser la vitesse de celui-ci et car cela aide à mieux comprendre les erreurs qui peuvent survenir pour pouvoir les
régler plus rapidement et efficacement.
Ceci étant dit, nous allons apprendre dans ce cours à configurer correctement quelques en-têtes de réponse HTTP pour
servir les objectifs décrits ci-dessus, et notamment les en-têtes liés aux redirections et au cache.

Déroulement d’une session HTTP

Le cycle requête-réponse HTTP s’insère dans un ensemble plus complet qu’on appelle « session HTTP ».
Une « session HTTP » correspond à l’ensemble des échanges qui se passent entre l’établissement d’une connexion et
jusqu’à la déconnexion par le serveur.
Une session HTTP peut ainsi être classiquement divisée en 3 phases distinctes :
1. L’établissement de la connexion par le client ;
2. L’envoi d’une requête HTTP ;
3. L’envoi d’une réponse HTTP.
Pour pouvoir envoyer des données d’un point A (client) à un point B (serveur) et inversement, il faut avant tout établir
une connexion entre ces deux entités. Cette connexion permet notamment aux deux machines de se mettre d’accord sur
certaines modalités du transfert.
Notez bien ici que la phase de connexion n’est pas effectuée par HTTP puisque cela se trouve en dehors du champ
d’influence de ce protocole. Pour être tout à fait précis, le connexion est gérée par les protocoles de la couche transport
du modèle TCP/IP (ou OSI) et donc par le protocole TCP dans la majorité des cas pour HTTP jusqu’à sa version HTTP/2 (qui
est la version de référence aujourd’hui).
Nous détaillerons les fonctions et enjeux de chaque couche des modèles TCP/IP et OSI et étudierons en détail les
protocoles à connaitre comme les protocoles TCP, IP, etc. dans la suite de ce cours. Pour l’instant, contentez-vous de
retenir que l’établissement de la connexion ne dépend pas de HTTP et s’effectue à un autre niveau et à l’aide d’un autre
protocole.
Dans les versions de HTTP précédant HTTP/1.1, le serveur fermait automatiquement la connexion dès l’envoi de la
réponse, ce qui signifie qu’il fallait lancer une nouvelle connexion pour chaque nouvelle requête. Cette façon de procéder
était bien évidemment très inefficiente et créait de la latence.
Ce n’est plus le cas aujourd’hui : des procédés (que nous étudierons en détail plus tard) comme les connexions
persistantes ou le multiplexing permettent de garder une connexion active et d’envoyer plusieurs requêtes d’affilée
durant la même connexion.

3) Evolution du HTTP : des fonctionnalités aux performances

HTTP est un protocole qui n’a au départ pas été créé pour être performant mais simplement pour fournir un format
d’échanges de données sur des réseaux grâce à des messages formatés appelés requêtes et réponses HTTP.
Cependant, le web est devenu rapidement beaucoup plus populaire que ce qui avait été anticipé et cette adoption
massive a logiquement amené une évolution rapide de celui-ci. L’idée ici est que les gens ont très rapidement voulu faire
plus avec le web.
La diversification des applications du web et sa complexification rapide ont à la fois été permises par l’évolution en

5/30
parallèle de HTTP et ont également poussé ce protocole à continuer d’évoluer.
HTTP s’est en effet progressivement développé en décrivant de nouvelles méthodes HTTP qui ont diversifié l’éventail des
opérations permises par les clients, en créant le concept d’en-têtes HTTP et en créant de nouveaux en-têtes au cours du
temps, etc.
D’un autre côté, le web est devenu de plus en plus complexe avec l’ajout de médias comme les images, les vidéos, les
fichiers PDF ainsi que l’ajout de nouveaux langages côté client comme le CSS et le JavaScript. Ainsi, le nombre de
ressources nécessaires pour l’affichage d’une page web a drastiquement augmenté en même temps que le poids des
pages et cela a commencé à poser de sérieux défis au HTTP qui n’était pas un protocole créé avec une idée de
performance.
Dans cette leçon, nous allons voir comment HTTP a réussi à évoluer et à s’adapter au cours de 30 dernières années et
allons détailler les différentes évolutions majeures de ce protocole.

Les prémices de HTTP : HTTP/0.9

La première version « numérotée » de HTTP est HTTP/1.0 (sortie en 1996) tandis que la première version standardisée
est HTTP/1.1 (sortie en 1997). Le nom « HTTP/0.9 » sert à designer la version de HTTP utilisée entre 1991 et 1996.
Au début des années 1990 et donc au début du web, les sites web étaient des sites statiques et principalement
composés de texte et le protocole HTTP était également très rudimentaire :
• Les requêtes se font sur une ligne ;
• La seule méthode disponible est la méthode GET ;
• Le serveur ferme immédiatement la connexion après l’envoi de la réponse.
Une requête HTTP ressemble alors à cela :
GET /une-page.htmlLe serveur répond en renvoyant un document HTML.
Ici, il faut bien noter que le serveur envoie directement le contenu de la réponse, sans métadonnées puisque les en-têtes
HTTP n’existent pas encore. Cela implique que le serveur ne peut renvoyer que des fichiers HTML et pas d’autres types
de ressources (images, PDF, etc.).

Développement du protocole de transfert : HTTP/1.0

HTTP/1.0 est la première version officielle numéroté de HTTP. Cette version introduit de nombreuses nouvelles
fonctionnalités et les requêtes HTTP deviennent plus complexes et également plus puissantes.
Parmi les évolutions, on peut notamment citer l’ajout du concept d’en-têtes HTTP et des méthodes POST et HEAD.
Le système de connexion reste lui le même que celui de HTTP/0.9 : dès l’envoi d’une réponse, le serveur clôt la
connexion et il faut donc qu’une nouvelle connexion s’établisse entre le client et le serveur pour chaque nouvelle requête.
Les requêtes HTTP se décomposent alors de la façon suivante :
• Une ligne de commande contenant la méthode utilisée, l’URL de la ressource et la version du protocole utilisée ;
• Une ou plusieurs en-têtes HTTP qui permettent de transmettre des méta données (facultatif) ;
• Une ligne vierge ;
• Un corps de requête (facultatif).
Le serveur va également renvoyer une réponse plus complète que précédemment. Cette réponse inclut un code de
statut qui permet d’indiquer si la requête a abouti ou pas ainsi que différents en-têtes dont un en-tête « content-type »
qui permet d’indiquer le type de contenu renvoyé.
Une requête de récupération d’une image et la réponse serveur vont alors être de la forme suivante :

(requête)
GET /monimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

(réponse)
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
Content-Length: 1375
(contenu de l'image)

Standardisation et recherche de la performance : HTTP/1.1

HTTP/1.0 introduit de nombreuses nouvelles fonctionnalités par rapport à HTTP/0.9. Cependant, les fonctionnalités
ajoutées ne sont pas le fruit d’un travail commun mais plutôt de besoins ponctuels par différents systèmes.
En effet, le web n’était à cette époque pas unifié ni normé comme aujourd’hui et les différents serveurs / navigateurs /
systèmes développaient eux-mêmes leurs propres fonctionnalités et « forçaient » les autres à les adopter, posant de
nombreux problèmes d’interopérabilité.
Face à la croissance très rapide du web, un besoin d’unification s’est vite fait sentir pour que le web puisse continuer à
être utilisable et c’est la raison pour laquelle des groupes influents ont commencé à travailler sur des standards et
notamment sur le standard HTTP/1.1 qui sera publié en 1997.
En plus de la standardisation du protocole, HTTP/1.1 introduit de nouvelles méthodes et en-têtes HTTP.
En termes de nouvelles méthodes, les méthodes PUT, DELETE, OPTIONS et TRACE sont directement introduites puis
viendront plus tard les méthodes CONNECT et PATCH.
En termes d’en-tête HTTP, l’en-tête Host est standardisée et est désormais obligatoire dans chaque requête HTTP. Cet en-
tête permet d’indiquer au serveur web quel hébergement virtuel utilisé. L’en-tête host permet ainsi de fait d’héberger
différents domaines sur une même adresse IP.
HTTP/1.1 est également la première version de HTTP où l’optimisation des performances devient une problématique
centrale. En effet, les pages web sont de plus en plus exigeantes en termes de nombre de ressources à charger et du

6/30
poids de chaque ressource.
Cela n’était pas prévu lors de la création de HTTP : les fondations du protocole sont qu’on ne peut effectuer qu’une seule
opération par requête. En plus de cela, HTTP souffre des limitations suivantes :
• On ne peut envoyer qu’une requête à la fois car il faut attendre de recevoir la réponse serveur avant d’en envoyer une
nouvelle ;
• Il faut établir une nouvelle connexion entre le client et le serveur après chaque réponse.
La version HTTP/1.1 s’attaque à ces limitations en proposant des mécanismes de connexions persistantes ou « keep-alive
» ainsi que le support des connexions en pipeline et des connexions parallèles.
Les connexions persistantes sont des connexions qui se poursuivent pendant un certain temps après la réponse du
serveur. Autrement dit, la connexion est maintenue dans l’attente d’une nouvelle requête. Cela permet d’économiser le
temps de la connexion et de la déconnexion.
Le « pipelining » est un mécanisme qui permet au client d’envoyer une nouvelle requête avant même d’avoir reçu la
réponse du serveur (c’est-à-dire d’envoyer plusieurs requêtes « en même temps » en établissant plusieurs connexions
simultanées). Les réponses du serveur doivent cependant arriver dans le même ordre que celui de l’envoi des requêtes.
Le principe de connexions parallèles, comme son nom l’indique, est d’établir plusieurs connexions simultanées de façon
à pouvoir envoyer plus de requêtes en même temps. Les navigateurs de l’époque étaient capables de supporter de 2 à 8
connexions simultanées.
Outre cela, HTTP/1.1 introduit également le concept de négociation de contenu au niveau du langage, de l’encodage et
du type (notamment via les en-tête Accept, Accept-Language et Accept-Encoding. Cela permet au client et au serveur
de se mettre d’accord sur le contenu à échanger. HTTP/1.1 ajoute également de nouveaux mécanismes de caches plus
perfectionnés.
Une ensemble de requêtes / réponses HTTP/1.1 ressemble à ceci :

(Request 1)
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

(Response 1)
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

[content]

(Request 2)
GET /static/img/header-background.png HTTP/1.1
Host: developer.cdn.mozilla.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

(Response 2)
HTTP/1.1 200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

[image content of 3077 bytes]

La version de référence : HTTP/2 et SPDY

HTTP/2 est la version du protocole de transfert hypertexte de reference utilisée aujourd’hui. Il convient avant tout de
noter que HTTP/2 ne modifie en rien la sémantique d’application de HTTP. Tous les concepts de base, tels que les
méthodes HTTP, les codes d’état, les URI et les champs d’en-tête sont conservés tels quels. En revanche, HTTP/2 modifie
la façon dont les données sont formatées et transportées entre le client et le serveur.

7/30
HTTP/2 a été publié en 2015 et trouve son origine dans un autre protocole appelé SPDY et développé par Google.
Au début des années 2010, Google a en effet commencé à effectuer des travaux pour améliorer les performances de
HTTP qui n’est pas un protocole créé avec une idée de performance à la base et qui est donc très complexe à optimiser.
Cela a donné lieu à la naissance de SPDY, un protocole réseau visant à augmenter les capacités du protocole HTTP sans
toutefois remplacer ce dernier (SPDY fonctionne avec HTTP).
L’objectif principal de SPDY est de réduire la durée de téléchargement des pages Web. Pour cela, les requêtes sont
classées par ordre de priorité (de sorte à ce que les requêtes les plus importantes comme le chargement d’un fichier de
style ne soient pas bloquées par d’autres moins importantes comme le chargement d’une image en bas de page). En plus
de cela, un mécanisme de multiplexing est mis en place.
Concrètement, le multiplexing permet d’envoyer plusieurs requêtes d’affilée lors d’une même connexion sans attendre à
chaque fois la réponse du serveur tout comme le permettait théoriquement le pipelining. En pratique, toutefois, le
pipelining était très complexe à mettre en place (notamment avec les connexions parallèles), mal supporté et pouvait
entrainer des faille de sécurité ce qui n’est plus le cas avec le multiplexing.
En plus de cela, avec le multiplexing, les réponses du serveur peuvent désormais revenir dans n’importe quel ordre. En,
d’autres termes, le serveur n’est plus obligé de renvoyer les réponses dans le même ordre que l’envoi des requêtes, ce
qui permet d’éviter des blocages et rend le processus plus performant.
SPDY a été implémenté et testé par Google pendant plusieurs années avant que Google se rapproche du groupe de
travail chargé de l’évolution de HTTP et leur passe les documents techniques liés à SPDY afin que ces avancées soient
introduites dans HTTP même.
Cela va donc être l’une des fondations de HTTP/2. En plus du multiplexing et de la priorisation des requêtes, on notera
également que HTTP/2 compresse désormais les en-têtes HTTP, de telle sorte qu’un même en-tête n’est pas renvoyé
plusieurs inutilement. HTTP/2 améliore également les mécanismes de cache notamment en permettant au serveur de
remplir le cache du client avant même que le client n’envoie une requête.
Enfin, il faut également souligner que HTTP/2 est désormais encodé directement en binaire et non plus en texte. Cela le
rend donc impossible à lire ou à écrire à la main mais permet de nouvelles optimalisations du protocole.
Pour être tout à fait précis, les données sont découpées en « frames » (trames) codées en binaire qui sont ensuite
mappées à des messages qui appartiennent à un flux particulier et qui sont tous multiplexés dans une seule connexion
TCP. C’est la base qui permet toutes les autres fonctionnalités et optimisations de performances fournies par le protocole
HTTP/2.

Le futur du HTTP : HTTP/3.0 et QUIC

Après SPDY, Google a continué à travailler sur les problématiques d’optimisation des performances sur le Web en général
pour « rendre le Web plus rapide ».
Google a ainsi développé un nouveau protocole appelé QUIC pour « Quick UDP Internet Connections ». Ce protocole se
situe au niveau de la couche transport des modèles OSI et TCP/IP et est censé fonctionner au-dessus d’un autre protocole
de transport nommée UDP.
L’idée de Google était ici d’utiliser le protocole de transport UDP plutôt que le protocole commun TCP pour proposer des
connexions HTTP et des transferts de données plus rapides.
Tout comme avec SPDY, Google a passé son travail sur QUIC à l’IETF (le groupe chargé de l’évolution de HTTP) afin que
les avancées faites soient intégrées à HTTP. Cela a marqué le point de départ de « HTTP over QUIC » renommé ensuite
HTTP/3.
Le support pour HTTP/3 a été ajouté à Chrome en septembre 2019 et à Firefox en novembre 2019. En janvier 2020, 2%
des sites l’utilisent déjà. Nous reviendrons plus en détail sur HTTP/3 dans la fin de ce cours.

4) Le Cache HTTP

Qu’est-ce qu’un cache et à quoi cela sert ?

Un cache correspond à un stockage local de données reçues précédemment ou plus exactement des messages de
réponse HTTP reçus précédemment. Un système de cache contrôle le stockage, la récupération et la suppression de ces
messages.
Grosso-modo, l’idée est la suivante : un client effectue une première requête HTTP pour par exemple récupérer une
certaine ressource. Le serveur lui renvoie la ressource demandée dans sa réponse HTTP. L’agent utilisateur (le navigateur
généralement) va alors pouvoir stocker cette réponse HTTP dans son cache local.
Ainsi, lorsque l’utilisateur effectuera à nouveau la même requête, l’agent utilisateur pourra immédiatement utiliser la
réponse stockée dans son cache plutôt que d’envoyer la même requête à nouveau au serveur et devoir attendre la
réponse.
Concrètement, le cache permet l’amélioration des performances aussi bien côté client que pour les propriétaires de site
grâce à la réduction du temps de réponse et à la diminution de la consommation de la bande passante.
Le cache permet également, entre autres, de consulter certains documents ou du moins d’améliorer la consultation de
certains documents hors ligne puisque la copie de la réponse du serveur est enregistrée localement dans le navigateur
du visiteur (c’est-à-dire sur sa propre machine).

Cache privé et cache partagé

Pour bien comprendre comment fonctionne le cache, il faut avant tout savoir qu’il existe deux types de caches : les
caches privés et les caches partagés.
Un cache privé est un cache qui n’appartient qu’à un seul navigateur. Typiquement, les caches des navigateurs des
utilisateurs sont des caches privés puisque chaque utilisateur possède son propre historique de recherche.
Un cache partagé est un cache qui a été mis en place à un plus haut niveau et qui a vocation à être utilisé par plusieurs
utilisateurs. Lorsqu’un utilisateur effectue une requête HTTP, il faut en effet savoir que la requête n’arrive pas
directement au serveur : elle passe généralement par de nombreux proxies qui vont la transmettre sur le web.
Il va tout à fait être possible de configurer un cache sur ces différents proxies. En effet, un serveur intermédiaire (proxy)

8/30
par lequel transite une requête HTTP peut également tout à fait utiliser un cache.
Au final, il existe une grande variété d’architectures et de configurations de caches déployées sur le World Wide Web et
au sein de grandes organisations, notamment des hiérarchies nationales des caches de proxy pour économiser la bande
passante transocéanique, etc.

Restrictions liées au cache : réponses cachable et non cachable

On dit qu’une réponse est « cachable » (« pouvant être mise en cache ») si un cache est autorisé à stocker une copie du
message de réponse HTTP pour l’utiliser pour répondre aux requêtes similaires suivantes.
La forme la plus courante d’une entrée de cache est typiquement le résultat d’une requête de récupération de
ressources réussie c’est-à-dire une réponse 200 (OK) à une requête GET qui contient une représentation de la ressource
identifiée par la cible de la requête.
Notez qu’il est cependant également possible de mettre en cache les redirections permanentes, les résultats négatifs
comme 404 (Not Found), les résultats incomplets comme 206 (Partial Content) et les réponses à des méthodes autres
que GET si la définition de la méthode permet une telle mise en cache et définit quelque chose qui peut être utilisé
comme clé de cache.

Composition d’une entrée de cache

Chaque entrée de cache se compose d’une clé de cache et d’une ou plusieurs réponses HTTP correspondant à des
demandes antérieures qui utilisaient la même clé.
La clé de cache principale se compose théoriquement de la méthode de requête et de l’URI (Identifiant de Ressource
Uniforme) cible. Cependant, en pratique, étant donné que les caches HTTP couramment utilisés aujourd’hui sont
généralement limités à la mise en cache des réponses à GET, de nombreux caches refusent simplement d’autres
méthodes et n’utilisent que l’URI comme clé de cache principale.
Notez que si la cible d’une requête fait l’objet d’une négociation de contenu, son entrée de cache peut consister en
plusieurs réponses stockées chacune différenciée par une clé secondaire.

Durée de vie ou fraicheur d’un cache

Par définition, tout cache doit avoir une durée de vie limitée. En effet, si un cache était stocké et resservi indéfiniment
par un navigateur, alors l’utilisateur n’aurait jamais accès aux changements faits ultérieurement sur le document.
La durée de vie ou de « fraicheur » d’un cache est l’un des points les plus techniques liés à celui-ci : en paramétrant une
durée de vie trop courte, on se prive de l’intérêt principal du cache qui est de ne pas avoir à effectuer l’aller-retour
jusqu’au serveur. Au contraire, en définissant une durée de vie trop élevée pour un cache, on court le risque que certains
utilisateurs n’aient pas accès à certains changements effectués sur nos documents.
La durée de vie de la fraîcheur d’une réponse est la durée entre sa génération par le serveur d’origine et son heure
d’expiration. Une heure d’expiration explicite est l’heure à laquelle le serveur d’origine prévoit qu’une réponse stockée
ne peut plus être utilisée par un cache sans validation supplémentaire, tandis qu’une heure d’expiration heuristique est
attribuée par une mémoire cache lorsqu’aucune heure d’expiration explicite n’est disponible.
Lorsqu’une réponse est « fraîche » dans le cache, elle peut être utilisée pour satisfaire les requêtes suivantes sans
contacter le serveur d’origine, améliorant ainsi l’efficacité.
Le principal mécanisme de détermination de la fraîcheur consiste pour un serveur d’origine à fournir une heure
d’expiration future explicite via un en-tête Expires ou via la directive max-age.
Pour calculer la durée de vie de fraîcheur d’une réponse, un cache va utiliser, dans cet ordre :
• La valeur de la directive s-maxage si le cache est partagé ou ;
• La valeur de la directive max-age ou ;
• La valeur de l’en-tête Expires ou ;
• Une durée de vie de fraicheur heuristique.
Une fois la durée de vie d’une réponse expirée dans le cache, celle-ci est considérée comme périmée (« stale » en
anglais). Lorsqu’une réponse est périmée, le cache ne l’utilise pas immédiatement mais transmet la requête au serveur
avec un en-tête If-None-Match pour vérifier si elle peut être quand même être utilisée (c’est-à-dire si aucun
changement n’a été fait depuis). Si c’est le cas, le serveur renvoie une réponse avec un statut 304 (Not Modified),
indiquant que la réponse cachée peut toujours être utilisée.

Contrôle du cache
Le champ d’en-tête Cache-Control est utilisé pour spécifier les directives pour les mécanismes de cache dans les
requêtes et les réponses.
Les règles standard Cache-Control suivantes peuvent être utilisées par un client HTTP dans une requête :
• Cache-Control: max-age : Indique la durée pendant laquelle la ressource doit être considérée comme valide (non
expirée). Contrairement à expires, la durée indiquée dans cette directive commence à la date de la requête ;
• Cache-Control: max-stale : Indique que le client accepte une réponse expirée. Une valeur optionnelle permet
d’indiquer la durée maximale depuis laquelle la réponse peut être expirée mais acceptée quand même ;
• Cache-Control: min-fresh : Indique que le client demande une réponse qui soit valide pour au moins la durée
demandée (dont la date d’expiration est supérieure à la date actuelle plus la durée spécifiée) ;
• Cache-Control: no-cache : Indique de renvoyer systématiquement la requête au serveur et ne servir une éventuelle
version en cache que dans le cas où le serveur le demande ;
• Cache-Control: no-store : La requête ou les données ne devraient jamais être mises en cache ;
• Cache-Control: no-transform : Aucune conversion ou transformation ne devraient être réalisée sur la ressource. Ainsi,
les en-tête Content-Encoding, Content-Range et Content-Type ne devraient jamais être modifiés par un proxy (serveur
mandataire). Un proxy non-transparent pourrait, en l’absence de cet en-tête, convertir ou compresser (avec pertes) des
images pour réduire la place occupée en cache ou diminuer le volume de données à transférer sur un lien lent ;
• Cache-Control: only-if-cached : Indique de se limiter au contenu en cache. Dans ce cas, le client ne veut pas que sa

9/30
réponse soit envoyée au serveur.
Les règles standard Cache-Control suivantes peuvent être utilisées par un serveur HTTP dans une réponse :
• Cache-Control: must-revalidate : Le cache doit refaire une requête dans le cas où les données sont expirées afin de
les mettre à jour s’il y a lieu (il reste parfaitement possible que le serveur réponde avec les mêmes données) ;
• Cache-Control :no-cache ;
• Cache-Control: no-store ;
• Cache-Control: no-transform ;
• Cache-Control: public : Indique que la réponse peut être mise en cache par n’importe quel cache ;
• Cache-Control: private : Indique que la réponse ne doit être mise en cache que pour un utilisateur donné et ne doit
donc pas être mise en cache par un cache partagé ;
• Cache-Control: proxy-revalidate : Comme pour must-revalidate, mais force la valeur pour les caches partagés.
Cette valeur est ignorée par les caches locaux.
• Cache-Control: max-age ;
• Cache-Control: s-maxage= : Indique une valeur pour écraser les valeurs définies par max-age ou Expires pour les
caches partagés (comme les proxies). Il est donc ignoré par les caches privés (dont les navigateurs).

5) Les redirections HTTP

La redirection d’URL est une technique qui permet de manière générale de donner plusieurs URL à une même ressource.
Il existe différents types de redirections (redirections temporaires, permanentes, etc.) qui servent différents objectifs et
les redirections peuvent être faites de différentes manières : en utilisant HTTP, en HTML ou encore avec JavaScript.
Dans cette leçon, nous étudierons uniquement les redirections HTTP. Notez qu’il est recommandé d’utiliser HTTP pour
effectuer une redirection plutôt que HTML ou JavaScript.

Fonctionnement d’une redirection

Une redirection HTTP indique que l’agent utilisateur doit prendre des mesures supplémentaires pour répondre à la
demande.
Voyons comment fonctionne une redirection concrètement. Pour cela, imaginons qu’un utilisateur demande à accéder à
une ressource particulière en tapant une URL dans son navigateur. Le client (navigateur) effectue alors une requête HTTP
au serveur pour lui demander la réponse en question.
Lorsque le serveur reçoit la requête, il essaie d’y répondre. Dans la réponse HTTP envoyée, il inclut un code de statut (ou
« code d’état ») HTTP. Si le serveur est capable de répondre à la demande et envoie bien la ressource demandée, par
exemple, il accolera un code de statut 200 (OK) à la réponse.
Si la ressource demandée est introuvable, il enverra un code de statut 404 (Not Found). Si une erreur interne au serveur
survient, il renverra un code 5xx, etc.
Dans certains cas, cependant, le serveur va bien trouver la ressource demandée mais ne va pas la renvoyer
immédiatement soit car celle-ci ne se trouve pas à l’URL indiquée mais ailleurs soit car elle peut être récupérée via un
cache navigateur. Dans ce cas, il va renvoyer un code de statut 3xx.
En fonction du type de redirection, le client va alors choisir l’action la plus adaptée. Les grands types de redirections sont
les suivants :
• Les redirections qui indiquent que la ressource peut être disponible à un URI différent, tel que fourni par l’en-tête de
réponse Location. C’est le cas pour les redirections 301 (Moved Permanently), 302 (Found) et 307 (Temporary Redirect) ;
• Les redirections qui offrent un choix de ressources correspondantes, chacune capable de représenter la cible de la
requête d’origine. C’est le cas pour le code de statut 300 (Multiple Choice) ;
• Les redirections vers une ressource différente, identifiée par l’en-tête de réponse Location, qui peuvent représenter une
réponse indirecte à la requête, comme dans le cas du code de statut 303 (See Other) ;
• Les redirections vers un résultat précédemment mis en cache, comme c’est le cas pour le code d’état 304 (Not
Modified).

Les types de redirections HTTP en détail

Les redirections HTTP sont représentées par les codes de statut 3xx. Chaque code de statut HTTP 3xx représente un type
de redirection différent.

300 Multiple Choice

Le code de statut 300 indique que la ressource cible possède plus d’une représentation possédant chacune un identifiant
(généralement une URL) différent.
Des informations sur les alternatives sont fournies afin que le client puisse sélectionner une représentation préférée en
redirigeant sa requête vers un ou plusieurs de ces identifiants.
En d’autres termes, le serveur souhaite que l’agent utilisateur s’engage dans une négociation réactive pour sélectionner
la ou les représentations les plus appropriées à ses besoins.
Si le serveur a un choix préféré, le serveur devrait générer un champ d’en-tête Location contenant la référence (sous
forme d’URI) relative à ce choix.

301 Moved Permanently

Le code de statut indique que la ressource cible a reçu un nouvel URI permanent et que toute référence future à cette
ressource doit utiliser ce nouvel URI.
Concrètement, cela signifie que la ressource demandée est désormais disponible à un autre URI. La redirection 301 est
certainement la redirection la plus courante. En effet, on l’utilise lorsqu’on modifie définitivement l’URL d’une page par
exemple afin de rediriger les visiteurs qui utiliseraient l’ancienne URL vers la nouvelle (le nouvel emplacement où se
trouve la page).
Le serveur devrait générer un champ d’en-tête Location dans la réponse contenant une référence URI préférée pour le
nouvel URI permanent.

10/30
Dans la majorité des cas, lorsque l’agent utilisateur reçoit une réponse 301, il effectue une nouvelle requête avec le
nouvel URI fourni par l’en-tête Location.
Notez qu’originellement la méthode de la nouvelle requête devrait être la même que celle de la précédente. Cependant,
historiquement, les agents utilisateurs ont souvent implémenté cela incorrectement notamment dans la cas où la
première requête était une requête POST (qui était souvent transformée en une requête GET).
Il est donc aujourd’hui admis qu’un agent utilisateur peut changer la méthode de demande de POST à GET d’une requête à
l’autre. Un nouveau code de statut, le code 308 a d’ailleurs été créé pour spécifier explicitement qu’on ne veut pas que
l’agent utilisateur change de méthode de requête lorsqu’il suit une redirection permanente.

302 Found
Le code d’état 302 indique que la ressource cible réside temporairement sous un URI différent.
Ce code de statut est le code à utiliser lors de maintenances par exemple ou lorsqu’on modifie une page et qu’on ne
souhaite pas que les visiteurs puissent accéder à celle-ci pendant qu’elle est modifiée.
Comme la redirection n’est que temporaire, le client doit continuer à utiliser l’URI de requête de base pour les demandes
futures. En effet, une redirection temporaire a pour finalité de disparaitre.
Comme pour une redirection 301, le serveur devrait générer un champ d’en-tête Location dans la réponse contenant une
référence URI préférée pour le nouvel URI permanent.
La prise en charge des 302 par les agents utilisateur a été similaire à celle des 301 historiquement, avec ces agents
utilisateur modifiant la méthode de requête entre deux requêtes alors que cela était théoriquement incorrect.
Comme précisé précédemment, il est aujourd’hui admis qu’un agent utilisateur peut changer la méthode de demande de
POST à GET d’une requête à l’autre. Un autre code de statut, le code 307 a été mis en place pour spécifier explicitement
qu’on ne veut pas que l’agent utilisateur change de méthode de requête lorsqu’il suit une redirection temporaire.

303 See Other

Le code de statut 303 indique que le serveur redirige l’agent utilisateur vers une ressource différente, comme indiqué
par un URI dans le champ d’en-tête Location, qui est destiné à fournir une réponse indirecte à la demande d’origine.
Ce code de statut est souvent utilisé comme résultat de requêtes POST et PUT.
En effet, imaginez qu’un utilisateur envoie des données via un formulaire. La méthode utilisée sera généralement POST.
Cependant, on voudra rarement rediriger l’utilisateur au même endroit que les données sont envoyées après qu’il ait
validé le formulaire. On va ici plutôt utiliser une 303 pour rediriger l’utilisateur vers l’URI qui nous intéresse (confirmation
d’envoi, page principale du compte client, page d’accueil du site, etc.).

304 Not Modified

Le code de statut 304 indique que la ressource demandée n’a pas changé depuis la dernière requête de récupération du
client et que celui-ci peut donc utiliser la réponse envoyée précédemment stockée dans son cache.
Pour bien comprendre comment fonctionne et l’intérêt de ce code de statut, il faut avant tout comprendre comment le
cache HTTP fonctionne.
Lorsqu’un agent utilisateur reçoit une réponse à une requête HTTP depuis le serveur, il peut cacher cette réponse, c’est-à-
dire la sauvegarder localement dans le but de la réutiliser directement si le client effectue la même requête par la suite.
Dans certains cas, cependant, l’agent utilisateur va devoir recontacter le serveur pour s’assurer qu’il puisse utiliser la
réponse cachée. C’est notamment le cas lorsque la durée de vie du cache est expirée.
Dans le cas où il n’y a pas eu de modification sur la ressource entre temps, le serveur peut alors renvoyer une 304
indiquant à l’agent utilisateur qu’il peut continuer d’utiliser la réponse mise en cache. Cela permet d’économiser des
ressources car il y a moins de données transférées.

305 Use Proxy

Code de statut déprécié qui indiquait que la requête doit être ré-adressée au proxy.

306 Switch Proxy

Code de statut réservé et plus utilisé aujourd’hui qui indiquait que les requêtes suivantes doivent utiliser le proxy spécifié.

307 Temporary Redirect

Le code de statut 307 est équivalent au code 302 et indique donc que la ressource cible réside temporairement sous un
URI différent.
La seule différence entre les codes de statut HTTP 302 et 307 est que le code 307 permet d’indiquer explicitement que
l’agent utilisateur ne doit pas changer la méthode de demande s’il effectue une redirection automatique vers cet URI.

308 Permanent Redirect

Le code de statut 308 est équivalent au code 301 et indique donc que la ressource cible réside de manière permanente
sous un URI différent.
La seule différence entre les codes de statut HTTP 301 et 308 est que le code 308 permet d’indiquer explicitement que
l’agent utilisateur ne doit pas changer la méthode de demande s’il effectue une redirection automatique vers cet URI.

Redirections et SEO
En pratique, les redirections les plus couramment utilisées sont les redirections 301 et 304 et ces deux types de
redirections HTTP sont principalement utilisées dans une optique SEO.
Les redirections 301 (et 308) permettent de transmettre l’autorité d’une URI à une autre pour les mots clefs sur lesquels
elle est positionnée.
En effet, mettre en place une redirection 301 permet aux robots de Google de comprendre qu’une ressource en
particulier a changé d’emplacement et donc de conserver les classements obtenus. Attention cependant : cela ne va
bien fonctionner que si la nouvelle URI possède bien un contenu similaire à l’ancienne.
En plus de cela, le redirections 301 permettent de ne pas perdre les liens externes obtenus (qui sont un facteur
d’optimisation du référencement essentiel) sur l’ancienne URI puisque leur autorité va donc également être « redirigée »

11/30
vers la nouvelle URI.
Les redirections 304 permettent également d’optimiser son référencement en optimisant la vitesse d’affichage des pages
d’un site pour les visiteurs puisque ce type de redirections permet de faire l’économie du transfert d’un certain poids de
données.

Paramétrer des redirections HTTP en pratique

En tant que développeur / webmaster, vous n’aurez généralement pas à mettre en place un système de redirections 304
par vous-même car la plupart des hébergeurs s’occupent de cela.
En revanche, vous allez être souvent amené à créer des redirections 301, 302, etc. Il est donc important de savoir le faire.
Les redirections HTTP vont être mises en place au niveau du serveur. La façon de procéder va donc être différente selon
que votre serveur soit un serveur Apache ou Nginx (ou autre).
Avec un serveur Apache (type de serveur le plus commun), vous pouvez définir des redirections soit dans le fichier de
configuration du serveur, soit dans le fichier .htaccess de chaque répertoire.
Pour créer une redirection 301, par exemple, il va alors suffire d’utiliser une directive Redirect comme ceci :
Redirect 301 / http://www.example.com
Ici, on demande à rediriger l’URL http://example.com (la racine du site, symbolisée par /) vers http://
www.example.com.
Notez qu’on aurait aussi bien pu écrire :
Redirect 301 http://example.com http://www.example.com
Pour rediriger une URL vers une image « image1.jpg » contenue dans un dossier images lui-même situé à la racine vers
une autre URL « image2.jpg », on pourra écrire :
Redirect 301 /images/image1.jpg http://www.example.com/images/image2.jpg
Avec un serveur nginx, on pourra créer un bloc server{} contenant nos redirections ou de manière plus classique utiliser
une directive rewrite comme cela :
rewrite ^/images/(.*)$ http:// example.com/photos/$1 redirect;.
Cela redirigera tous les documents du dossiers images vers un autre dossier photos. Ici, vous pouvez noter l’emploi de
plusieurs signes. Ces signes sont des métacaractères d’un langage appelé expressions régulières : ils possèdent une
signification spéciale et permettent donc de préciser la règle de redirection.

6) Les cookies HTTP

Un cookie HTTP est une petite quantité de données qu’un serveur envoie à un agent utilisateur (client) afin que ce dernier
le lui renvoie lors de requêtes ultérieures.
Pour comprendre l’intérêt des cookies, vous devez avant tout vous rappeler que HTTP est un protocole sans état. Cela
implique notamment que le serveur n’a à priori aucun moyen d’établir un lien entre deux requêtes provenant d’un même
client.
Cette particularité du HTTP peut rapidement devenir très gênante en termes d’expérience utilisateur : imaginez le cas où
un utilisateur se connecte sur un site ou si il a indiqué des préférences d’utilisation sur le site. Le serveur n’est à priori
pas capable de conserver l’état entre deux requêtes HTTP et le client devra se reconnecter ou indiquer à nouveau ses
préférences à chaque changement de page.
Les cookies permettent de maintenir une session avec état sur le protocole HTTP qui est normalement sans état. On va
pouvoir les utiliser pour la gestion de session comme la mémorisation d’un identifiant de session, de l’état d’un panier
d’achat etc. ou pour la mémorisation des préférences utilisateur.

Fonctionnement des cookies HTTP

Lorsqu’un client effectue une requête pour la première fois, le serveur peut attacher un ou plusieurs cookies avec sa
réponse. Le client pourra ensuite renvoyer ces cookies avec les requêtes futures, afin de conserver un état entre deux
requêtes.
Pour enregistrer un état, le serveur inclut un en-tête Set-Cookie dans la réponse HTTP. Cet en-tête va contenir une paire
nom-valeur et des métadonnées associées (date d’expiration, domaine de validité, etc.). On appelle cet ensemble nom +
valeur + métadonnée un cookie.
Par exemple, le serveur peut envoyer à l’agent utilisateur un cookie d’identifiant de session qu’on peut appeler SID («
Session ID ») et qui va posséder la valeur liée à la session courante afin de pouvoir immédiatement le ré-identifier par la
suite ou encore un cookie contenant les préférences de l’utilisateur par rapport à la langue qu’on peut appeler « lang ».
Ces cookies pourraient ressembler à cela :

Set-Cookie: SID=14322ac76654aa83; Path=/; Secure; HttpOnly

Set-Cookie: lang=fr-FR; Path=/; Domain=example.com
Ces cookies vont être stockés chez l’agent utilisateur (le client). Lorsque l’agent utilisateur effectue de nouvelles
requêtes, il utilise les métadonnées et d’autres informations pour déterminer s’il faut renvoyer les paires nom / valeur
dans un en-tête de requête Cookie. L’en-tête cookie pourrait ici ressembler à cela :
Cookie: SID=14322ac76654aa83; lang=fr-FR

Attributs des cookies HTTP

Les deux cookies définis ci-dessus sont composés de paires nom-valeur (SID=14322ac76654aa83 et lang=fr-FR) et
également d’autres données qu’on appelle des attributs de cookie.
Ces attributs vont nous permettre de définir la durée de vie des cookies, le domaine sur lequel ils doivent être définis, les
conditions d’envoi, etc. les cookies peuvent contenir les attributs suivants :
• Expires ;
• Max-Age ;
• Domain ;

12/30
• Path ;
• Secure ;
• HttpOnly ;
• SameSite (pas encore standardisé mais bénéficiant déjà d’un support étendu).

Expires
L’attribut Expires indique la durée de vie maximale du cookie, représentée par la date et l’heure d’expiration du cookie.
Notez que l’agent utilisateur peut tout à fait supprimer un cookie avant la data indiquée par Expires, notamment pour
des raisons de pression sur la mémoire ou pour des raisons de confidentialité / sécurité.

Max-Age
L’attribut Max-Age indique également la durée de vie maximale du cookie, cette fois-ci représentée par le nombre de
secondes jusqu’à l’expiration du cookie. L’agent utilisateur n’est une nouvelle fois pas tenu de conserver le cookie
pendant la durée spécifiée.
Certains vieux agents utilisateurs ne supportent pas Max-Age. Dans ce cas, l’attribut est ignoré.
Notez que si un cookie possède à la fois un attribut Max-Age et un attribut Expires, l’attribut Max-Age a la priorité et
contrôle la date d’expiration du cookie.
Enfin, notez que si un cookie ne possède ni attribut Max-Age ni Expires alors le cookie aura une durée de vie égale à celle
de la session courante.

Domain
L’attribut Domain spécifie les hôtes auxquels le cookie sera envoyé. Par exemple, si la valeur de l’attribut Domain est «
example.com », l’agent utilisateur inclura le cookie dans l’en-tête Cookie pour des requêtes HTTP sur example.com,
www.example.com et www.corp.example. com.
Si l’attribut Domain est omis, l’agent utilisateur renverra le cookie uniquement au serveur d’origine. Attention : certains
agents utilisateurs existants traitent un attribut Domain absent comme si l’attribut était présent et contenait le nom
d’hôte actuel.

Path
La portée de chaque cookie est limitée à un ensemble de chemins, contrôlé par l’attribut Path.
Si le serveur omet l’attribut Path, l’agent utilisateur utilisera le répertoire du composant de chemin de l’URL de demande
comme valeur par défaut.
L’agent utilisateur inclura le cookie dans une requête HTTP uniquement si la partie chemin de l’URL de la requête
correspond à (ou est un sous-répertoire de) l’attribut Path du cookie.
Notez que le caractère slash (/) est interprété comme un séparateur de répertoire .
Attention : bien que l’attribut Path semble utile pour isoler les cookies entre différents chemins au sein d’un hôte donné,
il n’est pas fiable d’un point de vue sécurité.

Secure
L’attribut Secure limite la portée du cookie aux canaux « sécurisés » (où la notion de « sécurité » est définie par l’agent
utilisateur).
Lorsqu’un cookie possède un attribut Secure, l’agent utilisateur n’inclut le cookie dans une requête HTTP que si celle-ci
est transmise sur un canal sécurisé, généralement HTTP sur Transport Layer Security (TLS) c’est-à-dire HTTPS.
Attention : l’attribut Secure protège uniquement la confidentialité du cookie. Un attaquant peut écraser les cookies Secure
d’un canal non sécurisé, ce qui perturbe leur intégrité.

HttpOnly
L’attribut HttpOnly limite la portée du cookie aux requêtes HTTP. En particulier, l’attribut indique à l’agent utilisateur
d’omettre le cookie lors de l’accès aux cookies via des API non-HTTP (telles qu’une API de navigateur Web qui expose les
cookies aux scripts).
Notez que l’attribut HttpOnly est indépendant de l’attribut Secure : un cookie peut avoir à la fois un attribut HttpOnly et
un attribut Secure.

Samesite
L’attribut Samesite n’est pas encore standardisé mais bénéfice déjà d’un support étendu parmi les navigateurs les plus
populaires.
Cet attribut permet d’indiquer qu’un cookie ne doit pas être envoyés avec des requêtes cross-site. Il offre une certaine
protection contre les attaques de type cross-site request forgery (CSRF).

Création et gestion des cookies HTTP

En tant que webmaster ou que développeur, vous n’aurez pas à créer la plupart des cookies puisque ceux-ci vont être
générés automatiquement par le serveur (dans le cas de cookies d’environnement) ou par le CMS (Content Management
System) utilisé si celui-ci a bien été conçu.
Cependant, il y a des situations où vous allez devoir vous-même définir des cookies, notamment dans le cas où vous
avez besoin de stocker quelque chose de très spécifique chez le client ou dans le cas où vous êtes amené à créer un site
sans utiliser d’architecture préconçue.
Dans ce cas-là, il existe différents moyens de créer des cookies. Dans tous les cas, vous allez créer vos cookies en
utilisant un langage côté serveur (PHP, Python, etc.) ou éventuellement du JavaScript. Pour plus d’informations à ce
sujet, n’hésitez pas à lire mes cours où j’explique comment créer un cookie en PHP et comment créer un cookie en
JavaScript.

7) Le mécanisme HTTP de négociation de contenu

13/30
Le serveur a souvent différentes manières de représenter les informations envoyées dans une réponse suite à une
requête. Les données peuvent en effet être disponibles par exemple dans différents formats, langues ou encodages.
De même, différents utilisateurs ou agents utilisateurs peuvent avoir des capacités, des caractéristiques ou des
préférences différentes qui pourraient influencer la représentation, parmi celles disponibles, qui serait la meilleure à
fournir.
Pour cette raison, HTTP fournit des mécanismes de négociation de contenu qui vont, comme le nom l’indique, permettre
une négociation entre le client et le serveur pour obtenir la représentation la plus appropriée.

Quels sont les modèles de négociation de contenu HTTP disponibles ?

Les deux modèles de négociation de contenu les plus communs sont la négociation proactive et la négociation réactive.
Négociation proactive : le serveur sélectionne la représentation en fonction des préférences déclarées de l’agent
utilisateur.
Négociation réactive : le serveur fournit une liste de représentations pour l’agent utilisateur à choisir.
Il existe également d’autres modèles de négociation de contenu comme :
• Le contenu conditionnel : la représentation se compose de plusieurs parties qui sont rendues sélectivement en fonction
des paramètres de l’agent utilisateur ;
• Le contenu actif : la représentation contient un script qui fait des demandes supplémentaires (plus spécifiques) en
fonction des caractéristiques de l’agent utilisateur ;
• La négociation transparente de contenu : la sélection de contenu est effectuée par un intermédiaire.
Notez que, dans tous les cas, HTTP n’est pas au courant de la sémantique des ressources. La cohérence avec laquelle un
serveur d’origine répond aux requêtes est entièrement déterminée par l’entité ou l’algorithme qui sélectionne ou génère
ces réponses.
nbsp;

La négociation proactive en détail

La négociation de contenu est dite proactive lorsque les préférences de négociation de contenu sont envoyées par
l’agent utilisateur au sein d’une requête pour encourager un algorithme situé au niveau du serveur à sélectionner la
représentation préférée.
La négociation proactive est donc toujours une négociation pilotée par le serveur puisque c’est lui qui décide in-fine de la
représentation à fournir au client (en tenant compte des préférences décrites par ce dernier).
La sélection est basée sur les représentations disponibles pour une réponse (les dimensions sur lesquelles elle peut
varier, telles que la langue, le codage de contenu, etc.) par rapport aux diverses informations fournies dans la requête.
La négociation proactive est avantageuse lorsque l’algorithme de sélection parmi les représentations disponibles est
difficile à décrire à un agent utilisateur, ou lorsque le serveur souhaite envoyer sa « meilleure estimation » à l’agent
utilisateur avec la première réponse dans l’espoir que celle-ci soit suffisante (et donc dans l’espoir d’éviter un nouvel
aller-retour de requête-réponse).
Afin d’aider le serveur à deviner la meilleure représentation, un agent utilisateur peut envoyer des champs d’en-tête de
demande qui décrivent ses préférences.
D’un autre côté, la négociation proactive présente des inconvénients inhérents à sa définition :
• Il est impossible pour le serveur de déterminer avec précision ce qui pourrait être « le meilleur » pour un utilisateur
donné ;
• Demander à l’agent utilisateur de décrire ses capacités dans chaque demande peut être à la fois très inefficace (étant
donné que seul un petit pourcentage des réponses ont plusieurs représentations) et un risque potentiel pour la
confidentialité de l’utilisateur ;
• La réutilisabilité des réponses pour la mise en cache partagée est limitée.
En plus de cela, un agent utilisateur ne peut pas compter sur le respect constant des préférences de négociation
proactives, car le serveur d’origine peut ne pas implémenter la négociation proactive pour la ressource demandée ou
peut décider que l’envoi d’une réponse non conforme aux préférences de l’agent utilisateur est préférable à l’envoi d’une
réponse 406 (Not Acceptable).
Un champ d’en-tête Vary est souvent envoyé dans une réponse soumise à une négociation proactive pour indiquer
quelles parties des informations de demande ont été utilisées dans l’algorithme de sélection.

Le champ d’en-tête Vary

Le champ d’en-tête Vary dans une réponse décrit quelles parties d’un message de demande, à part la méthode, le
champ d’en-tête de l’hôte et la cible de la demande, peuvent influencer le processus du serveur d’origine pour
sélectionner et représenter cette réponse.
Cela permet de déterminer comment les en-têtes de requêtes future sont associés pour décider si une réponse en cache
peut être réutilisée plutôt que de solliciter à nouveau le serveur d’origine.
La valeur de Vary peut être soit *, soit une liste de noms de champs d’en-tête. La valeur * indique que tout dans la
requête peut jouer un rôle dans la sélection de la représentation de la réponse. Une valeur composée d’une liste de noms
séparés par des virgules indique que les champs d’en-tête de requête nommés peuvent jouer un rôle dans la sélection de
la représentation.
Par exemple, une réponse contenant Vary : accept-encoding, accept-language indique que le serveur d’origine peut
avoir utilisé les champs Accept-Encoding et Accept-Language de la requête (ou leur absence) comme facteurs
déterminants lors du choix du contenu de cette réponse.

La négociation réactive en détail

La négociation de contenu est dite réactive lorsque la sélection de la meilleure représentation de réponse est effectuée
par l’agent utilisateur après avoir reçu une réponse initiale du serveur d’origine qui contient une liste de ressources pour
des représentations alternatives.

14/30
Si l’agent utilisateur n’est pas satisfait par la représentation de réponse initiale, il peut effectuer une requête GET sur une
ou plusieurs des ressources alternatives, sélectionnées en fonction des métadonnées incluses dans la liste, pour obtenir
une forme de représentation différente pour cette réponse. La sélection des alternatives peut être effectuée
automatiquement par l’agent utilisateur ou manuellement par l’utilisateur sélectionnant à partir d’un menu généré.
Notez qu’on parle ici généralement de représentations multiples de la réponse et non pas de la ressource demandée en
soi.
Un serveur peut choisir de ne pas envoyer une représentation initiale mais seulement une liste d’alternatives pour
indiquer ainsi que la négociation réactive par l’agent utilisateur est préférée.
Par exemple, les alternatives répertoriées dans les réponses avec le code de statut 300 (Multiple Choices) incluent des
informations sur les représentations disponibles afin que l’utilisateur ou l’agent utilisateur puisse réagir en effectuant une
sélection.
La négociation réactive est souhaitée lorsque le serveur d’origine est incapable de déterminer les capacités d’un agent
utilisateur à partir de l’examen de la requête.
La négociation proactive souffre également d’inconvénients inhérents à sa définition comme le fait de transmettre une
liste d’alternatives à l’agent utilisateur et de nécessiter une deuxième requête pour obtenir une représentation
alternative qui augmentent la latence perçue.

8) Les requêtes conditionnelles HTTP

Les requêtes conditionnelles sont des requêtes HTTP qui incluent un ou plusieurs champs d’en-tête indiquant une
condition préalable à tester avant d’appliquer la méthode à la ressource cible.

A quoi servent les requêtes HTTP conditionnelles

Concrètement, les requêtes conditionnelles vont pouvoir être utiles dans deux situations différentes :
• Pour valider un cache HTTP efficacement dans le cas d’une requête GET ;
• Pour éviter les problèmes d’écrasement et donc de perte de mise à jour dans le cas où deux clients modifieraient la
même ressource en même temps avec une requête PUT ou DELETE par exemple.

Comment fonctionne une requête conditionnelle ?

Les requêtes conditionnelles sont des requêtes où le résultat va pouvoir être différent en fonction de la valeur d’un
validateur.
Les validateurs vont prendre la forme d’en-têtes qu’on appelle des en-têtes conditionnelles. Ces en-têtes vont nous
permettre de définir une condition de départ et cette condition va justement conditionner le résultat de la requête (selon
que la condition soit validée ou pas).
Dans le cas d’une requête GET, par exemple, on va pouvoir utiliser des requêtes conditionnelles pour faire en sorte que le
serveur ne renvoie la ressource demandée que si elle a été modifiée ou un code 304 dans le cas contraire et ainsi
économiser des ressources.
Dans le cas d’une requête modifiant les informations sur serveur, on va pouvoir utiliser les requêtes conditionnelles pour
vérifier si la ressource en question n’a pas déjà été modifiée entre temps par un autre client et, dans le cas où celle-ci a
bien été modifiée, refuser les nouvelles modifications (et donc empêcher un écrasement des modifications précédentes).

Les types de validateurs : validateurs faibles et forts

On utilise les validateurs pour vérifier (« valider ») si la ressource stockée sur le serveur correspond à sa représentation
spécifique dont on dispose.
On classe les validateurs en deux catégories : les validateurs dits « faibles » et les validateurs dit « forts ».
Les validateurs forts permettent d’effectuer une comparaison (vérification) bit par bit entre la représentation de la
ressource dont on dispose et sa représentation sur serveur.
Les validateurs faibles sont plus laxistes : ils vont également comparer les représentation d’une ressource mais vont les
déclarer égales même si il existe des différences minimes entre elles.
Les validateurs faibles sont faciles à générer mais sont beaucoup moins utiles pour les comparaisons. Les validateurs
forts sont idéaux pour les comparaisons mais peuvent être très difficiles (et parfois impossibles) à générer efficacement.
Comme il sera parfois plus pertinent d’utiliser un validateur plutôt qu’un autre, HTTP n’impose pas que toutes les formes
de ressources adhèrent à la même force de validateur mais HTTP expose le type de validateur utilisé et impose des
restrictions lorsque des validateurs faibles peuvent être utilisés comme conditions préalables.

Les en-têtes Last-Modified et ETag

On va pouvoir créer des validateurs à des valeurs des en-têtes Last-Modified et ETag. Notez déjà que ces deux en-têtes
permettent en théorie chacun d’implémenter des validations faibles ou fortes mais que la complexité d’implémentation
va être plus ou moins grande en pratique.
Le champ d’en-tête de réponse Last-Modified contient la date et l’heure auxquelles le serveur d’origine pense que la
ressource a été modifiée pour la dernière fois.
On va l’utiliser comme validateur pour déterminer si une ressource reçue ou stockée est la même. Cet en-tête est moins
précis qu’un en-tête Etag.
Par défaut, la date fournie par Last-Modified, lorsqu’elle est utilisée comme validateur dans une requête est
implicitement faible sauf s’il est possible de déduire qu’elle est forte.
Les demandes conditionnelles contenant des en-têtes If-Modified-Since ou If-Unmodified-Since utilisent le champ
d’en-tête Last-Modified.
Le champ d’en-tête ETag dans une réponse est un identifiant pour une version spécifique d’une ressource. Si la ressource
à une URL donnée change, une nouvelle valeur ETag doit être générée.

15/30
Les valeurs des etags sont uniques et l’en-tête ETag est donc utilisé comme validateur fort par défaut.

Autres champs d’en-tête conditionnels

Les champs d’en-tête suivants permettent de créer des requêtes conditionnelles :
If-MatchPour les méthodes GET et HEAD, le serveur renverra la ressource demandée uniquement si elle correspond à l’un
des ETags répertoriés. Pour les méthodes non sûres, il ne téléchargera la ressource que dans ce cas.If-None-MatchPour
les méthodes GET et HEAD, le serveur renverra la ressource demandée avec un code 200 uniquement s’il n’a pas d’ETag
correspondant à ceux fournis. Pour les autres méthodes, la demande sera traitée uniquement si l’ETag de la ressource
éventuellement existante ne correspond à aucune des valeurs répertoriées.If-Modified-SinceLe serveur renverra la
ressource demandée, avec un code 200, uniquement si elle a été modifiée pour la dernière fois après la date indiquée. Si
la demande n’a pas été modifiée depuis, la réponse sera un 304 sans aucun corps. Cet en-tête ne peut être utilisé qu’avec
une méthode GET ou HEAD.If-Unmodified-SinceLe serveur renverra la ressource demandé, ou l’acceptera dans le cas
d’une méthode non sûre uniquement si elle n’a pas été modifiée pour la dernière fois après la date indiquée. Si la
ressource a été modifiée après la date indiquée, la réponse sera une erreur 412 (échec de la condition préalable). Avec
des méthodes non sûres, comme POST, cet en-tête peut être utilisé pour rejeter une édition si le document stocké a été
modifié depuis que l’original a été récupéré. Avec une demande de plage et un en-tête If-Range, cet en-tête peut être
utilisé pour garantir que le nouveau fragment demandé provient d’un document non modifié.If-RangeSi la condition est
remplie, la demande de plage sera émise et le serveur renvoie une réponse 206 (Partial Content)avec le corps approprié.
Si la condition n’est pas remplie, la ressource complète est renvoyée, avec un code de statut 200.

HTTP ET MODELES RESEAUX

9) Les modèles réseaux OSI et TCP/IP expliqués

Un protocole est un ensemble de règles qui définissent comment différents systèmes communiquent entre eux.
Dans le cas de réseaux, les protocoles définissent comment les données sont transférées d’un système à un autre.
Il est possible théoriquement d’utiliser un unique protocole qui prend les données d’une application informatique et les
envoie à une application sur un autre ordinateur. Le problème avec cette approche est qu’elle est très rigide, car tout
changement nécessite de modifier l’ensemble du protocole.
Pour ajouter de la souplesse et de l’efficacité, des modèles en couches (« stacks » ou « layers ») ont été définis. Chaque
protocole va appartenir à une couche précise et chaque couche va avoir une fonction différente des autres. Le grand
intérêt des modèles en couches réside dans la séparation des fonctions : on va pouvoir modifier des protocoles ou utiliser
un protocole d’une couche plutôt qu’un autre sans affecter les autres.
Aujourd’hui, dans le monde réseau, il existe deux modèles largement dominants : le modèle OSI qui définit 7 couches et
le modèle TCP/IP (« modèle Internet ») qui définit 4 couches.
Le modèle OSI est un modèle de réseau idéalisé (modèle conceptuel), tandis que le modèle TCP/IP est une implémentation
pratique.

Le modèle théorique OSI et ses 7 couches

Le modèle OSI (Open Systems Interconnection ou Interconnexion de Systèmes Ouverts en Français) est un modèle
conceptuel (théorique) dont le but est de définir des normes de communication entre différents systèmes informatiques.
Il est normé en 1984.
Ce modèle propose un système de communication composé de 7 couches différentes. L’idée derrière cette
représentation est une nouvelle fois de décomposer la communication entre deux périphériques en différentes « étapes »
bien définies afin qu’on puisse par la suite faire évoluer les composants de chacune des couches de manière
indépendante plutôt que de devoir modifier l’intégralité du processus de communication dès le changement d’un
composant.
Le modèle OSI ne donne qu’une définition générale de chaque couche (on parle de couche d’abstraction) sans spécifier
les services ni les protocoles utilisés par chacune d’entre elles. C’est aux concepteurs des protocoles de les créer de
façon à ce qu’ils respectent les règles et limites d’une couche en particulier.
Les 7 couches définies par le modèle OSI sont les suivantes :
N° de la couche Nom de la couche Unité de données
7 Application Données non transformées
6 Présentation Données non transformées
5 Session Données non transformées
4 Transport Segments
3 Réseau Paquets
2 Liaison des données Frames
1 Physique Bits

La couche application
La couche application est la couche la plus proche de l’utilisateur. La majorité des protocoles utilisés par les utilisateurs
se situent dans cette couche (HTTP, SMTP, FTP, etc.).
Cette couche interagit avec les applications logicielles qui implémentent des composants de communication. La couche
application est le point d’accès aux services réseaux.

16/30
La couche application a généralement pour fonction d’identifier les interlocuteurs, de déterminer si les ressources sont
disponibles et de synchroniser les communications.
La couche d’application en elle-même n’a aucun moyen de déterminer la disponibilité des ressources sur le réseau.
Notez que la couche application est la couche où il y a la plus grande diversité de protocoles. En effet, il n’y a pas
beaucoup de méthodes fondamentalement différentes permettant d’assurer les fonctions des couches 2 à 6 et leur
éventail de protocoles est donc assez
Pour la couche application, en revanche, on peut notamment utiliser les protocoles suivants (en se limitant au monde IP) :
• Les protocoles FTP (IETF), NFS (Sun Microsystems) et AFS, SMB/CIFS (Microsoft) pour le transfert de fichiers ;
• Les protocoles Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP), Internet Message Access Protocol (IMAP)
pour les services de messagerie ;
• Les protocoles Telnet, rlogin, Secure Shell (SSH) pour les sessions distantes ;
• Le protocole HTTP pour le transfert de ressources hypermédia comme les documents HTML ;
• Des protocoles d’exploitation et de gestion comme Domain Name System (DNS) pour la résolution d’adresse, Simple
Network Management Protocol pour la supervision.

La couche présentation
La couche présentation est chargée du formatage des données de la couche applicative afin qu’elles puissent être
envoyées à travers le réseau puis être lues à nouveau par les applications.

La couche session
La couche session contrôle les connexions entre les ordinateurs. Cette couche permet l’ouverture et la fermeture de
session et gère la synchronisation des échanges ainsi que les transactions.

La couche transport
La couche transport fournit les moyens concrets pour transférer des données de taille variable d’une source vers une
destination en conservant la qualité du service.
L’enjeu de la couche de transport est de réceptionner les données qui viennent des couches supérieures, de les
découper et de la faire transiter jusqu’à la couche réseau.
Cette couche est la première à communiquer directement avec la machine de destination : elle gère les communications
de bout en bout (“end to end”) entre processus (programmes en cours d’exécution).

La couche réseau
La couche réseau fournit les moyens concrets pour transférer des données de taille variable (appelés “paquets”) entre
différents réseaux de nœuds.
On va notamment effectuer le routage et l’adressage des paquets dans cette couche, c’est-à-dire qu’on va définir la route
que vont emprunter les paquets pour aller d’un point de départ à un point d’arrivée (d’un interlocuteur à l’autre).

La couche liaison des données

La couche liaison des données gère les communications entre deux machines directement connectées entre elles.
On va dans cette couche découper des données brutes en frames de tailles variables puis les envoyer de manière
séquentielle.
On va également dans cette couche détecter et pouvoir corriger les erreurs pouvant survenir dans la couche physique,
définir le protocole pour établir et mettre fin à une connexion entre deux périphériques connectés physiquement et
définir le protocole de contrôle de flux (régulation du trafic) entre eux.

La couche physique
La couche physique est chargée de la transmission des signaux entre les interlocuteurs. Son service est limité à
l’émission et la réception d’un bit ou d’un train de bits continu.
La couche physique est, comme son nom l’indique, la couche dans laquelle sont définis les protocoles du monde
physique (les différents câbles de transmission).

Le modèle pratique TCP/IP et ses 4 couches

Le modèle TCP/IP (encore appelé « modèle Internet »), qui date de 1976, a été stabilisé bien avant la publication du
modèle OSI en 1984.
Pour information, TCP/IP est un modèle dérivé de l’ARPANET dont le but était de maintenir les communications coûte que
coûte en cas d’attaque nucléaire. Il en découle un réseau basé sur le routage de paquets à travers une couche appelée
Internet.
Le modèle TCP/IP est une approche réaliste ou pratique d’un modèle réseau là où le modèle OSI est un modèle idéalisé
ou théorique. En conséquence, c’est le modèle TCP/IP qui est utilisé comme modèle de réseau de référence pour Internet.
Le modèle TFP/IP tient son nom de ses deux protocoles « majeurs » : les protocoles TCP (Transmission Control Protocol) et
IP (Internet Protocol).
Il présente aussi une approche modulaire (utilisation de couches) mais en contient uniquement quatre :
• La couche application ;
• La couche transport ;
• Internet ;
• Accès réseau.

17/30
 N° de la couche Nom de la couche Unité de données TCP/IP
7 Application Données non transformées application
6 Présentation Données non transformées application
5 Session Données non transformées application
4 Transport Segments segment
3 Réseau Paquets paquets
2 Liaison des données Frames frames
1 Physique Bits bits
I

La couche application
Le modèle TCP/IP regroupe les trois couches de session, présentation et application du modèle OSI dans une seule
couche application. En effet, d’un point de vue pratique, cela ne fait souvent pas beaucoup de sens de séparer ces
couches.
Cette couche contient tous les protocoles de haut niveau : FTP pour le transfert de fichiers, SMTP pour les mails, HTTP
pour le WWW, DNS pour les noms de domaine.

La couche transport
La couche transport assure la communication logique entre processus. Cette couche détermine comment les données
doivent être envoyées : de manière fiable ou pas.
Concrètement, on va pouvoir choisir entre deux protocoles dans la couche transport : TCP (Transmission Control Protocol)
et UDP (User Datagram Protocol).
TCP est un protocole de transfert fiable orienté connexion. Ce protocole contrôle et s’assure qu’il n’y ait ni perte ni
corruption de données. Il est donc en charge des erreurs. TCP est le protocole le plus utilisé sur le Web aujourd’hui.
UDP est un protocole de transfert non fiable et qui ne nécessite pas de connexion préalable. Ce protocole est
particulièrement utilisé pour les échanges où la perte de quelques données n’est pas grave (appel vidéo, jeu en ligne,
etc.) car il est plus rapide que TCP.

La couche Internet
Le but principal de la couche Internet est d’assurer la communication logique entre hôte, c’est-à-dire de transmettre
coûte que coûte les paquets d’un hôte à un autre et de faire en sorte qu’ils arrivent à destination. Le protocole principal
de cette couche est IP (Internet Protocol ou Protocole Internet). Les paquets peuvent prendre différentes routes pour
arriver à destination et arriver dans un ordre différent de l’ordre dans lequel ils ont été envoyés.
Dans son fonctionnement, la couche Internet n’est pas responsable d’une transmission fiable. Elle ne fournit qu’un
service peu fiable et une livraison optimale (via le routage et l’adressage). Étant donné que la livraison de paquets entre
divers réseaux est une opération intrinsèquement peu fiable et sujette aux pannes, la charge de la fiabilité a été placée
avec les points d’extrémité d’un chemin de communication, c’est-à-dire les hôtes, plutôt que sur le réseau.
Ce sera aux protocoles de plus haut niveau d’assurer la fiabilité du service.

La couche accès réseau

La couche accès réseau du modèle TCP/IP regroupe les couches physique et de liaison des données du modèle OSI. Cette
couche définit comment envoyer des paquets IP à travers le réseau (via des protocoles comme Ethernet ou Wireless
entre autres)

Comment se passe un échange de données en pratique ?

Pour bien comprendre l’ensemble des notions décrites ci-dessus, il me semble essentiel de visualiser comment se passe
un échange de données de manière pratique. Pour cela, prenons l’exemple d’un utilisateur qui souhaite accéder à une
page web.
Pour cela, les premiers protocoles utilisés vont être HTTP ou HTTPS (HTTP + le protocole de chiffrement TLS). HTTP va
nous permettre d’envoyer une demande (requête) au serveur. En l’occurrence, la requête sera « renvoie moi le
document HTML demandé ».
A ce niveau, d’autres protocoles vont être utilisés comme DNS (pour trouver le serveur où se situe le document), etc. Le
protocole HTTP permet de créer une requête HTTP. Cette requête (ces données) vont devoir être transportées à travers
les réseaux.
Pour cela, on va déjà devoir utiliser un protocole de transport comme TCP par exemple. Celui-ci va garantir l’intégrité des
données et la transmission entre processus. A ce niveau, dans la couche de transport, les données venant de différents
processus sont transformées en segments.
Chaque segment contient la donnée originale à laquelle est accolée un en-tête de transport. Cet en-tête contient les
numéros de ports de la source et de la destination afin que les données puissent être transmises de manière effective.
Ces segments sont ensuite transmis aux protocoles de la couche Internet. Le rôle de cette couche est de choisir la route
la plus rapide à travers le réseau pour que les données arrivent à destination. Les segments sont alors transformés en
paquets. Cette couche se charge également de l’adressage des données en ajoutant un en-tête aux paquets qui contient
l’adresse IP de destination et celle de départ.
Les paquets sont ensuite à nouveau transformés en frames dans la couche d’accès réseau. A ce niveau, on ajoute un en-
tête contenant les adresses MAC (Media Access Control – adresses qui permettent d’identifier tout périphérique de
manière unique) source et de destination.
Dans cette même couche, les informations sont finalement transformées en bits (0 et 1 qui correspondent au langage de
la machine) et ces bits sont envoyés dans le réseau (les 0 et les 1 sont encodées dans les câbles en utilisant des
transmissions électriques ou des impulsions lumineuses dans le cas de la fibre).
Dès que ces bits arrivent à destination, les opérations se déroulent dans le sens inverse : les bits sont reformés en
18/30
frames, puis en paquets, en segments et enfin les données de base sont reconstituées.
Dans le cas d’une demande de page Internet, le serveur reçoit donc la requête originale et renvoie une réponse. Les
mêmes opérations sont à nouveau effectuées avec transformation des données pour qu’elles puissent transiter puis
reconstitution du côté du client.
Vous pouvez noter qu’on appelle la phase de transformation de l’information en bits l’encapsulation tandis que la phase
inverse de reconstitution des données s’appelle la décapsulation.

10) Zoom sur TCP, le Protocole de Contrôle de Transmission

Transmission Control Protocol (TCP ou protocole de contrôle de transmissions) est un protocole de transport fiable en mode
connecté.
TCP est utilisé approximativement pour 95 % de tout le trafic Internet. Les applications les plus courantes qui utilisent
TCP sont HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (messagerie) et FTP (transfert de fichiers).
Le mode connecté est l’établissement d’une session de communication entre deux parties qui veulent échanger des
données. Cette session comporte un début, une fin et une validation (vérification des erreurs), classiquement un
identifiant un mot de passe. Elle correspond à la couche de session du modèle OSI (située entre les couches «
présentation » et « transport »).
Dans le modèle Internet, aussi appelé modèle TCP/IP, TCP est situé au-dessus de IP. Dans le modèle OSI, il correspond à
la couche transport, intermédiaire entre la couche réseau et la couche session. Les applications transmettent des flux de
données sur une connexion réseau. TCP découpe le flux d’octets en segments dont la taille dépend de la MTU (Unité de
Transmission Maximale) de la couche de liaison de données.
Une session TCP fonctionne en trois phases :
• l’établissement de la connexion ;
• les transferts de données ;
• la fin de la connexion.

La connexion TCP : le three way handshake

Selon le protocole de communication TCP, une connexion entre deux hôtes s’établit en trois étapes : c’est le three-way
handshake. Pendant la phase d’établissement de la connexion, des paramètres comme le numéro de séquence sont
initialisés afin d’assurer la transmission fiable (sans perte et dans l’ordre) des données.
En informatique, en télécommunications et dans les domaines associés, le handshaking (ou handshake ; en français,
établissement d’une liaison1) est un processus automatisé de négociation qui établit les paramètres d’une
communication entre deux entités avant que la communication commence.
Comme son nom l’indique, le three-way handshake se déroule en trois étapes :
1. SYN : Le client qui désire établir une connexion avec un serveur va envoyer un premier paquet SYN (« synchronized »)
au serveur. Le numéro de séquence de ce paquet est un nombre aléatoire A.
2. SYN-ACK : Le serveur va répondre au client à l’aide d’un paquet SYN-ACK (« synchronize, acknowledge »). Le numéro du
ACK est égal au numéro de séquence du paquet précédent (SYN) incrémenté de un (A + 1) tandis que le numéro de
séquence du paquet SYN-ACK est un nombre aléatoire B.
3. ACK : Pour terminer, le client va envoyer un paquet ACK au serveur qui va servir d’accusé de réception. Le numéro de
séquence de ce paquet est défini selon la valeur de l’acquittement reçu précédemment (par exemple : A + 1) et le numéro
du ACK est égal au numéro de séquence du paquet précédent (SYN-ACK) incrémenté de un (B + 1).

Le transfert de données
Pendant la phase de transferts de données, certains mécanismes clefs permettent d’assurer la robustesse et la fiabilité
de TCP. En particulier, les numéros de séquence sont utilisés afin d’ordonner les segments TCP reçus et de détecter les
données perdues, les sommes de contrôle permettent la détection d’erreurs, et les acquittements ainsi que les
temporisations permettent la détection des segments perdus ou retardés.
La somme de contrôle ou checksum en anglais, parfois appelée « empreinte », est un nombre qu’on ajoute à un message
à transmettre pour permettre au récepteur de vérifier que le message reçu est bien celui qui a été envoyé.
Grâce aux numéros de séquence et d’acquittement, les systèmes terminaux peuvent remettre les données reçues dans
l’ordre à l’application destinataire.
Les numéros de séquence sont utilisés pour décompter les données dans le flux d’octets. On trouve toujours deux de ces
nombres dans chaque segment TCP, qui sont le numéro de séquence et le numéro d’acquittement. Le numéro de
séquence représente le propre numéro de séquence de l’émetteur TCP, tandis que le numéro d’acquittement représente
le numéro de séquence du destinataire. Afin d’assurer la fiabilité de TCP, le destinataire doit acquitter les segments reçus
en indiquant qu’il a reçu toutes les données du flux d’octets jusqu’à un certain numéro de séquence.
Une somme de contrôle sur 16 bits, constituée par le complément à un de la somme complémentée à un de tous les
éléments d’un segment TCP (en-tête et données), est calculée par l’émetteur, et incluse dans le segment émis. Le
destinataire recalcule la somme de contrôle du segment reçu, et si elle correspond à la somme de contrôle reçue, on
considère que le segment a été reçu intact et sans erreur.
La perte d’un segment est gérée par TCP en utilisant un mécanisme de temporisation et de retransmission. Après l’envoi
d’un segment, TCP va attendre un certain temps la réception du ACK correspondant. Un temps trop court entraîne un
grand nombre de retransmissions inutiles et un temps trop long ralentit la réaction en cas de perte d’un segment.
Dans les faits, le délai avant retransmission doit être supérieur au RTT (round trip time) moyen d’un segment, c’est-à-dire
au temps que prend un segment pour effectuer l’aller-retour entre le client et le serveur. Comme cette valeur peut varier
dans le temps, on « prélève » des échantillons à intervalle régulier et on en calcule une moyenne pondérée
Chaque partenaire dans une connexion TCP dispose d’un tampon de réception dont la taille n’est pas illimitée. Afin
d’éviter qu’un hôte ne surcharge l’autre, TCP prévoit plusieurs mécanismes de contrôle de flux. Ainsi, chaque segment
TCP contient la taille disponible dans le tampon de réception de l’hôte qui l’a envoyé. En réponse, l’hôte distant va limiter
la taille de la fenêtre d’envoi afin de ne pas le surcharger.

19/30
Fermeture de la connexion
La phase de terminaison d’une connexion utilise un handshaking en quatre temps, chaque extrémité de la connexion
effectuant sa terminaison de manière indépendante. Ainsi, la fin d’une connexion nécessite une paire de segments FIN et
ACK pour chaque extrémité.

Ports TCP
Le numéro de port est utilisé par TCP (et par UDP) pour identifier les applications, c’est-à-dire pour distinguer les
différents interlocuteurs. À chaque extrémité (client/serveur) de la connexion TCP est associé un numéro de port sur 16
bits (de 1 à 65535) assigné à l’application émettrice ou réceptrice. Ces ports sont classés en trois catégories :
• Les ports bien connus, assignés par l’IANA (Internet Assigned Numbers Authority) dans la plage 0-1023 et qui sont
souvent utilisés par des applications bien connues qui fonctionnent en tant que serveur et sont en attente de connexions
comme FTP (port 21), SSH (port 22), Telnet (23), SMTP (25), HTTP (80), POP3 (110) ;
• Les ports enregistrés généralement utilisés par des applications utilisateur comme ports sources éphémères pour se
connecter à un serveur, mais qui peuvent également identifier des services non enregistrés par l’IANA ;
• Les ports dynamiques/privés qui peuvent aussi être utilisés par des applications utilisateur, mais plus rarement. Ils n’ont
pas de sens en dehors d’une connexion TCP particulière.

11 ) Zoom sur IP, le Protocole Internet

Internet protocol (protocole internet, abrégé en IP) est une famille de protocoles de communication de réseaux
informatiques conçus pour être utilisés sur Internet. Les protocoles IP sont au niveau 3 dans le modèle OSI. Les protocoles
IP s’intègrent dans la suite des protocoles Internet et permettent un service d’adressage unique pour l’ensemble des
terminaux connectés.
Le protocole Internet (IP) est un ensemble d’exigences pour l’adressage et le routage des données sur Internet. IP peut
être utilisé avec plusieurs protocoles de transport, notamment TCP et UDP.

L’adressage IP
Lors d’une communication entre deux postes, le flux de données provenant de la couche transport — niveau 4 du modèle
OSI — (par exemple des segments TCP) est encapsulé dans des paquets par le protocole IP lors de leur passage au
niveau de la couche réseau. Ces paquets sont ensuite transmis à la couche liaison de données — niveau 2 du modèle OSI
— afin d’y être encapsulés dans des trames (par exemple Ethernet).
Les données traversant Internet sont divisées en morceaux plus petits, appelés paquets. Des informations IP sont
attachées à chaque paquet, et ces informations aident les routeurs à envoyer des paquets au bon endroit. Chaque
appareil ou domaine qui se connecte à Internet se voit attribuer une adresse IP et, comme les paquets sont dirigés vers
l’adresse IP qui leur est attachée, les données arrivent là où elles sont nécessaires.
Les paquets IP sont créés en ajoutant un en-tête IP à chaque paquet de données avant son envoi. Un en-tête IP n’est
qu’une série de bits (uns et zéros) qui enregistre plusieurs informations sur le paquet, y compris l’adresse IP d’envoi et
de réception. Les en-têtes IP indiquent également:
• Longueur de l’en-tête ;
• Longueur du paquet ;
• Time To Live (TTL), ou le nombre de sauts de réseau qu’un paquet peut faire avant qu’il ne soit jeté ;
• Quel protocole de transport est utilisé (TCP, UDP, etc.).
Au total, il existe 14 champs d’informations dans les en-têtes IPv4, bien que l’un d’entre eux soit facultatif.
Une adresse IP est un identifiant unique attribué à un appareil ou un domaine qui se connecte à Internet. Chaque adresse
IP est une série de caractères, tels que «192.168.1.1». Grâce aux résolveurs DNS, qui traduisent les noms de domaine
lisibles par l’homme en adresses IP, les utilisateurs peuvent accéder à des sites Web sans mémoriser cette série
complexe de caractères.
Chaque paquet IP contiendra à la fois l’adresse IP de l’appareil ou du domaine envoyant le paquet et l’adresse IP du
destinataire prévu, de la même façon que l’adresse de destination et l’adresse de retour sont incluses dans une pièce de
courrier ou dans un email.

Le routage IP
Avec l’adressage, le routage est l’une des principales fonctions du protocole IP. Le routage consiste à transmettre des
paquets IP de la source aux machines de destination sur un réseau, en fonction de leurs adresses IP. Cette transmission
se produit généralement via un routeur.
Les protocoles IP assurent l’acheminement au mieux (best-effort delivery) des paquets. Ils ne se préoccupent pas du
contenu des paquets, mais fournissent une méthode pour les mener à destination.
Les protocoles IP sont considérés comme « non fiables ». Cela ne signifie pas qu’ils n’envoient pas correctement les
données sur le réseau, mais qu’ils n’offrent aucune garantie pour les paquets envoyés quant à :
• la corruption de données ;
• l’ordre d’arrivée des paquets (un paquet A peut être envoyé avant un paquet B, mais le paquet B peut arriver avant le
paquet A) ;
• la perte ou destruction de paquets ;
• la duplication des paquets.
En termes de fiabilité, le seul service offert par un protocole IP est de s’assurer que les en-têtes de paquets transmis ne
comportent pas d’erreurs grâce à l’utilisation de somme de contrôle (checksum). Si l’en-tête d’un paquet comprend une
erreur, sa somme de contrôle ne sera pas valide et le paquet sera détruit sans être transmis.

20/30
Les versions IP : IPv4 et IPv6
IPv4 utilise des adresses codées sur 32 bits (soit en théorie 4 294 967 296 adresses possibles) tandis qu’IPv6 les code sur
128 bits (soit en théorie 3,4 × 1038 adresses possibles).
Le premier champ d’un paquet d’un protocole IP est composé de 4 bits qui indiquent la version du protocole utilisé. La
valeur 0100 (4 en binaire) est utilisée pour IPv4, 0110 (6 en binaire) pour IPv6.
Les versions 1 à 3 du protocole sont restées expérimentales. Elles ont été utilisées entre 1977 et 1979.
La version 4 du protocole est une version qui a été très largement utilisée. Le nombre 4 est le numéro de version du
protocole porté par les datagrammes IP qui l’utilisent. IPv4 est défini dans la RFC RFC 7919 de 1981.
La version 5 du protocole est une version expérimentale utilisée dans le cadre de l’étude du Internet Stream Protocol,
protocole lui-même expérimental.
Le successeur officiel du protocole IPv4 est IPv6. Ce protocole est le résultat de plusieurs années d’expérimentation et
d’échanges au cours desquels plusieurs protocoles ont été proposés (TP/IX, PIP, TUBA…).

12 ) Zoom sur le protocole SPDY

SPDY est un protocole réseau appartenant à la couche application créé par Google dans le cadre de l’initiative « let’s make
the Web faster ».
Le but principal de SPDY est d’améliorer les capacités du protocole HTTP, c’est-à-dire de réduire la latence des échanges
HTTP entre le client et le serveur (= réduire la durée de téléchargement des pages Web).
En effet, Google part de la constatation suivante pour le développement de SPDY : le HTTP n’a pas été conçu au départ
pour réduire la latence. En plus de cela, le Web a énormément évolué depuis la création de HTTP et les pages sont
aujourd’hui très différentes (inclusion de styles CSS, de médias, de fichiers JavaScript, etc.) et le HTTP ne s’est pas bien
adapté à tous ces changements.
Parmi les facteurs limitant la performance, il est notamment cité que HTTP/1 ne peut extraire qu’une ressource à la foi ce
qui entraine à priori de gros problèmes de latente due aux nombreux aller-retours client / serveur nécessaires pour
récupérer les différentes ressources d’une page. Les navigateurs contournent ce problème en utilisant plusieurs
connexions mais cela reste non optimal.
En plus de cela, avec HTTP, seul le client peut initier une demande. Même si le serveur sait que le client a besoin d’une
ressource, il n’a aucun mécanisme pour informer le client et doit plutôt attendre de recevoir une demande de la ressource
du client.
En outre, le HTTP/1 ne possède pas de mécanisme de compression des en-têtes et certains en-têtes sont renvoyés
plusieurs fois dans différentes requêtes ce qui augmente inutilement le poids de chaque requête.
SPDY a pour but de s’attaquer à ces problèmes en fournissant des solutions d’optimisation au-dessus de HTTP. Les
principales techniques utilisées sont :
• La compression des en-têtes HTTP ;
• La pré-lecture des requêtes ;
• La priorisation des requêtes ;
• Le multiplexage.
SPDY utilise des techniques de compression des en-tête HTTP. En plus de cela, SPDY conserve une liste des en-têtes HTTP
déjà envoyés durant une session afin de ne pas les renvoyer inutilement.
SPDY permet également à certains serveurs d’effectuer une pré-lecture / de deviner que certaines ressources vont être
nécessaires au client et de les envoyer avant même que le client n’envoie une requête. Par exemple, si un client
demande au fichier HTML qui contient des liens vers des feuilles de style CSS, un serveur SPDY pourrait analyser le code
HTML, et envoyer le CSS sans attendre que le demande.
HTTP/1 gère des connexions parallèles de manière limitée (entre 6 et 8 selon le navigateur). Si les connexions sont plus
nombreuses, il faudra attendre que les connexions précédentes soient résolues. SPDY permet de contourner cette
limitation en utilisant des flux hiérarchisés de façon à ce que les requête les plus importantes soient résolues en premier.
SPDY permet aussi le multiplexage qui permet également de résoudre le problème des connexions parallèles limitées. Le
multiplexage correspond à la combinaison de nombreux signaux en un seul : un navigateur utilisant SPDY va combiner
plusieurs requêtes en une seule qui va être envoyée au serveur. Le serveur va ensuite décomposer cette requête pour
récupérer l’ensemble des requêtes originales combinées. C’est ce qu’on appelle le démultiplexage.
Dès 2012, Google se rapproche de l’IETF (le groupe responsable du développent de HTTP entre autres) afin que SPDY soit
standardisé. SPDY est intégré dans HTTP/2 dès sa sortie (en mai 2015) et Google abandonne donc le développement du
protocole, laissant son évolution à l’IETF.

13) Zoom sur le protocole QUIC

QUIC (originellement l’acronyme de « Quick UDP Internet Connections ») est un protocole à usage général créé par Google
en 2012.
En 2016, Google passe les documents de ce protocole au groupe de travail de l’IETF (Internet Engineering Task Force –
groupe chargé d’établir des standards pour la suite de protocoles du modèle Internet) pour qu’il poursuive son évolution
et qu’il soit intégré à la suite de protocoles du modèle Internet.
L’objectif premier de QUIC est d’améliorer les performances des applications Web orientées connexion qui utilisent
actuellement TCP en utilisant des connexions multiplexées et en réduisant la latence durant la connexion et le transport
notamment.
En effet, l’un des principaux objectifs de HTTP/2 était d’éviter le blocage en tête de ligne (« head of line blocking » ou
blocage HOL). Le blocage en tête de ligne est un phénomène limitant les performances qui se produit lorsqu’un
ensemble de paquets (et donc de requêtes) est bloqué par le premier paquet (et donc la première requête), c’est-à-dire
par le paquet en « tête de ligne ».
Pour résoudre ce problème, HTTP/2 a implémenté le multiplexage au-dessus de TCP. Le multiplexage HTTP correspond à
la réutilisation des connexions de serveur établies pour les connexions de plusieurs clients. Grosso modo, l’idée est de
laisser une connexion au serveur ouverte un certain temps plutôt que de la fermer immédiatement afin de pouvoir
réutiliser cette même connexion dans le cas où le client effectue une nouvelle requête au serveur. Le multiplexage
permet ainsi d’effectuer plusieurs requêtes sur une même connexion et permet de réduire la latence.

21/30
Le problème avec HTTP/2 est que la correction du blocage de tête de ligne dans HTTP a repoussé une partie du problème
au niveau de la couche transport. En effet, lorsqu’un paquet est perdu, TCP met en tampon tous les paquets suivants
jusqu’à ce qu’il soit retransmis avec succès, même lorsque l’application pourrait utiliser certaines de ces données mises
en mémoire tampon (comme c’est le cas lorsque le multiplexage est activé avec HTTP). Ainsi, certaines connexions HTTP
avec pertes inhérentes comme le streaming vidéo par exemple ont vu constaté des performances réduites avec HTTP/2.
Le protocole TCP garantit l’intégrité des données. Pour ce faire, TCP décompose les données en paquets réseau et ajoute
de petites quantités de données à chaque paquet. Ces données supplémentaires comprennent un numéro de séquence
utilisé pour détecter les paquets perdus ou transmis dans le désordre, et une somme de contrôle qui permet de détecter
les erreurs dans les données de paquet. Si un problème survient, TCP utilise un procédé de répétition automatique de
requête (ARQ = automatic repeat request) pour dire à l’expéditeur de renvoyer le paquet perdu ou endommagé.
Les erreurs sont bloquantes pour TCP dans la plupart des implémentations, ce qui signifie que les autres transferts vont
être mis en attente jusqu’à ce que l’erreur soit résolue ou que la connexion soit considérée comme ayant échoué. Si une
seule connexion est utilisée pour envoyer plusieurs flux de données, comme c’est le cas dans le protocole HTTP/2, tous
ces flux sont bloqués bien qu’un seul d’entre eux puisse avoir un problème.
TCP est conçu pour ressembler à un flux de données et contient délibérément peu de compréhension des données qu’il
transmet. Si ces données ont des exigences supplémentaires, comme le chiffrement à l’aide de TLS, cela doit être
configuré par des systèmes fonctionnant au-dessus de TCP. Ce type d’opération nécessite d’établir une nouvelle liaison
(un handshake) à chaque fois et on va donc souvent avoir plusieurs allers-retours de requêtes et de réponses jusqu’à ce
que la connexion soit établie. En raison de la latence inhérente des communications à longue distance, cela peut ajouter
une surcharge importante à la transmission globale.
QUIC se base sur le modèle de flux HTTP/2 et l’intègre dans la couche de transport, de sorte qu’une seule connexion
puisse progresser sur un flux même si des paquets contenant des données provenant d’autres flux sont perdus,
atténuant ainsi le problème de blocage en tête de ligne dans le transport ainsi que dans la couche d’application.
Pour faire cela, QUIC est construit sur le protocole UDP (User Datagram Protocol) plutôt que sur TCP et intègre le cryptage
par défaut.
Aujourd’hui, la plupart des connexions HTTP sont sécurisées (HTTPS) via TLS. QUIC intègre l’échange des clés de
configuration et des protocoles pris en charge dans le processus de prise de contact initial. Ainsi, lorsqu’un client ouvre
une connexion, le paquet de réponse inclut les données nécessaires pour que les futurs paquets puissent utiliser le
chiffrement. Cela élimine le besoin de configurer la connexion TCP, puis de négocier le protocole de sécurité via des
paquets supplémentaires.
QUIC est également construit sur UDP qui n’inclut pas de mécanisme de récupération des pertes. Pour contourner ce
problème, chaque flux QUIC est contrôlé indépendamment et les données perdues sont retransmises au niveau de QUIC
et non pas de UDP.
Cela signifie que si une erreur se produit dans un flux la pile de protocoles peut continuer à desservir d’autres flux
indépendamment. Cela améliore grandement les performances sur les liaisons sujettes aux erreurs puisque dans la
plupart des cas une quantité non négligeable de données peuvent être reçues avant que TCP ne remarque qu’un paquet
est manquant ou cassé et ces données vont alors être bloquées voire effacées pendant que l’erreur est corrigée tandis
qu’avec QUIC ces données sont libres d’être traitées pendant que le flux multiplexé unique est réparé.
En octobre 2018, les groupes de travail HTTP et QUIC de l’IETF ont décidé conjointement d’appeler le mappage HTTP sur
QUIC « HTTP/3 » avant d’en faire une norme mondiale. HTTP/3 est dont bâti sur QUIC et fonctionne avec UDP plutôt
qu’avec TCP comme protocole de transport des données.
TCP est aujourd’hui encore considéré comme étant la norme et l’infrastructure Internet en général est configurée pour
fonctionner avec ce processus et dans certains cas certains composants peuvent bloquer UDP. Dans ces cas, un système
de repli rapide vers TCP qui n’entraine pas de latence est utilisé.

14) Zoom sur UDP, le Protocole de Datagramme Utilisateur

Le User Datagram Protocol (UDP, en français protocole de datagramme utilisateur) est un des principaux protocoles de
télécommunication utilisés par Internet. Il fait partie de la couche transport du modèle OSI (comme TCP). Il ne fournit pas
de garantie au protocole de la couche supérieure quant à la livraison du message. De plus, la couche UDP ne retient pas
d’information quant à l’état des messages UDP une fois envoyés. Pour ces raisons, on désigne UDP comme un protocole
de transmission non fiable1.
Le rôle de ce protocole est de permettre la transmission de données (sous forme de datagrammes) de manière très
simple entre deux entités, chacune étant définie par une adresse IP et un numéro de port. Aucune communication
préalable n’est requise pour établir la connexion, au contraire de TCP (qui utilise le procédé de handshaking). UDP utilise
un mode de transmission sans connexion.
L’intégrité des données est assurée par une somme de contrôle sur l’en-tête (header). L’utilisation de cette somme est
cependant facultative en IPv4 mais obligatoire avec IPv6. Si un hôte n’a pas calculé la somme de contrôle d’un
datagramme émis, la valeur de celle-ci est fixée à zéro. La somme de contrôle inclut également les adresses IP de la
source et de la destination.
À cause de l’absence de mécanisme de handshaking, ce protocole expose le programme qui l’utilise aux problèmes
éventuels de fiabilité du réseau ; ainsi, il n’existe pas de garantie de protection quant à la livraison, l’ordre d’arrivée, ou
la duplication éventuelle des datagrammes.
Si des fonctionnalités de correction d’erreur sont requises, une application peut donc se tourner vers les protocoles TCP
ou SCTP, qui sont conçus à cet effet. UDP est donc adapté à un usage pour lequel la détection et la correction d’erreurs
ne sont pas nécessaires, ou sont effectuées directement par l’application.
La nature du protocole UDP le rend utile pour transmettre rapidement de petites quantités de données, depuis un
serveur vers de nombreux clients ou bien dans des cas où la perte éventuelle d’un datagramme est préférée à l’attente
de sa retransmission. Les jeux en ligne et le streaming sont des utilisateurs typiques de ce protocole.

Qu’est-ce qu’un datagramme

Un datagramme est un paquet de données dans un réseau informatique ou un réseau de télécommunications. Il est
utilisé par des protocoles orientés « non connectés » tels que : IPX ou UDP. Le datagramme est le terme généralement
utilisé pour désigner la transmission d’un paquet via un service non « fiable » : le protocole utilisé ne garantit pas que le

22/30
paquet est arrivé à sa destination (un peu comme une lettre sans accusé de réception).
L’en-tête d’un datagramme UDP est plus simple que celui de TCP. Il contient 4 champs :
• Le port source (16 bits) qui indique depuis quel port le paquet a été envoyé.
• Le port de destination (16 bits) qui indique à quel port le paquet doit être envoyé.
• La longueur (16 bits) qui indique la longueur totale (exprimée en octets) du segment UDP (en-tête et données). La
longueur minimale est donc de 8 octets (taille de l’en-tête).
• La somme de contrôle (16 bits) qui permet de s’assurer de l’intégrité du paquet reçu quand elle est différente de zéro.
Elle est calculée sur l’ensemble de l’en-tête UDP et des données, mais aussi sur un pseudo en-tête (extrait de l’en-tête IP).

Qu’est-ce qu’un handshake

En informatique, en télécommunications et dans les domaines associés, le handshaking (ou handshake ; en français,
établissement d’une liaison) est un processus automatisé de négociation qui établit les paramètres d’une communication
entre deux entités avant que la communication commence.
Un handshake est fait au moment où un ordinateur veut entreprendre une communication avec un appareil plus ou moins
éloigné, par exemple un modem, une imprimante ou un serveur. Sur les anciens modem 56 kb/s, le processus de
handshaking durait 20 secondes et était audible, chaque son émis par le modem de l’utilisateur correspondant à une
étape du handshaking.
Le handshaking peut négocier les paramètres que des équipements et systèmes situés aux deux extrémités du lien de
communication pourront utiliser, y compris le débit binaire, l’encodage alphabétique, la parité, la procédure d’interruption
et d’autres protocoles et détails techniques. . Cependant, dans les RFCs concernant TCP/IP, le terme « handshake » fait
plutôt référence au TCP three-way handshake.

HTTP ET SECURITE

15) L’authentification HTTP

HTTP fournit un cadre général pour le contrôle d’accès et l’authentification, via un ensemble extensible de schémas
d’authentification de type « défi-réponse », qui peuvent être utilisés par un serveur pour contester une requête client et
par un client pour fournir des informations d’authentification.

Fonctionnement général de l’authentification HTTP

HTTP utilise un jeton (token) insensible à la casse comme moyen d’identifier le schéma d’authentification, suivi des
informations supplémentaires nécessaires pour réaliser l’authentification via ce schéma. Ce dernier peut être soit une
liste de paramètres séparés par des virgules, soit une seule séquence de caractères capable de contenir des informations
codées en base64.
Les paramètres d’authentification sont des paires nom = valeur.
Un message de réponse 401 (Unauthorized) est utilisé par un serveur d’origine pour contester l’autorisation d’un agent
utilisateur. Ce message contient un champ d’en-tête WWW-Authenticate contenant au moins un défi applicable à la
ressource demandée.
Un message de réponse 407 (Proxy Authentication Required) est utilisé par un proxy pour contester l’autorisation d’un
client. Ce message contient un champ d’en-tête Proxy-Authenticate contenant au moins un challenge applicable au proxy
pour la ressource demandée.
Un agent utilisateur qui souhaite s’authentifier auprès d’un serveur d’origine – généralement, mais pas nécessairement,
après avoir reçu un 401 (non autorisé) – peut le faire en incluant un champ d’en-tête Authorization avec la requête.
Un client qui souhaite s’authentifier avec un proxy – généralement, mais pas nécessairement, après avoir reçu un 407
(authentification proxy requise) – peut le faire en incluant un champ d’en-tête Proxy-Authorization avec la requête.
La valeur du champ Authorization et celle du champ Proxy-Authorization contiennent les informations d’identification du
client pour le realm (l’espace de protection) de la ressource demandée, en fonction d’un défi reçu dans une réponse.
À la réception d’une requête d’accès à une ressource protégée qui omet les informations d’identification, contient des
informations d’identification non valides (par exemple, un mauvais mot de passe) ou des informations d’identification
partielles (par exemple, lorsque le schéma d’authentification nécessite plus d’un aller-retour), un serveur d’origined
evrait envoyer une réponse 401 contenant un champ d’en-tête WWW-Authenticate avec au moins un (éventuellement
nouveau) défi applicable à la ressource demandée.
De même, à la réception d’une demande qui omet les informations d’identification de proxy ou contient des informations
d’identification de proxy non valides ou partielles, un proxy qui requiert une authentification devrait générer une réponse
407 contenant un champ d’en-tête Proxy-Authenticate avec au moins un (éventuellement nouveau) défi applicable au
proxy.
Un serveur qui reçoit des informations d’identification valides mais qui ne sont pas suffisantes pour accéder à une
réponse doit répondre avec le code de statut 403 (Forbidden).

Les codes de statut 401 et 407 en détail

Le code de statut 401 indique que la requête n’a pas été satisfaite car il manque des informations d’identification
d’authentification valides pour la ressource cible. Le serveur générant une réponse 401 doit envoyer un champ d’en-tête
WWW-Authenticate (section 4.1) contenant au moins un défi applicable à la ressource cible.
Si la requête incluait des informations d’authentification, la réponse 401 indique que l’autorisation a été refusée pour ces
informations. L’agent utilisateur PEUT répéter la demande avec un champ d’en-tête Authorization nouveau ou remplacé.
Le code de statut 407 est similaire au code 401 mais il indique que le client doit s’authentifier pour utiliser un proxy. Le
mandataire doit envoyer un champ d’en-tête Proxy-Authenticate contenant un défi applicable à ce mandataire pour la

23/30
ressource cible. Le client peut répéter la demande avec un champ d’en-tête Proxy-Authorization nouveau ou remplacé.

Les en-têtes de réponse WWW-Authenticate et Proxy-Authenticate

Les en-têtes de réponse WWW-Authenticate et Proxy-Authenticate définissent la méthode d’authentification à utiliser
pour accéder à une ressource. Ils doivent spécifier le schéma d’authentification utilisé, afin que le client qui souhaite
autoriser sache comment fournir les informations d’identification. La syntaxe de ces en-têtes est la suivante:
WWW-Authenticate: type realm = realm
Authentification proxy: type realm = realmIci, « type » est le schéma d’authentification (« Basic » est le schéma le
plus courant). Le realm est utilisé pour décrire la zone protégée ou pour indiquer l’étendue de la protection. Il peut s’agir
d’un message du type « Accès à l’espace réservé » ou similaire, afin que l’utilisateur sache à quel espace il tente
d’accéder.

Les en-têtes de requête Authorization et Proxy-Authorization

Les en-têtes de requête Authorization et Proxy-Authorization contiennent les informations d’identification pour
authentifier un agent utilisateur avec un serveur ou un proxy. Ici, le type est à nouveau nécessaire suivi des informations
d’identification, qui peuvent être encodées ou chiffrées selon le schéma d’authentification utilisé.
Authorization: type credentials
Proxy-Authorization: type credentials

Le schéma d’authentification Basic et la sécurité

Dans le cas d’une authentification avec un schéma Basic, l’échange doit avoir lieu via une connexion HTTPS (TLS) pour
être sécurisé.
Le schéma d’authentification HTTP Basic transmet les informations d’identification sous forme de paires ID utilisateur /
mot de passe, codées en base64. Comme l’ID utilisateur et le mot de passe sont transmis sur le réseau en texte clair (il
est codé en base64, mais en base64 est un codage réversible), le schéma d’authentification de base n’est pas sécurisé.
HTTPS / TLS doit être utilisé conjointement avec l’authentification de base. Sans ces améliorations de sécurité
supplémentaires, l’authentification de base ne doit pas être utilisée pour protéger des informations sensibles ou
précieuses.
Pour protéger par mot de passe un répertoire sur un serveur Apache, vous aurez besoin d’un fichier .htaccess et d’un
fichier .htpasswd.
Le fichier .htaccess ressemble généralement à ceci:

AuthType Basic
AuthName "Accès à l’espace protégé"
AuthUserFile /path/to/.htpasswd
Require valid-userLe fichier .htaccess fait référence à un fichier .htpasswd dans lequel chaque ligne se compose d’un
nom d’utilisateur et d’un mot de passe séparés par deux points (« : »). Vous ne pouvez pas voir les mots de passe réels
car ils sont cryptés (md5 dans ce cas).
Pour nginx, vous devrez spécifier un emplacement que vous allez protéger et la directive auth_basic qui fournit le nom de
la zone protégée par mot de passe. La directive auth_basic_user_file pointe ensuite vers un fichier .htpasswd contenant
les informations d’identification utilisateur chiffrées, tout comme dans l’exemple Apache ci-dessus.

Le schéma d’authentification Basic en détail

L’un des piliers du schéma d’authentification Basic est que le client doit s’authentifier lui-même avec un identifiant
utilisateur et un mot de passe pour chaque espace de protection (« realm »).
La valeur du realm est une chaîne de forme libre qui ne peut être comparée que pour égalité avec d’autres realm sur ce
serveur. Le serveur ne traitera la demande que s’il peut valider l’ID utilisateur et le mot de passe pour l’espace de
protection s’appliquant à la ressource demandée.
Le schéma d’authentification de base utilise le cadre d’authentification comme suit.
Dans les défis:
• Le nom du schéma est « Basic » ;
• Le paramètre d’authentification «realm » est obligatoire ;
• Le paramètre d’authentification « charset »’ est facultatif ;
• Aucun autre paramètre d’authentification n’est défini. Les paramètres inconnus doivent être ignorés par les destinataires.
À la réception d’une demande d’URI dans l’espace de protection qui manque d’informations d’identification, le serveur
peut répondre avec un défi en utilisant le code de statut et le champ d’en-tête WWW-Authenticate comme ceci :

HTTP/1.1 401 Unauthorized

Date: Tue, .04 févr.2020 18:00:00 GMT
WWW-Authenticate: Basic realm="Formations”« Formations » est la chaîne affectée par le serveur pour identifier
l’espace de protection. Notez qu’un proxy peut répondre avec un défi similaire en utilisant le code de statut 407.
Pour recevoir l’autorisation, le client :
1. Obtient l’identifiant et le mot de passe de l’utilisateur ;
2. Concatène l’ID utilisateur et le mot de passe et les séparant par un deux-points (:) ;
3. Encode le résultat en une séquence d’octets ;
4. Obtient les informations d’identification Basic en encodant cette séquence d’octets à l’aide de Base64 en une séquence
de caractères US-ASCII ;
Notez que le schéma d’authentification Basic n’est pas une méthode sécurisée d’authentification des utilisateurs, ni ne
protège en aucune façon l’entité, qui est transmise en texte clair sur le réseau physique utilisé comme opérateur.
L’authentification Basic entraîne notamment la transmission en texte clair du mot de passe de l’utilisateur sur le réseau

24/30
physique. Cette la raison pour laquelle on l’utilise avec des améliorations comme HTTPS pour protéger les informations
sensibles ou précieuses.

16) Le protocole de sécurisation des échanges TLS (ancien SSL) et HTTPS

Le protocole TLS pour Transport Layer Security ou Sécurité de la Couche de Transport en français est un protocole de
sécurisation des échanges (au sens large) sur Internet. TLS crypte les données envoyées sur Internet pour garantir que les
données transmises ne soient pas interceptées par des entités malveillantes.
Le protocole TLS est le successeur de l’ancien protocole SSL (Secure Sockets Layer).

L’origine de TLS : le protocole SSL

Le protocole SSL a été originellement créé par la société Netscape. Son objectif principal était de permettre de
développement les achats sur le net en fournissant un gage de confiance aux utilisateurs. La session chiffrée est utilisée
pour empêcher un tiers d’intercepter des données sensibles transitant par le réseau. L’IETF (groupe chargé de la
standardisation de certains protocoles et notamment chargé de l’évolution de HTTP) a ensuite continué son
développement en le renommant TLS.

Qu’est-ce que TLS et à quoi sert ce protocole ?

TLS est un protocole cryptographique qui assure la sécurité de bout en bout des données envoyées entre les applications
sur Internet.
Le protocole TLS fonctionne au-dessus de la couche transport des modèles OSI et TCP/IP. Théoriquement, le cryptage des
données devrait être du ressort de la couche présentation du modèle OSI même si en pratique certaines applications
traitent TLS comme si il appartenait à la couche transport.
TLS est aujourd’hui très largement utilisé sur Internet notamment car il n’implique pas une modification des protocoles de
la couche application comme HTTP. Les protocoles comme HTTP vont simplement être implémentés au-dessus de TLS.
Par exemple, le protocole HTTPS est simplement la variante sécurisée du protocole HTTP.
TLS permet d’initialiser une connexion client-serveur privée (ou sécurisée) en utilisant une cryptographie symétrique
pour crypter les données transmises. Les clés de ce cryptage symétrique sont générées de manière unique pour chaque
connexion et sont basées sur un secret partagé qui a été négocié au début de la session. La négociation de ce secret
partagé est à la fois sécurisée (le secret négocié n’est pas accessible aux écoutes et ne peut être obtenu, même par un
attaquant qui se place au milieu de la connexion) et fiable (aucun attaquant ne peut modifier les communications
pendant la négociation sans être détectée).
De plus, la connexion est fiable car chaque message transmis comprend un contrôle d’intégrité du message à l’aide d’un
code d’authentification de message pour éviter toute perte ou altération non détectée des données pendant la
transmission.
Enfin, l’authentification du serveur (et de manière optionnelle du client) peut être réalisée à l’aide de clefs
cryptographiques publiques afin de s’assurer qu’un attaquant n’est pas en train d’usurper l’identité de l’une des deux
parties (client ou serveur).
Attention : il faut savoir que TLS prend en charge de nombreuses méthodes différentes pour l’échange de clés, le
chiffrement des données et l’authentification de l’intégrité des messages. Par conséquent, la configuration sécurisée de
TLS implique de nombreux paramètres configurables, et tous les choix ne fournissent pas toutes les propriétés liées à la
confidentialité.

Historique des versions SSL et TLS

Le protocole SSL a connu 3 versions (la première n’ayant jamais été mise en œuvre) : SSL 1.0 en 1994, SSL 2.0 en février
1995 et SSL 3.0 en novembre 1996.
Le protocole TLS a connu quatre versions : TLS v1.0 en 1999, TLS v1.1 en 2006, TLS v1.2 en 2008 et TLS v1.3 en 2018.

Fonctionnement des échanges avec TLS

Lorsqu’un utilisateur tente d’accéder à un site web qui utilise TLS, le client (navigateur de l’utilisateur) commence par
envoyer une demande de mise en place de connexion sécurisée par TLS au serveur.
Le serveur renvoie alors son certificat contenant sa clé publique, ses informations (nom de la société, adresse postale,
pays, e-mail de contact…) et une signature numérique qui permettent de l’authentifier.
Le certificat est un certificat numérique X.509 délivré par une autorité de certification (AC). Ce certificat peut être vu
comme une carte d’identité numérique. Il permet d’identifier une entité et peut également être utilisé pour chiffrer des
échanges.
Note : certaines applications utilisent également TLS pour authentifier le client, afin d’obtenir une authentification forte.
Une fois le certificat envoyé, le client vérifie si celui-ci est valide. Pour cela, il vérifie la signature numérique du certificat
du serveur en utilisant les clés publiques contenues dans les certificats des autorités de certifications intégrés par défaut
dans le navigateur.
Si la validité du certificat est confirmée, le client génère une clé de chiffrement symétrique ou « clef de session » ou «
secret » à partir de la clé publique contenue dans le certificat du serveur puis transmet cette clé de session au serveur.
La clé de chiffrement symétrique est générée à partir d’un chiffrement asymétrique.
Le serveur déchiffre la clé de session envoyée par le client grâce à sa clé privée puis le client et le serveur commencent
finalement à s’échanger des données en les chiffrant en utilisant la clef de session.
Dès la fin de la connexion, le serveur révoque la clé de session afin qu’elle ne puisse plus être utilisée.

17 ) La norme CORS : gestion du partage de ressources entre origines

25/30
multiples
Le mécanisme CORS pour « Content Origin Resource Sharing » ou « Partage de Ressources entre Origines Multiples »
permet la récupération de ressources choisies à partir d’origines différentes de la cible de la requête.
Lorsqu’on crée un site, il va être courant d’utiliser des ressources appartenant à d’autres sites dans nos propres pages.
Cela va être notamment le cas lors de l’utilisation (et donc du chargement) d’une police d’écriture Google, d’une feuille
de style externe comme un fichier CSS Bootstrap ou encore lors de l’inclusion d’un script JavaScript externe comme cela
va être le cas si vous implémentez des solutions comme Google Analytics ou Google Adsense.
La problématique ici est qu’il peut être très dangereux pour un visiteur de télécharger des ressources à partir d’une autre
source que celle qui est la cible de sa requête. En effet, sans restriction ni contrôle, un client pourrait aussi bien
télécharger aveuglément du code malveillant et être piraté.
Conscients de cela, la plupart des clients (navigateurs) suivent des politiques de sécurité pour atténuer ces risques et
notamment la politique dite de même origine ou « same-origin policy » en anglais.

La politique de même origine ou same-origin policy

La politique de même origine stipule qu’un document hébergé sur un serveur ne peut interagir qu’avec d’autres
documents possédant la même origine.
Une origine est composée d’un protocole, d’un hôte et d’un numéro de port. Deux documents ont la même origine si le
protocole, l’hôte et le numéro de port sont les mêmes.
• Le protocole : sur le web, les protocoles utilisés pour accéder à un document vont généralement être HTTP et HTTPS ;
• Le nom d’hôte : c’est ce qu’on appelle également le nom de domaine. Attention, un sous domaine sera considéré
comme un nom d’hôte différent ;
• Le numéro de port : spécifie le port utilisé pour se connecter. HTTP utilise le port 80 par défaut, HTTPS utilise le port 443
par défaut. Si il est précisé, il doit correspondre pour satisfaire à la condition de même origine.
Imaginons un premier document situé à l’adresse http://www.pierre-giraud.com/home.html qui cherche à récupérer une
ressource située à une autre adresse. Regardons ce que ce document est autorisé à récupérer en respectant la politique
de même origine :
URL de la ressource Résultat Explication
http://www.pierre-giraud.com/cours.html Succès
https://www.pierre-giraud.com/cours.html Echec Protocoles (et numéro de port) différents
http://www.cours.pierre-giraud.com/index.html Echec Hôtes différents
http://www.wikipedia.org/index.html Echec Hôtes différents
http://www.pierre-giraud.com:88/cours.html Echec Ports différents
Comme vous pouvez le voir, la politique de même origine est extrêmement restrictive puisqu’elle interdit tout
simplement de faire appel à des ressources d’origine différente. Pour autant, ne pas implémenter de politique de sécurité
rendrait le Web bien trop risqué. C’est la raison pour laquelle la norme CORS a été créée.

Qu’est-ce que CORS ?

Le partage de ressources entre origines multiples intervient lorsqu’un document inclut une demande de ressources
située à une autre origine.
Si toutes les demandes de ressources à partir d’une autre origine étaient interdites, le Web serait très limité et beaucoup
moins performant.
Le mécanisme CORS permet aux serveurs de spécifier qui (c’est-à-dire quelles origines) peut accéder aux ressources sur
le serveur ainsi que la façon dont on va pouvoir y accéder.
Concrètement, la plupart des serveurs vont autoriser les requêtes dites « safe », c’est-à-dire les requêtes qui ne
modifient pas les ressources sur le serveur comme GET et vont donc permettre aux ressources d’origine externe d’accéder
à leurs ressources en lecture simple.
En revanche, d’autres méthodes dits « unsafe » comme PUT ou DELETE peuvent être refusées pour empêcher tout
comportement malveillant : il est légitime qu’un serveur ne souhaite pas que d’autres serveurs modifient ou suppriment
ses ressources.
Cependant, les serveurs ne bloquent pas systématiquement de telles requêtes. Pour être tout à fait précis, la norme
CORS impose aux navigateurs d’effectuer un contrôle en amont des requêtes (« preflight request ») pour les méthodes
de requêtes qui peuvent modifier les données avant d’envoyer la requête réelle dans le cas où le serveur l’approuverait.
Concrètement, les requêtes en amont consistent en l’envoi préalable d’une requête HTTP avec la méthode OPTIONS à la
ressource cross-origin pour déterminer si la requête réelle peut être envoyée en toute sécurité.

Comment fonctionne CORS en pratique ?

La norme CORS gère les demandes d’origine croisée en ajoutant de nouveaux en-têtes HTTP à la liste standard des en-
têtes. Ces en-têtes sont les suivants :
• Access-Control-Allow-Origin : indique si la réponse peut être partagée, en renvoyant la valeur littérale de l’en-tête
de requête Origin (qui peut être « null ») ou « * » dans une réponse. ;
• Access-Control-Allow-Credentials : indique si la réponse peut être partagée lorsque le mode d’informations
d’identification de la requête est « include » ;
• Access-Control-Allow-Headers: indique les en-têtes pris en charge par l’URL de la réponse aux fins du protocole
CORS ;
• Access-Control-Allow-Methods : indique les méthodes prises en charge par l’URL de la réponse aux fins du protocole
CORS : indique quels en-têtes peuvent être exposés dans la réponse en répertoriant leurs noms ;

26/30
• Access-Control-Expose-Headers : indique quels en-têtes peuvent être exposés dans le cadre de la réponse en
répertoriant leurs noms ;
• Access-Control-Max-Age: indique le nombre de secondes (5 par défaut) pendant lesquelles les informations fournies
par les en-têtes Access-Control-Allow-Methods et Access-Control-Allow-Headers peuvent être mises en cache ;
• Access-Control-Request-Headers : indique les en-têtes qu’une future requête CORS à la même ressource pourrait
utiliser ;
• Access-Control-Request-Method : indique la méthode qu’une future requête CORS à la même ressource pourrait
utiliser ;
• Origin : indique d’où provient une récupération (un fetch).

En résumé : quel intérêt de mettre en place CORS

Aujourd’hui, de plus en plus de sites font appel à des ressources externes. Pour se protéger contre le téléchargement de
code potentiellement malveillant, les navigateurs et les serveurs mettent en place des politique de sécurité dont la
politique de même origine qui est très restrictive.
Le mécanisme CORS est un mécanisme qui utilise des en-têtes HTTP supplémentaires pour indiquer aux navigateurs
quels types de requêtes doivent être acceptées et quelles autres doivent être rejetées et à quelles conditions.
Au final, CORS définit une manière dont un navigateur et un serveur peuvent interagir pour déterminer si une requête
pour une ressource située à une autre origine doit être autorisée ou pas.

Les politiques de sécurité liée au contenu et de contrôle des

18 )

fonctionnalités
Au cours du temps, les possibilités du web ont été multipliés et les sites web ont progressivement intégrés de nouveaux
contenus et fait de plus en plus appel à des contenus externes (en intégrant des polices Google, des frameworks, des
scripts externes comme Google Analytics, etc.) tout en développant leur éventail de fonctionnalités.
Face à cela, des politiques de sécurité ont dû être mises en place pour éviter que les navigateurs et les serveurs ne
soient sujets à des attaques et corruptions en suivant aveuglément n’importe quelle requête.
Il existe deux grands types de politique de sécurité aujourd’hui : la politique de sécurité liée aux contenus ou CSP pour
Content Security Policy et la politique liée aux fonctionnalités au Feature Policy.

La politique de sécurité liée aux contenus ou CSP

L’objectif principal de la politique de sécurité liée aux contenus est de permettre de restreindre l’origine de certains
contenus jugés à risque (tel qu’un script Javascript, une feuille de style etc.) intégrés dans un document à certains sites
autorisés.
L’application de cette politique permet de se protéger contre l’injection de code malveillant et donc contre les attaques
de type XSS (cross-site scripting) et contre les attaques dont le but est de détourner un utilisateur vers un autre site suite
à un clic.
L’application de la politique de sécurité liée aux contenus se fait via l’en-tête HTTP Content-Security-Policy.
Concrètement, on va envoyer la liste des sites autorisés (sous forme de liste de noms de domaine) en valeur de l’en-tête.

La politique liée aux fonctionnalités

La politique liée aux fonctionnalités fournit un mécanisme pour déclarer explicitement quelles fonctionnalités peuvent
être utilisées et quelles fonctionnalités ne peuvent pas être utilisées sur l’ensemble d’un site Web.
Concrètement, la politique liée aux fonctionnalités permet aux développeurs Web d’activer, de désactiver et de modifier
de manière sélective le comportement de certaines fonctionnalités et API dans le navigateur.
On va pouvoir attribuer une stratégie de contrôle à chacune des fonctionnalités suivantes :
• GeoLocation
• midi
• Notifications
• Push
• sync-xhr
• Microphone
• Camera
• Magnetometer
• Gyroscope
• Speaker
• Vibrate
• Fullscreen
• Payment
On va pouvoir spécifier une stratégie liée aux fonctionnalités de deux façons différentes :
• En utilisant l’en-tête HTTP Feature-Policy ;
• En utilisant un attribut HTML allow dans des iframes.
L’attribut allow ne contrôle que les fonctionnalités d’un iframe tandis que l’en-tête Feature-Policy contrôle les
fonctionnalités de tout contenu incorporé dans la page.
L’en-tête Feature-Policy supporte trois valeurs qui permettent de définir dans quel contexte une fonctionnalité peut être
utilisée :
• * : La page dans son ensemble (avec tous les iframes imbriqués) peuvent utiliser la fonctionnalité liée ;
• Self : La page ainsi que tous les contextes de navigation imbriqués peuvent utiliser la fonctionnalité liée à condition
qu’ils soient sur la même origine ;
• None : La fonctionnalité liée ne peut pas être utilisée sur la page.

27/30
ANNEXE 1 : Liste des en-têtes HTTP (HTTP headers)
19) Liste des en-têtes HTTP ou HTTP headers

Les en-têtes HTTP sont très nombreux et permettent d’ajouter des informations de contexte ou de préciser une requête
ou une réponse HTTP.
La liste des en-têtes HTTP (HTTP headers) est la suivante :
• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Accept-Patch
• Accept-Ranges
• Access-Control-Allow-Credentials
• Access-Control-Allow-Headers
• Access-Control-Allow-Methods
• Access-Control-Allow-Origin
• Access-Control-Expose-Headers
• Access-Control-Max-Age
• Access-Control-Request-Headers
• Access-Control-Request-Method
• Age
• Allow
• Alt-Svc
• Authorization
• Cache-Control
• Clear-Site-Data
• Connection
• Content-Disposition
• Content-Encoding
• Content-Language
• Content-Length
• Content-Location
• Content-Range
• Content-Security-Policy
• Content-Security-Policy-Report-Only
• Content-Type
• Cookie
• Cross-Origin-Resource-Policy
• DNT
• Date
• ETag
• Early-Data
• Expect
• Expect-CT
• Expires
• Feature-Policy
• Forwarded
• From
• Host
• If-Match
• If-Modified-Since
• If-None-Match
• If-Range
• If-Unmodified-Since
• Index
• Keep-Alive
• Last-Modified
• Link
• Location
• Origin
• Proxy-Authenticate
• Proxy-Authorization
• Public-Key-Pins
• Public-Key-Pins-Report-Only
• Range
• Referer
• Referrer-Policy
• Retry-After
• Save-Data

28/30
• Sec-WebSocket-Accept
• Server
• Server-Timing
• Set-Cookie
• SourceMap
• Strict-Transport-Security
• TE
• Timing-Allow-Origin
• Tk
• Trailer
• Transfer-Encoding
• Upgrade-Insecure-Requests
• User-Agent
• Vary
• Via
• WWW-Authenticate
• Warning
• X-Content-Type-Options
• X-DNS-Prefetch-Control
• X-Frame-Options
• X-XSS-Protection

ANNEXE 2 : Liste des codes de statut ou codes d’état HTTP

20)
Les codes de statut HTTP ou « codes d’état » HTTP sont envoyés par le serveur avec sa réponse et permettent de fournir
des informations quant à la complétion ou la non-complétion d’une requête. Ceux-ci sont très utiles pour le débogage
dans le cas où la requête n’aurait pas abouti ou pour économiser des ressources.
Les codes de statut HTTP se décomposent en 5 grandes familles :
• Un code 1xx indique une réponse provisoire (non implémenté avec HTTP/1.0) ;
• Un code 2xx (200, 201, 202, 204) indique que la requête a été traitée avec succès ;
• Un code 3xx(300, 301, 302, 304) indique que la requête doit être redirigée ;
• Un code 4xx (400, 401, 403, 404) indique une erreur côté client ;
• Un code 5xx (500, 501, 502, 503) indique une erreur côté serveur.
Pour information, vous pourrez trouver la liste complète des codes de statut et le message associé à chacun d’entre eux
ci-dessous :
• 100 Continue
• 101 Switching Protocols
• 103 Early Hints
• 200 OK
• 201 Created
• 202 Accepted
• 203 Non-Authoritative Information
• 204 No Content
• 205 Reset Content
• 206 Partial Content
• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect
• 400 Bad Request
• 401 Unauthorized
• 402 Payment Required
• 403 Forbidden
• 404 Not Found
• 405 Method Not Allowed
• 406 Not Acceptable
• 407 Proxy Authentication Required
• 408 Request Timeout
• 409 Conflict
• 410 Gone
• 411 Length Required
• 412 Precondition Failed
• 413 Payload Too Large
• 414 URI Too Long
• 415 Unsupported Media Type
• 416 Range Not Satisfiable
• 417 Expectation Failed
• 418 I'm a teapot
• 422 Unprocessable Entity

29/30
• 425 Too Early
• 426 Upgrade Required
• 428 Precondition Required
• 429 Too Many Requests
• 431 Request Header Fields Too Large
• 451 Unavailable For Legal Reasons
• 500 Internal Server Error
• 501 Not Implemented
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout
• 505 HTTP Version Not Supported
• 506 Variant Also Negotiates
• 507 Insufficient Storage
• 508 Loop Detected
• 510 Not Extended
• 511 Network Authentication Required

30/30