L’évolution DU PROTOCOLE HyperText Transfer Protocol

Présentation au sujet: "L’évolution DU PROTOCOLE HyperText Transfer Protocol"— Transcription de la présentation:

1 L’évolution DU PROTOCOLE HyperText Transfer Protocol
VEILLE TECHNOLOGIQUE 2015 L’évolution DU PROTOCOLE HyperText Transfer Protocol Professeurs: Didier Donsez Georges-Pierre Bonneau ÉTUDIANT : Thibault SAUSSAC

2 Sommaire Rappels sur HTTP Les évolutions de HTTP Conclusion HTTP 0.9
Thibault SAUSSAC Veille Technologique 2015 Sommaire Rappels sur HTTP Les évolutions de HTTP HTTP 0.9 HTTP 1.0 HTTP 1.1 HTTP SPDY HTTP 2.0 Conclusion

3 HTTP, Quèsaco? Signification: HyperText Transfer Protocol
Thibault SAUSSAC Veille Technologique 2015 HTTP, Quèsaco? Signification: HyperText Transfer Protocol « Protocole de transfert hypertexte » Création : 1990 par Sir Berners-Lee Concurrent : Gopher Port : 80 (ou 443 avec https ) Couche : Application Type : Protocole sans État Architecture : Client – Serveur Identification : Uniform Ressource Identifier Protocole sans états : qui ne retient pas les requetes envoyé. pos

4 HTTP, Quèsaco? Exemple de requête / réponse HTTP : Thibault SAUSSAC
Veille Technologique 2015 HTTP, Quèsaco? Exemple de requête / réponse HTTP :

5 L’évolution de HTTP… 25 ans d’histoire HTTP 0.9 HTTPS HTTP 2.0
Thibault SAUSSAC Veille Technologique 2015 HTTP 0.9 HTTPS HTTP 1.1 HTTP 2.0 1995 2000 2010 L’évolution de HTTP… HTTP 1.0 SPDY 1990 2005 2015 25 ans d’histoire

6 HTTP 0.9 (port 2784) Non Commercial BUT : Échanger des pages web HTML
Thibault SAUSSAC Veille Technologique 2015 HTTP 0.9 (port 2784) Non Commercial BUT : Échanger des pages web HTML Principe Connexion du client. Envoi d’une requête (de méthode GET). Réponse du serveur. Le serveur ferme la connexion (Fin de la réponse) Méthode dans les requêtes : GET Type de réponse : Un fichier HTML NB Le serveur reconnaît de nos jours qu’il a à faire à une requête HTTP 0.9 au fait que la version n’est pas précisée suite à l’URI (contrairement à ce qui se passe pour les versions ultérieures).

7 HTTP 1.0 (RFC 1945) Premier standard commercialisé
Thibault SAUSSAC Veille Technologique 2015 HTTP 1.0 (RFC 1945) Premier standard commercialisé Une connexion / requête Plusieurs connections / Client 3 types de méthode : GET HEAD POST Ajout d’une en-tête de type MIME  METADONNEES (HOST, REFERER, USER-AGENT) NB : Première notion de cache…(Pragma: no-cache) 16 type d’entête General-Header (Section 4.3), Request-Header (Authorization ; Section 10.2 | From ; Section 10.8 | If-Modified-Since ; Section 10.9 | Referer ; Section 10.13 | User-Agent ), Response-Header (Section 6.2), and Entity-Header Host permet de préciser le site web concerné par la requête, ce qui est nécessaire pour un serveur hébergeant plusieurs sites à la même adresse IP (name based virtual host, hôte virtuel basé sur le nom). C’est la seule en-tête réellement importante. – Référer spécifie l’URI du document qui a donné un lien sur la ressource demandée. Cet en-tête permet aux webmaîtres d’observer d’où viennent les visiteurs. – User-Agent spécifie le logiciel utilisé pour se connecter. Il s’agit généralement d’un navigateur Web ou d’un robot d’indexation.

