2 HTTP

Université Université
De Boumerdes De Limoges
Couche Application
Réalisé par : Mr RIAHLA

Doctorant a l’université de limoge (France)
2009/2010
Introduction
Couche Application
Elle se situe au sommet des couches de

protocoles TCP/IP. Celle-ci contient les applications
réseaux permettant de communiquer grâce aux
couches inférieures.
Les applications de cette couche communiquent

donc grâce à un des deux protocoles de la couche
transport, TCP ou UDP, elles sont de différents types,
mais la plupart sont des services réseau, c'est-à-dire
des applications fournies à l'utilisateur pour assurer
l'interface avec le système d'exploitation.
Réalisé par : Mr RIAHLA 2009/2010 2

Introduction
Couche Application
On peut les classer selon les services qu'ils rendent :
Les services de gestion (transfert) de fichier et

d'impression,
Les services de connexion à distance,
Les utilitaires Internet divers.
…etc
Les différents protocole existants dans cette

couches : TELNET, SSH, FTP, DNS, SNMP, HTTP, SMTP,
POP…..

Université Université
De Boumerdes De Limoges
Le protocole HTTP (Port 80)

Le protocole HTTP
HTTP (Hyper Text Transfer Protocol) est le

protocole de communication du web permettant
d'échanger des documents hypertextes contenant des
données sous la forme de texte, d'images fixes ou
animées et du son.
Tout client web communique avec le port 80

d'un serveur HTTP par l'intermédiaire d'une, ou
plusieurs, connexions TCP simultanées, chacune des
connexions TCP ouvertes servant à récupérer l'un des
composants de la page web.

Le protocole HTTP
En prenant un exemple commun, de

communication entre un navigateur web (le
client) et un serveur web, la communication se
déroule de la manière décrite sur le schéma
suivant:

Le protocole HTTP
 L'ordinateur de l'internaute utilise le navigateur pour

envoyer une requête à un serveur web.
 Cette requête demande un document (exemple:

page HTML, image, fichier CSS ...).
 Le serveur cherche les informations, puis il est peut-

être amené à interpréter les résultats
(exemple: PHP, Java ...), pour finalement envoyer la
réponse.
 Cette réponse contient les entêtes du protocole HTTP

et normalement le contenu demandé.
Evitons déjà une confusion
HTTP (Hyper Text Transfert Protocol) est un

protocole destiné à transférer du texte depuis un
serveur vers un client.
HTML (Hyper Text Markup Language) est un

langage de description de document. Outre les
possibilités d'enrichissement du texte comme les
attributs gras, italique, souligné, les différents
niveaux de titre, il offre la bien connue possibilité de
définir des « hyperliens » entre documents ou parties
de documents.

Contenu statique vs Contenu dynamique
Page statique
Le contenu d'une page HTML est écrit « en dur » de façon statique,
avec un outil spécialisé ou non,
Page dynamique
Le html est généré à la volée par le serveur, de façon dynamique, à
partir d'informations stockées dans des bases de données où dans
des fichiers texte.



Le serveur Apache
 Serveur HTTP/1.1
 Versions pour Windows, OS/2, Linux…
 Utilise du pré-fork
 Configuration du serveur en plaçant des directives dans un fichier
texte.
 httpd.conf (lu au démarrage)
 .htaccess (accès au répertoire)
 Syntaxe: Directive Valeur

 Les directives s’appliquent à l’ensemble du serveur
 Leur portée peut-être limitée avec des sections
 <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>,
<LocationMatch>, <VirtualHost>
Apache – Restriction d’accés
 Directives Allow,Deny
 from all
 from www.xxx.yyy.zzz
 from unice.fr
 Peut spécifier un ordre pour les directives d’accés

 order deny, allow : les deny sont évalués avant les allow
 order allow, deny : les allow sont évalués avant les deny
 Exemple
order deny,allow
deny from all
allow from .ncsa.uiuc.edu
Apache – Virtual Host
 Permet d’avoir plusieurs serveurs sur une même machine

 Virtual Host basé sur IP
 Utilise l’IP de la connexion pour déterminer le bon serveur
 Virtual Host basé sur le nom
 Utilise le nom de domaine fourni par le client pour déterminer
