Le protocole HTTP
- Présentation
- Fonctionnement
- Problèmes liés à ce protocole
- La version 1.1 fait toute la différence
- Références
1 - Présentation
HTTP - HyperText Transfert Protocol - fondé par Tim Berners Lee, développé
et utilisé par le WWW à partir de 1990.
Protocole adapté au transfert d'information multimédia.
Léger et rapide, à coût d'exploitation très bas.
Introduit la notion d'hypertexte, c'est à dire que l'information de
navigation est prise en compte dans le document, mais ne prend pas en
charge le procédé complet de navigation.
Le protocole HTTP sert à la communication entre le client et le serveur.
Il s'agit en fait d'un dérivé du protocole FTP. Lors d'une communication,
le logiciel client se connecte en TCP sur le serveur et télécharge en
FTP le document désigné. Il coupe aussitôt la communication avec le
serveur. S'il y a dans le document HTML plusieurs composants (comme
des images, la plupart du temps), ce processus se répète autant de fois
qu'il y a d'éléments constituant la page.
L'avantage de ce processus est de limiter au maximum le temps d'occupation
du serveur, de façon qu'il n'y ait pas d'engorgement de ce dernier.
2 - Fonctionnement
Connexion
La connexion se fait, à travers une connexion TCP-IP, en mentionnant le nom du domaine ou le numéro IP, ainsi le numéro de port donné dans l'adresse. Dans le cas où ce dernier n'est pas spécifié, le nombre 80 est mis par défaut.
Si HTTP fonctionne le plus souvent sous TCP, il peut tout aussi bien tourner sous n'importe quel service orienté connexion. Les requêtes sont mises en forme par le navigateur, puis transmises au protocole HTTP.
Requêtes
Le client envoie une requête de document qui consiste en une ligne écrite en caractères ASCII se terminant par "CR LF" (carriage return, line feed).
Cette requête dans le cas le plus simple est du type "GET", un espace et l'adresse du document, en oubliant de mentionner l'hôte et le port.
Sinon la syntaxe générale d'une requête est du type :
Ligne_requete (En-tête_requête
| En-tête_entité ) ;
CRLF
[ Corps-entité ]
Où :
Ligne_requete = Méthode
SP URL SP Version-HTTP CRLF
|
Authorization |
Document protégé |
|---|---|
|
| From |
Identifiant physique (adresse mail) |
|
| If-modified-since |
Date dernière modification à ne pas dépasser |
|
| Referer |
Page d'origine |
|
| User-agent |
Interface utilisée |
|
Allow |
Méthode supportée |
|---|---|
|
| Content-Encoding |
Nature de l'encodage |
|
| Content-Length |
Longueur |
|
| Content-Type |
Type du document |
|
| Expires |
Date de validité |
|
| Last-Modified |
Notion de cache |
|
| champ_en-tête |
|
Réponse
Le format de réponse rassemble sensiblement les mêmes champs. Suivant le client ou serveur certaines variables sont utilisées. Le message débute par la version du protocole utilisé par le serveur, ainsi qu'un code résultat et éventuellement un message.
Ce premier flux d'informations est constitué de caractères ASCII. Ceci, suivi par une série d'entêtes dont les plus importants sont "type du contenu", qui décrit le type de l'objet qui est donné, et "longueur du contenu", qui indique la longueur du document. Les entêtes se terminent par des lignes vides.
Syntaxe :
Ligne_etat (En_tete_reponse
| En_tete_entite)
CRLF
Corps_entite
Où :
Ligne_etat = Version SP Code_Etat SP Raison CRLF
En_tete_reponse = Location | Server | WWW-Authentificate
En_tete_entite défini lors de la requête
Code_Etat :Le premier chiffre du code d'état indique la classe générale de la réponse. Les deux derniers n'ont pas de rôle de classification particulier. Le premier chiffre peut prendre 5 valeurs :
| Code | Classe | Usage |
|
1xx |
Information |
Non utilisé, pour usage futur |
|
2xx |
Succès |
L'action a été correctement reçue, interprétée, et exécutée |
|
3xx |
Redirection |
Une décision supplémentaire doit être prise pour terminer la requête |
|
4xx |
Erreur Client |
La requête présente une erreur de forme et ne peut être satisfaite |
|
5xx |
Erreur Serveur |
La requête est valide, mais le serveur ne peut la satisfaire |
Le serveur peut maintenant envoyer n'importes quelles données. Après l'envoi du document, le serveur coupe la connexion.
Déconnexion
La connexion TCP-IP est coupée par le serveur quand tout le document a été transmis.
Le client peut avorter le transfert en coupant lui-même la connexion avant la fin du transfert, dans ce cas le serveur n'enregistrera aucune erreur.
Le serveur n'a besoin de stocker aucune information concernant la requête. Cependant le serveur enregistre les entêtes HTTP pour des statistiques éventuelles, ou le déboggage. Attention ces informations tombent sous la loi "informatique et liberté"
Voici une ligne type de fichier LOG :
# Exemple 1 (IIS) :
192.168.100.70, -, 24/01/98, 01:34:46, W3SVC, ALIAN, 192.168.100.70,
89789, 230, 5630, 200, 0, GET, /alian/bienvenue.htm, -,
## Exemple 2 (Netscape Entreprise):
139.160.213.93 - - [18/Mar/1998:08:48:43 +0100] "GET /directagence/images/carre_bleu.gif HTTP/1.0" 200 307
3 - Problèmes liés à ce protocole
Il semble que HTTP passe plus de temps à attendre qu'à transmettre. Avant de voir le pourquoi de cette attente, parlons de quelques unités de mesure :
Le Round Trip Time (RTT) est le temps que prend l'envoi d'un
paquet d'un bout de la connexion à l'autre, plus le retour. Le RTT peut
prendre 70 millisecondes ou plus.
Une autre importante unité de mesure est la largeur de bande
de la connexion. Elle mesure le débit de bits par seconde. Il est possible
d'établir une borne inférieure pour la largeur de bande en observant
le temps que prend l'envoi d'un paquet.
Parlons du phénomène Slow Start. C'est un système qui ouvre une seconde fenêtre appelée "Congestion Window", pour les "nack". A la connexion, chaque expéditeur n'a le droit d'envoyer qu'un seul "nack" à la fois. A chaque fois que la réception d'un segment est confirmée par un "ack", la "Congestion Window" est ouverte, sinon, en cas de perte, elle se ferme.
De quelle façon le protocole HTTP est ralenti par le Slow Start
HTTP est touché par slow start du côté du client et celui du serveur. Parce que les entêtes de HTTP sont plus grandes que le MSS (maximun segment size), le client TCP a besoin de 2 segments. Vu que la "Congestion Window" est initialisée à 1, on a besoin d'attendre le premier segment pour envoyer le "ack" avant de pouvoir le second. Ceci ajoute an RTT supplémentaire au temps minimum du transfert. De plus, à partir du moment où la plupart des documents dépassent 1K, le slow Start du serveur va typiquement ajouter au moins un RTT au total de la transaction.
Le temps de latence et la largeur de bande sont les clés de la performance de ce protocole. Le temps de latence, mesuré par le RTT, est une mesure de coût fixe de la transaction et ne change pas en fonction de la taille du document. La largeur de bande, comme dit précédemment mesure le temps qu'il faut pour envoyer les données.
De plus avec la version HTTP/1.0, pour une page contenant 42 images, il va y avoir 42 connections TCP... La version 1.1 introduit la notion de "connections permanentes".
4 - La version 1.1 fait toute la différence
Les deux grosses différences de cette version sont la sécurité et la gestion plus adaptée des caches.
Sécurité
Dans un premier temps, la sécurité était mise en place au niveau du serveur. Puis les offres sont arrivées avec la demande :
En effet le protocole Secure-HTTP (S-HTTP) assure la sûreté de la transmission. Un message S-HTTP est composé d'une requête ou d'une ligne de statut (comme dans HTTP) suivi d'une d'en-tête de type RFC-822 ainsi que d'un résumé du contenu. Une fois le contenu décodé, il peut s'agir d'un autre message S-HTTP, d'un message HTTP ou de simples données. Implémenté dans HTTP/1.0. Développé par des professionels du commerce électronique .
Certains serveurs implémentent le protocole SSL par dessus le protocole HTTP. Solution Netscape.
Deux formes de protection sont mises en place dans HTTP/1.1:
- Basic Access Authentification
- Digest Acces Authentificate
Gestion des caches
Nouvelles fonctionnalités
- Supporte la compression des données
- Nouveaux formats : PNG, CCS
- PNG : format d'images où la taille est /10 par rapport a une image GIF
- CCS : Cascading Style Sheep : charte graphique
- Supporte le "Multi-home Web"
5 - Références
- RFC 1945 : Mai 96 - HTTP/1.0 http://www.eisti.fr/eistiweb/docs/normes/rfc1945
- RFC 2068 : Janvier 97 - HTTP/1.1 http://www.w3.org/Protocols/rfc2068/rfc2068.txt