8 HTTP 1.1 (RFC 2616) Meilleure gestion du cache (Cache-Control)
Thibault SAUSSAC Veille Technologique 2015 HTTP 1.1 (RFC 2616) Meilleure gestion du cache (Cache-Control) Apparition des ETags L’entête HOST  OBLIGATOIRE Connexions persistantes ( KEEP-ALIVE ), PIPELINNING Réduit la charge du réseau Accélère le chargement des pages Un ETag est un identifiant unique opaque assigné par le serveur web à chaque version d'une ressource accessible via une URL. Si la ressource accessible via cette URL change, un nouvel ETag différent du précédent sera assigné. Utilisés ainsi, les ETags sont similaires à des empreintes digitales, et peuvent être rapidement comparés pour vérifier si deux versions sont identiques et ainsi savoir si une demande peut être honorée par un cache local ou pas. Etag : chaine de caractère opaque qui sert à la validation des entrées cache Connexions persistantes : la connexion n’est pas immédiatement fermée après une requête, mais reste disponible pour une nouvelle requête.

9 HTTP 1.1 (RFC 2616) Négociation de contenu Transfert par morceaux
Thibault SAUSSAC Veille Technologique 2015 HTTP 1.1 (RFC 2616) Négociation de contenu Entête de type « Accept-Language: fr » Transfert par morceaux Transfert encoding : chuncked Des nouvelles méthodes (OPTION, CONNECT, TRACE, PUT, DELETE) Les User-Agent peuvent ainsi choisir la version la mieux adaptée à leurs capacités. Une des utilisations classiques de ce mécanisme est de proposer une image aussi bien au format GIF que PNG. Ainsi un User-Agent qui ne peut pas afficher le format PNG peut toujours utiliser la version en GIF. Le support des connexions persistantes doit également fonctionner dans les cas où la taille de la ressource n’est pas connue d’avance (comme dans le cas d’une ressource générée dynamiquement par le serveur ou un flux externe au serveur). Pour cela, l’encodage de transfert nommé chunked permet de transmettre la ressource par morceaux consécutifs en précédant chacun par une ligne de texte donnant la taille de celui-ci en hexadécimal. OPTIONS permet d’obtenir les options de communication d’une ressource ou du serveur en général. – CONNECT permet d’utiliser un proxy comme tunnel de communication. – TRACE demande au serveur de retourner ce qu’il a reçu, dans le but de tester et effectuer un diagnostic sur la connexion. – PUT permet de remplacer ou d’ajouter une ressource sur le serveur. L’URI fourni est celui de la ressource en question. A cause de la mauvaise implémentation des méthodes HTTP par les navigateurs, la méthode POST est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée à la fois pour la création et la mise à jour de ressources. – DELETE permet de supprimer une ressource du serveur. Ces deux dernières méthodes nécessitent généralement un accès privilégié.

10 SPDY Créé par Google Infrastructure reste inchangée L’idée :
Thibault SAUSSAC Veille Technologique 2015 SPDY Créé par Google Infrastructure reste inchangée L’idée : Connections multiples au sein d'une même session TCP. Compression en-têtes (dynamic stream-based), élimination des jugés inutiles. SSL au cœur Serveur peut initier une connexion. Client priorise les requêtes

11 SPDY, quelques résultats
Thibault SAUSSAC Veille Technologique 2015 SPDY, quelques résultats % de performance

12 HTTP 2.0 (RFC 7540) 1,4% des sites Adaptation de SPDY
Thibault SAUSSAC Veille Technologique 2015 HTTP 2.0 (RFC 7540) 1,4% des sites Adaptation de SPDY Effort sur la compression Huffman Nouvelle extension ALPN Application du multiplexage à toutes les communications avec différents hôtes en même temps. SSL n’est plus au cœur. HUFFMAN : This helps to reduce the potential for attacks on the protocol. ALPN : une option du protocole de sécurité TLS pour permettre à un client TLS d'indiquer au serveur TLS quelle application il veut utiliser TLS/SSL non nécessaire. Par contre, les sites Web qui utilisent le cryptage verront un gain de performances notable sur les sites Web cryptées d’aujourd’hui.

13 Conclusion Simple et versatile Un développement INCROYABLE
Thibault SAUSSAC Veille Technologique 2015 Conclusion Simple et versatile Un développement INCROYABLE A été construit dans le but de ne pas changer HTTP2 fut un changement extraordinaire De nouvelles versions pourront apparaître plus facilement Alors … vers un HTTP 3.0?

14 Sources https://bulledev.com/resume-performance-web-mars-avril-2015/
Thibault SAUSSAC Veille Technologique 2015 Sources Cours Interconnexions des réseaux RICM4

15 Avez vous des requêtes (HTTP) ?
Thibault SAUSSAC Veille Technologique 2015 Avez vous des requêtes (HTTP) ?