le serveur
 Exemple
NameVirtualHost *
<VirtualHost *>
ServerName www.domain.tld
DocumentRoot /www/domain
</VirtualHost>
<VirtualHost *>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>
 http://httpd.apache.org/docs/vhosts/name-based.html
La mise en place d’un serveur HTTP
Windows
 Wamp, easyphp,,,etc
Linux
 Httpd, apache2

Le codage MIME
Format de messages de l'internet permettant de

découper un message en plusieurs parties et d'y
inclure des données non-ASCII, à savoir du son, des
images..)
HTTP, un peu comme SMTP, ne sait pas nativement

transporter autre chose que du texte.
Il est bien connu de tous que le web propose aussi

autre chose, comme des images (jpg, gif, png…), des
animations et des documents aux formats plus ou
moins particuliers (pdf, mpg, doc, xls, odt, ods…).

Le codage MIME
Client et serveur doivent se mettre d'accord sur un

moyen de coder ces information (serveur) et de les
décoder (client) pour les afficher quand c'est
possible, ou en proposer le téléchargement.
Dans tous les cas, ces données non textuelles

doivent être codées et décodées de façon
cohérente.

URL (Unified Ressource Locator)
http://www.debian.org/doc/manuals/reference/ch-
preface.fr.html:
http:
Le protocole employé ;
//www.debian.org
Le serveur web contenant l'information recherchée ;
/doc/manuals/reference/ch-preface.fr.html:
Le chemin complet de la page visitée dans l'arborescence du
serveur concerné.
http://www.debian.org est équivalent

à http://www.debian.org/index.html.

Interroger un serveur HTTP avec telnet
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv= "Content-
Type" content=
"text/html; charset=iso-8859-1">
</head>
<body bgcolor= »#FFFFFF » text=

»#000000 »>
<p>Hello world.</p>
<p><img src="images/tux.gif"
width= "97" height= "115"></p>
</body>
</html>

Interroger un serveur HTTP avec telnet
telnet 127,0,0,1 80
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Wed, 08 May 2002 14:26:57 GMT
Server: Apache-
AdvancedExtranetServer/1.3.23
(Mandrake Linux/4mdk) auth_ldap/1.6.0
mod_ssl/2.8.7 OpenSSL/0.9.6c PHP/4.1.2
Last-Modified: Sun, 14 Apr 2002
09:29:32 GMT
ETag: "57d44-116-3cb94bfc"
Accept-Ranges: bytes
Content-Length: 278
Connection: close
Content-Type: text/html
Comment travaille le navigateur ?
La même chose que nous :
• Il appelle la page d'accueil GET / HTTP/1.0

(éventuellement HTTP/1.1, mais alors, suivant la
définition de cette version HTTP, il devra au moins
envoyer aussi le nom d'hôte du serveur interrogé).
• Une fois la page reçue, il va chercher dedans tous les
URI, ici celui de l'image, et va les appeler avec un GET.
• Dans le cas de l'image, il devra la recomposer, ce qui
lui est possible parce qu'il connaît le format
d'encodage gif.
• Il affiche alors la page, dans son intégralité.

Le protocole HTTP (Requête)
GET /~ferment/http/prog/page_test1.html HTTP/1.1

Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux;
Fr)
Referer: http://www.u-picardie.fr/~ferment/http/prog/
Pragma: no-cache
Cache-control: no-cache
Accept: text/html, image/jpeg, image/png, text/*, image/*,
*/*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8; q=0.5, *; q=0.5
Accept-Language: fr, en
Host: www.u-picardie.fr
Eventuel corps ……………..
Le protocole HTTP (Réponse)
HTTP/1.1 200 OK
Date: Tue, 22 Jun 2004 13:18:15 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2
mod_ssl/2.8.9 OpenSSL/0.9.6g DAV/1.0.3
Last-Modified: Tue, 22 Jun 2004 13:15:43 GMT
ETag: "63f3d-8e-40d830ff
Accept-Ranges: bytes
Content-Length: 142
Keep-Alive: timeout=15, max=2000
Connection: Keep-Alive
Content-Type: text/html
<Html> <Body><h1>page html </h1><p> contenant une
image <br>et une seule<img src="balle.gif“></p>
</Body><Html>
Le protocole HTTP (code de réponse)
Code Usage
Classe
1xx Information Informationnel : demande reçu, processus continue…
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 protocole HTTP et TCP
No. Time Source Destination Proto Info

1 0.000000 192.168.0.10 192.168.0.253 TCP 1282 > 80 [SYN]
2 0.000163 192.168.0.253 192.168.0.10 TCP 80 > 1282 [SYN, ACK]
3 0.000565 192.168.0.10 192.168.0.253 TCP 1282 > 80 [ACK]
4 0.001410 192.168.0.10 192.168.0.253 HTTP GET / HTTP/1.1
5 0.001487 192.168.0.253 192.168.0.10 TCP 80 > 1282 [ACK]
6 0.068550 192.168.0.253 192.168.0.10 HTTP HTTP/1.1 200 OK
7 0.098435 192.168.0.10 192.168.0.253 HTTP GET /images/tux.gif HTTP/1.1
8 0.098593 192.168.0.253 192.168.0.10 TCP 80 > 1282 [ACK]
9 0.099450 192.168.0.253 192.168.0.10 HTTP HTTP/1.1 200 OK
10 0.099724 192.168.0.253 192.168.0.10 HTTP Continuation
11 0.102794 192.168.0.10 192.168.0.253 TCP 1282 > 80 [ACK]
12 0.102915 192.168.0.253 192.168.0.10 HTTP Continuation
13 0.280331 192.168.0.10 192.168.0.253 TCP 1282 > 80 [ACK]

Requête du cache
L'internaute ferme son navigateur. Quelques instants plus tard, il l'ouvre à

nouveau et réclame la même page. Que va-t-il se passer ?

Requête du cache
La requête
La réponse
Le navigateur va donc réafficher la page qu'il a conservée en cache

Les méthodes HTTP
GET
 C'est la méthode la plus courante pour demander une
ressource. Une requête GET est sans effet sur la
ressource, il doit être possible de répéter la requête sans
effet.
HEAD
 Cette méthode ne demande que des informations sur
la ressource, sans demander la ressource elle-même.
POST
 Cette méthode est utilisée pour transmettre des
données en vue d'un traitement à une ressource (le plus
souvent depuis un formulaire HTML).

Les méthodes HTTP
OPTIONS
 Cette méthode permet d'obtenir les options de
communication d'une ressource ou du serveur en
général.
CONNECT
 Cette méthode permet d'utiliser un proxy comme un
tunnel de communication.
TRACE
 Cette méthode demande au serveur de retourner ce qu'il a
reçu, dans le but de tester et effectuer un diagnostic sur
la connexion.
Les méthodes HTTP
PUT
 Cette méthode permet de remplacer ou d'ajouter une
ressource sur le serveur. L'URI fourni est celui de la
ressource en question.
PATCH
 Cette méthode permet, contrairement à PUT, permet de
faire une modification partielle d'une ressource.
DELETE
 Cette méthode permet de supprimer une ressource du
serveur.

Les formulaires...
Les formulaires ont pour but de permettre au client

d'envoyer des données au serveur.
A charge pour lui de les traiter correctement.
Leur emploi va du simple « log in » à la

composition de documents très sophistiqués, et
hélas aussi parfois, à l'envoi d'informations qui ont
été récupérées sur votre système à votre insu.

Les formulaires par la méthode « GET »
Avec cette méthode, les données sont envoyées

dans l'URI de la page qui sera appelée lorsque vous
cliquerez sur « envoyer ».
http://irp.nain-
t.net/doku.php/210http:form_get?saisie1=riahla&B1=Demander

Les formulaires par la méthode « POST»
Les données sont envoyées de façon « invisible ».

<FORM action="http://somesite.com/prog/adduser"
method="post">
<P>
First name:
<INPUT type="text" name="firstname"><BR>
Last name:
<INPUT type="text" name="lastname"><BR>
email: <INPUT type="text" name="email"><BR>
<INPUT type="radio" name="sex" value="Male">
Male<BR>
<INPUT type="radio" name="sex" value="Female">
Female<BR> <INPUT type="submit" value="Send">
<INPUT type="reset">
</P>
</FORM>
Les cookies
Vous entrez sur un site privé qui nécessite une

authentification (nom d'utilisateur et mot de passe) A
priori, sans l'aide des cookies, vous seriez probablement
amené à vous identifier à chaque nouvelle page..
HTTP ne gère pas le concept de session
Le principe est simple : Une fois authentifié, le serveur

va déposer chez vous un « cookie » contenant des
informations qu'il peut ensuite aller relire à chaque
ouverture d'une nouvelle page, pendant toute la durée
de vie de ce cookie.
2016/2017 30
Les cookies
2016/2017 31
Le passage par un proxy
Le routeur NAT
Le routeur NAT agit au niveau IP. Il fonctionne pour
tous les protocoles applicatifs comme HTTP, FTP,
mais aussi POP, IMAP, SMTP etc.
Le proxy
Le serveur proxy travaille, lui, au niveau du
protocole applicatif lui-même. Un serveur proxy
n'assure aucun routage au niveau IP. En français,
on appelle ça un serveur mandataire.
2016/2017 32
Le proxy HTTP
• Relayer les requêtes HTTP reçues d'un client vers le

serveur demandé.
• Gestion de la concurrence
• Filtrage qui consiste à interdire certaines opérations.
interdire la récupération des documents en
provenance de certains sites, ou interdire les requêtes
provenant de certains clients.
• Journalisation (logging) de tous les événements pour
un suivi et une administration optimale.
• La gestion des droits de connexion au Proxy en
fonction de l'utilisateur en utilisant l’authentification
HTTP Basic.

Le proxy HTTP
• La configuration dynamique du Proxy via HTTP en

utilisant des formulaires (arrêt et démarrage, changement
du nombre de processus légers, …etc.).
• L’administration à distance et à temps réel du Proxy.

Exemple : visualisation des logs en fonction de différents
critères (date, numéro IP source, utilisateur, requête,
etc...), des informations de filtrage, état du relais….
• La gestion optimale du cache pour l’amélioration du

temps de réponse, plutôt que de renvoyer uniquement les
documents vers le client, le Proxy peut les stocker afin de
les resservir ultérieurement.

Le proxy « transparent »
• La présence du proxy est connue des utilisateurs du

réseau, ils doivent configurer leur navigateur pour
pouvoir l'utiliser.
• Il est possible de forcer les utilisateurs à passer par
le proxy en bloquant le port 80 sur la passerelle par
défaut.
• Laisser le client HTTP dans l'ignorance de l'existence du
proxy,
• Le client va exécuter un GET « normal » sur l'adresse IP
de la cible visée. Pour forcer le passage par le proxy, la
passerelle devra alors rediriger cette requête sur le
serveur proxy et ce dernier devra savoir retrouver
l'adresse de la cible.

Les connexions persistantes
Avec HTTP/1.0, la connexion est fermée par le

serveur après le transfert de la ressource.
Ainsi, chaque ressource requière sa propre

connexion pour être obtenue.
Ouvrir et fermer une connexion TCP/IP prend une

quantité non négligeable de ressources CPU, de
bande passante, et de mémoire sur le serveur web.

Les connexions non persistantes

Avec la possibilité de conserver ouverte une

connexion jusqu’au transfert complet d’une page,
la version 1.1, apporte un gain de performance
non négligeable, surtout si l’on songe qu’il s’agit
d’une connexion TCP qui fait l’objet d’une
négociation complète entre l’appelant et l’appelé
lors de son établissement.


 Si le client ne supporte pas les connexions persistantes, ou

si la requête est la dernière de la série, il faut inclure l'en-
tête Connection : close.
 Le serveur fermera la connexion après avoir envoyé la
réponse correspondante à cette requête.
 De même, si le serveur envoie cet en-tête dans la réponse
cela signifie qu'il fermera la connexion après cette réponse
et que le client ne devrait pas envoyer d'autres requêtes
sur cette connexion.
 Le serveur peut fermer la connexion avant d'avoir envoyé
toutes les réponses. Il faut donc que le client garde une
trace de toutes les transactions qui ont réussi, et relancer
les autres requêtes.

Gestion d'une connexion HTTP avec pipelining
 Le pipelining (chevauchement) pour les connexions

HTTP peut être vu comme une référence aux
pipelines des processeurs modernes.
On évite d'attendre que le résultat d'un calcul soit

stocké avant de commencer le calcul suivant.

Pour le protocole HTTP 1.1, le pipelining consiste

à conserver la même connexion ouverte (donc
persistante) afin de transmettre plusieurs
requêtes au même agent,
Emettre la requête suivante avant d'avoir reçu

la réponse à la dernière requête émise,
Extrêmement utile pour avoir un affichage

rapide pour une page html contenant de
nombreuses images.

images/hp3.gif

Négociation de contenu
 HTTP/1.1 essaie d'apporter une gestion

intelligente des documents.
La négociation du contenu (content négociation)
est un outil qui permet de renvoyer (ou récupérer
selon le cas) le document qui répondra au mieux
aux attentes du l'utilisateur.
 Server-driven Negotiation (le serveur qui va essayer de

déterminer le document qui va le mieux correspondre à l'utilisateur)
 Agent-driven Negotiation (le client HTTP essaie de demander
le meilleur document)
 Transparent Negotiation (combinaison des deux types
précédents: faire travailler les caches à la place du serveur )

Server-driven Negotiation
 Par exemple, si le serveur arrive à savoir que l'utilisateur

est français (en vérifiant le nom du navigateur par
exemple), il va essayer de renvoyer prioritairement les
documents écrits en français.
 L'intérêt est que c'est le serveur qui fait le calcul
Il y a cependant quelques désavantages :

 Le serveur ne peut pas tout savoir des besoins de
l'utilisateur (document à imprimer où à afficher à
l'écran ?);
 Le client ne peut pas tout dire au serveur: respect de
la vie privée
 Limitation des performances des caches.
Agent-driven Negotiation
 Cette fois-ci c'est le client HTTP qui essaie de demander
le meilleur document.
 La sélection se fait sur base d'une liste renvoyée par le
serveur.
c'est le client web qui est le mieux placé pour savoir

ce qu'attend l'utilisateur (langue, encodage
supporté).
inconvénient : la négociation se fait toujours en 2 temps

(demande de la liste des représentations puis demande du
bon document).

Transparent Negotiation
 C'est une combinaison des deux types
précédents.
 Faire travailler les caches à la place du
serveur :
 Sur une Agent-driven Negotiation (pour
obtenir la liste des représentations possibles),
 Lorsque le cache maîtrise son contenu, il
est alors capable de jouer le rôle du serveur
avec une Server-driven Negotiation.

Le caching en HTTP
Gagner du temps sur les documents fortement

demandés et aussi de réduire le trafic réseau.
Le problème consiste donc à savoir si le document a
été mis à jour
HTTP/1.1 inclut aussi la directive Pragma : no-cache

Le caching en HTTP
Last-modified: Thu, 25 Apr 1996 14:14:42 GMT

L'en-tête If-Modified-Since permet de faire des
requêtes conditionnelles.
GET /toto.html HTTP/1.1
If-Modified-Since: Thu, 25 Apr 1996 14:14:42
GMT
Si le document n'a pas été modifié depuis le serveur
répond avec le code 304 :
HTTP/1.0 304 Not Modified
Date: Fri, 24 May 1996 12:45:46 GMT
Server: Apache/1.1b2
Sinon il renvoie le document normalement.

Le caching en HTTP
 L’entête Expires, le serveur, dans la mesure du

possible, peut indiquer au cache une date
d'expiration du document.
Exemple : Expires: Fri, 24 May 1996 12:45:46

GMT

L’authentification HTTP
Pour le cas d’un serveur origine,

 Réponse 401 (Unauthorized)
 en-tête WWW-Authenticate
 Le client envoie le champ Authorization qui contient
l’accréditif (mot de passe par exemple)
Pour le cas d’un serveur Proxy,

 Réponse 407 (Proxy Authentication Required)
 en-téte Proxy-Authentication
 Le client envoie le champ Proxy- Authorization qui
contient l’accréditif (mot de passe par exemple)

Modèles d’authentification HTTP
Authentification HTTP Basic

 Un user-ID et un mot de passe pour chaque domaine
d'accès,
 représentée comme une chaîne non visible (codée)
 Sur toute réception d'une requête visant une URL dans

l'espace protégé, le serveur doit renvoyer une demande
d'identification de forme :
WWW-Authenticate: Basic realm="WallyWorld"
 Dans laquelle "WallyWorld" est le nom symbolique de

l'espace contenant l'URL-visée, attribué par le serveur.
 Pour obtenir l'autorisation d'accès, le client envoie l'user-
ID et le mot de passe, séparés par un deux-points (":"),
le tout encodé en base64.
Authentification HTTP Basic

Accréditif_de_base = "Basic" SP cookie-basique
cookie-basique = ["userID-mot_de_passe" encodé base64, limité à 76
char/line]
userID-mot_de_passe = [ nom_ID ] ":" *TEXT
 Si le client voulait utiliser l'user-ID « Aladdin »de passe «

open sesame », il spécifierait le champ ainsi:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
 une méthode non sécurisée de filtrage d'accès

à des ressources données sur un serveur HTTP

Authentification HTTP Digest

 Utilise les fonctions de hachage

Les versions HTTP
 HTTP 0.9: extrêmement simple.

 Connexion du client HTTP
 Envoi d'une requête de méthode GET (la seule
méthode!!!)
 Réponse du serveur HTTP
 Le serveur ferme la connexion pour signaler la fin de la
réponse.
 Si le document n’existe pas le serveur ne renvoie rien :
on ne peut pas savoir si le document est vide ou s’il
n’existe pas.
Si le WEB se résumait simplement à la
récupération de documents texte, la version 0.9
suffirait largement
Les versions HTTP
HTTP 1.0: RFC 1945

 La gestion de la connexion reste identique à HTTP 0.9,
 La notion d’en-têtes, introduite
 L’échange de méta information entre clients et serveurs
 Gérer les caches à l'aide de certaines de ses en-têtes
 Distinction entre les différents types de données (Texte,
Images, Son, …) MIME
 HTTP/1.0 permet aux utilisateurs.de.s’authentifier.
 HTTP 1.0 supporte aussi les méthodes HEAD et POST.
En effet, il faut encore ouvrir plusieurs
connexions par document pour en récupérer les
différents objets qui le composent (problème de
persistance).
Les versions HTTP
HTTP 1.1: RFC 2616

 Une meilleure gestion du cache,
 Les connexions persistantes sont devenues le
comportement par défaut. Connection:
Keep-Alive
 Un mécanisme d'authentification plus fiable
 Il est aussi permis à un client HTTP d'envoyer
plusieurs requêtes sur la même connexion
sans attendre les réponses (pipelining)
 Supporte la négociation de contenu Accept-,,,

Les versions HTTP
HTTP 1.1bis: En juin 2014

 Clarifier la spécification sans en modifier la sémantique
RFC 7230 (HTTP/1.1): Message Syntax and Routing (Standard proposé)

RFC 7231 (HTTP/1.1): Semantics and Content (Standard proposé)
RFC 7232 (HTTP/1.1): Conditional Requests (Standard proposé)
RFC 7233 (HTTP/1.1): Range Requests (Standard proposé)
RFC 7234 (HTTP/1.1): Caching (Standard proposé)
RFC 7235 (HTTP/1.1): Authentication (Standard proposé)
RFC 7236 (HTTP/1.1): Authentication Scheme Registrations (Information)
RFC 7237 (HTTP/1.1): Method Registrations (Information)

Les versions HTTP
HTTP/2: février 2015

 Débuter après la création du protocole SPDY proposé
par Google afin de réduire le temps de chargement des
pages Web,
 SPDY (Speedy)
 Intégré dans HTTP/2 (publié en mai 2015).
 Réduire la durée de téléchargement des pages
Web en classant par ordre de priorité,
 Multiplexer le transfert de plusieurs fichiers
(ceux composant une page web) de façon à ce
qu'une seule connexion soit requise.
 Intégrer dans Mozilla Firefox 11, Chrome, Opera 12,10, IE 11,
SAFARI 8,
HTTPs

2 HTTP

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2 HTTP

Transféré par

Droits d'auteur :

Formats disponibles

Université Université

Réalisé par : Mr RIAHLA

Elle se situe au sommet des couches de

Les applications de cette couche communiquent

Réalisé par : Mr RIAHLA 2009/2010 2

On peut les classer selon les services qu'ils rendent :

Les services de gestion (transfert) de fichier et

Les différents protocole existants dans cette

Réalisé par : Mr RIAHLA 2009/2010 3

Le protocole HTTP (Port 80)

Réalisé par : Mr RIAHLA 2009/2010 4

HTTP (Hyper Text Transfer Protocol) est le

Tout client web communique avec le port 80

Réalisé par : Mr RIAHLA 2009/2010 5

En prenant un exemple commun, de

Réalisé par : Mr RIAHLA 2009/2010 6

 L'ordinateur de l'internaute utilise le navigateur pour

 Cette requête demande un document (exemple:

 Le serveur cherche les informations, puis il est peut-

 Cette réponse contient les entêtes du protocole HTTP

HTTP (Hyper Text Transfert Protocol) est un

HTML (Hyper Text Markup Language) est un

Réalisé par : Mr RIAHLA 2009/2010 8

Réalisé par : Mr RIAHLA 2009/2010 9

Réalisé par : Mr RIAHLA 2009/2010 11

Réalisé par : Mr RIAHLA 2009/2010 10

 Syntaxe: Directive Valeur

 Peut spécifier un ordre pour les directives d’accés

 Permet d’avoir plusieurs serveurs sur une même machine

Réalisé par : Mr RIAHLA 2009/2010 64

Format de messages de l'internet permettant de

HTTP, un peu comme SMTP, ne sait pas nativement

Il est bien connu de tous que le web propose aussi

Réalisé par : Mr RIAHLA 2009/2010 12

Client et serveur doivent se mettre d'accord sur un

Dans tous les cas, ces données non textuelles

Réalisé par : Mr RIAHLA 2009/2010 13

http://www.debian.org est équivalent

Réalisé par : Mr RIAHLA 2009/2010 14

<body bgcolor= »#FFFFFF » text=

Réalisé par : Mr RIAHLA 2009/2010 15

La même chose que nous :

• Il appelle la page d'accueil GET / HTTP/1.0

Réalisé par : Mr RIAHLA 2009/2010 17

GET /~ferment/http/prog/page_test1.html HTTP/1.1

1xx Information Informationnel : demande reçu, processus continue…

2xx Succès L'action a été correctement reçue, interprétée, et exécutée…

Réalisé par : Mr RIAHLA 2009/2010 20

No. Time Source Destination Proto Info

Réalisé par : Mr RIAHLA 2009/2010 21

L'internaute ferme son navigateur. Quelques instants plus tard, il l'ouvre à

Réalisé par : Mr RIAHLA 2009/2010 22

Le navigateur va donc réafficher la page qu'il a conservée en cache

Réalisé par : Mr RIAHLA 2009/2010 23

Réalisé par : Mr RIAHLA 2009/2010 24

Réalisé par : Mr RIAHLA 2009/2010 26

Les formulaires ont pour but de permettre au client

A charge pour lui de les traiter correctement.

Leur emploi va du simple « log in » à la

Réalisé par : Mr RIAHLA 2009/2010 27

Avec cette méthode, les données sont envoyées

Réalisé par : Mr RIAHLA 2009/2010 28

Les données sont envoyées de façon « invisible ».