Centre Universitaire d’Aflou
Architecture des réseaux avancés
Présentation #8 : HTTP
Computer Networking
•
Chapter 2 : Section 2.2
Architecture des réseaux avancés : HTTP
• une page web est constituée d'objets, chacun d'entre eux
pouvant être stocké sur différents serveurs web.
• Un objet peut être un fichier HTML, JPEG, Java applet,
audio,…
• Une page web est constituée d'un fichier HTML de base qui
comprend plusieurs objets référencés, chacun adressable par
une URL, par exemple,
Architecture des réseaux avancés : HTTP
Demande de la page
Envoie de la page
Serveur
Client
Architecture des réseaux avancés : HTTP
https://www.cu-aflou.dz/DocPdf/master/master_guide_inscr.pdf
nom_du_protocole://adresse_du_site/chemin_du_repertoire/fichier
• Nom du protocole: Définit le mécanisme de communication utilisé. Le
Web utilise le protocole http.
• Adresse du site: Correspond à l’emplacement du serveur contenant le
site web. L’adresse du serveur est de forme numérique: 161.97.117.156
• Chemin du répertoire: Le répertoire contenant le fichier.
• Fichier: Le nom du fichier désiré.
Architecture des réseaux avancés : HTTP
Client
1
Etablir une connexion
avec le serveur
2
Demander la page
Serveur
Architecture des réseaux avancés : HTTP
• le client établit une connexion TCP (crée un socket) avec le serveur
en utilisant le port 80
• Le serveur accepte la demande de connexion.
• Messages HTTP (messages du protocole de la couche application)
échangés entre le navigateur (client HTTP) et le serveur Web
(serveur HTTP).
• Connexion TCP fermée.
• HTTP is stateless: le serveur ne conserve aucune information sur les
demandes passées des clients.
Architecture des réseaux avancés : HTTP
Non-persistent HTTP
Persistent HTTP
1. Ouverture de connexion
2. Au plus un seul objet est
envoyé et reçu.
3. Fermeture de la connextion.
1. Ouverture de connexion
2. plusieurs objets peuvent être
envoyés sur une seule
connexion TCP entre le client
et le serveur.
3. Fermeture de la connexion.
le téléchargement de plusieurs
objets nécessite plusieurs
connexions.
Architecture des réseaux avancés : HTTP
Utilisateur saisie:
www.cu-aflou.dz/index.html
(contenant du texte et références à 10 images jpeg)
1a. Le client HTTP établit une
connexion TCP avec le serveur
HTTP (processus) à l'adresse
www.cu-aflou.dz sur le port 80.
2. Le client HTTP envoie un
message de demande HTTP
(contenant l'URL) dans le
socket de connexion TCP. Le
time
message indique que le client
veut l'objet index.html
1b. Le serveur HTTP attend une
connexion TCP sur le port 80. Il
"accepte" la connexion et en
informe le client.
3. Le serveur HTTP reçoit le message de
demande, forme le message de
réponse contenant l'objet demandé,
et envoie le message dans son socket.
Architecture des réseaux avancés : HTTP
Utilisateur saisie:
www.cu-aflou.dz/index.html
(contenant du texte et références à 10 images jpeg)
5. Le client HTTP reçoit un message de
4. Serveur HTTP ferme la
connexion.
réponse contenant un fichier html,
affiche le html. Analyse du fichier
html, trouve 10 objets jpeg référencés.
6. Etapes 1-5 répétées pour
chacun des 10 objets jpeg
time
Architecture des réseaux avancés : HTTP
Temps de réponse HTTP (par objet)
• 1 RTT pour initier une connexion.
• un RTT pour la demande HTTP et les
premiers octets de la réponse HTTP à
retourner
• Temps nécessaire à la transmission de
l’object/fichier.
initiate TCP
connection
RTT
request file
time to
transmit
file
RTT
file received
time
Temps de réponse = 2RTT+ temps transmission fichier
Architecture des réseaux avancés : HTTP
time
• Necessite 2 RTTs par object
• Surcharge pour le système d’exploitation.
• Les navigateurs ouvrent souvent plusieurs connexions TCP
parallèles pour récupérer les objets référencés.
Architecture des réseaux avancés : HTTP
• Le serveur laisse la connexion ouverte après avoir envoyé la réponse
• Les messages HTTP ultérieurs entre le même client/serveur sont
envoyés sur une connexion ouverte.
• Le client envoie une requête dès qu'il rencontre un objet référencé.
• Un seul RTT pour tous les objets référencés (réduisant de moitié le
temps de réponse).
Architecture des réseaux avancés : HTTP
GET / HTTP/1.1
Host: www.cu-aflou.dz
Client
HTTP/1.1 200 OK
…
<html> … </html>
Architecture des réseaux avancés : HTTP
Serveur
Message de requête
GET / HTTP/1.1
Host: www.cu-aflou.dz
User-agent: Mozilla/5.0
Connection: Keep-alive
Accept-language: fr
Message de réponse
HTTP/1.1 200 OK
Date: Tue, 01 Mar 2022 00:15:00 GMT
Server: Apache
Content-Length: 189286
Content-Type: text/html
Architecture des réseaux avancés : HTTP
method
sp
URL
header field name
sp
value
version
cr lf
cr lf
header
lines
~
~
~
~
header field name
value
request
line
cr lf
cr lf
~
~
entity body
Architecture des réseaux avancés : HTTP
~
~
body
• 200 OK: Requête acceptée. Les information demandé sont envoyés
avec le message retourné.
• 301 Moved Permanently: L’objet demandé a été transféré. La
nouvelle adresse est envoyé avec le message retourné.
• 400 Bad Request: Mauvaise requête (le serveur n’a pas compris cette
requête).
• 404 Not Found: L’objet demandé n’existe pas.
• 505 HTTP Version Not Supported: Le serveur ne prend pas en
charge la version HTTP utilisé.
Architecture des réseaux avancés : HTTP
• GET: Utilisé pour demander un objet.
• POST: Utilisé quand l’utilisateur envoie des information, comme
remplir un formulaire.
• HEAD: Quand un serveur reçois une requête HEAD, il répond mais
n’envoie aucun objet. Généralement utilisé par les développeurs pour
tester.
• PUT: Permettre à un utilisateur d’envoyer (upload) un objet à un
serveur (répertoire).
• DELETE: Permet de supprimer un objet d’un serveur Web.
Architecture des réseaux avancés : HTTP
stateful protocol: le client apporte
deux modifications à X, sinon aucune.
Comme discuté, HTTP ne conserve
aucune information (stateless)
 aucune notion d'échanges de
messages HTTP en plusieurs étapes
pour achever une transaction Web
• il n'est pas nécessaire que le
client/serveur suive l'état de l'échange en
plusieurs étapes.
• Toutes les requêtes HTTP sont
indépendantes les unes des autres
• Le client/serveur n'a pas besoin de
corriger une transaction partiellement
achevée.
X
X
X’
t’
X’’
X’’
time
time
Q: que se passe-t-il si la connexion réseau ou le
client se bloque au temps t' ?
Architecture des réseaux avancés : HTTP
Les sites Web et le navigateur du client utilisent des cookies
pour conserver certains états entre les transactions.
quatre composantes
1) L’entête du cookie dans la réponse HTTP.
2) L'en-tête du cookie dans le prochain message de requête HTTP
3) Fichier cookie conservé sur l'hôte de l'utilisateur, géré par le
navigateur de l'utilisateur.
4) Base de données du site Web (back-end).
Architecture des réseaux avancés : HTTP
client
serveur
Requête HTTP
Fichier cookie
Réponse HTTP
set-cookie: 1678
amazon 1678
Serveur Amazon
crée ID
1678
entrée
créé
Requête HTTP
spécification
du cookie
cookie: 1678
Réponse HTTP
Base de données
(back-end)
Une semaine
plus tard
accès
Requête HTTP
amazon 1678
spécification
du cookie
cookie: 1678
Réponse HTTP
time
accès
time
Architecture des réseaux avancés : HTTP
Les cookies sont utilisés pour:
• autorisation
• paniers d'achat
• recommendations
• état de session de l'utilisateur (e-mail Web)
Architecture des réseaux avancés : HTTP
Architecture des réseaux avancés : HTTP
1
4
2
GET fichier html de
base nytimes.com
5
récupérer la
publicité AdX.com
7
afficher la page
composée
nytimes.com
HTTP 1
GET
2 HTTP
reply
3
4
6
5
Page du NY Times avec
publicité intégrée affichée
AdX.com
Architecture des réseaux avancés : HTTP
1634: sports, 2/15/22
nytimes.com (sports)
HTTP
GET
“first party” cookie – du
site web que vous avez
choisi de visiter (fournit
le fichier html de base)
HTTP
reply
Set cookie: 1634
HTTP GET
Referer: NY Times Sports
4
“third party” cookie – à
partir d'un site web qu’on
a pas choisi de visiter
7493: NY Times sports, 2/15/22
5
HTTP reply
NY Times: 1634
AdX: 7493
Set cookie: 7493
Architecture des réseaux avancés : HTTP
AdX.com
1634: sports, 2/15/22
AdX:
nytimes.com
socks.com
2
HTTP 1
GET
HTTP GET
Referer: socks.com, cookie: 7493
 suit ma navigation sur
les sites contenant des
publicités AdX
 Renvoie des publicités
ciblées en fonction de
l'historique de navigation
4
7493: NY Times sports, 2/15/22
7493: socks.com, 2/16/22
5
HTTP reply
NY Times: 1634
AdX: 7493
Set cookie: 7493
Architecture des réseaux avancés : HTTP
AdX.com
1634: sports, 2/15/22
1634: arts, 2/17/22
nytimes.com (arts)
socks.com
HTTP
GET
cookie: 1634
HTTP
reply
Set cookie: 1634
HTTP GET
Referer:nytimes.com, cookie: 7493
4
7493: NY Times sports, 2/15/22
7493: socks.com, 2/16/22
7493: NY Times arts, 2/15/22
5
HTTP reply
NY Times: 1634 Set cookie: 7493
AdX: 7493 Renvoie pub pour
chaussettes!
Architecture des réseaux avancés : HTTP
AdX.com
Les cookies peuvent être utilisés pour:
• suivre le comportement des utilisateurs sur un site web donné
(first party cookies).
• suivre le comportement des utilisateurs sur plusieurs sites web
(third party cookies) même que l'utilisateur n’a pas choisi de visiter
le site!
• Le suivi peut être invisible pour l'utilisateur:
• plutôt qu'une publicité affichée déclenchant un HTTP GET vers le tracker, il
pourrait s'agir d'un lien invisible.
third party tracking via cookies:
• Désactivés par défault sur Firefox et Safari.
• sera désactivé sur Chrome en 2023.
Architecture des réseaux avancés : Couche transport
Les Web caches sont utlisés pour satisfaire les demandes des clients
localement (sans passer par le serveur d'origine)
• l'utilisateur configure son
navigateur pour qu'il pointe
2
1 Web
vers un cache Web (local)
cache
client
origin
• le navigateur envoie toutes
4
server
3
5
les requêtes HTTP au cache
• if objet dans le cache : le cache
renvoie l'objet au client
• else cache demande un objet au
serveur d'origine, met en cache
l'objet reçu, puis renvoie l'objet
au client.
6
client
Architecture des réseaux avancés : HTTP
• Le cache web agit à la fois comme client et comme serveur
• serveur pour le client demandeur original
• client pour server d’origine
• Le serveur le cache s’il peut sauvegarder une copie dans l’entête de la
réponse
Architecture des réseaux avancés : HTTP
• Reduire le temps de réponse
• cache est proche du client
• réduire la charge réseau trafic sur la liaison d'accès d'une institution.
• permet aux fournisseurs de contenu (serveur Web) non fiable de
diffuser plus efficacement leur contenu.
Architecture des réseaux avancés : HTTP
Scenario:
•
•
•
•
access link rate: 1.54 Mbps
RTT from institutional router to server: 2 sec
web object size: 100K bits
average request rate from browsers to origin
servers: 15/sec
• avg data rate to browsers: 1.50 Mbps
Performance:
retards
• access link utilization = .97
importants dans
• LAN utilization: .0015
les files d'attente
• end-end delay = Internet delay +
access link delay + LAN delay
= 2 sec + minutes + µsecs
Architecture des réseaux avancés : HTTP
origin
servers
public
Internet
1.54 Mbps
access link
institutional
network
1 Gbps LAN
Scenario:
•
•
•
•
154 Mbps
access link rate: 1.54 Mbps
RTT from institutional router to server: 2 sec
web object size: 100K bits
average request rate from browsers to origin
servers: 15/sec
• avg data rate to browsers: 1.50 Mbps
Performance:
.0097
• access link utilization = .97
• LAN utilization: .0015
• end-end delay = Internet delay +
access link delay + LAN delay
= 2 sec + minutes + usecs
msecs
Coût : liaison d'accès plus rapide (chère !)
Architecture des réseaux avancés : HTTP
origin
servers
public
Internet
154 Mbps
1.54 Mbps
access link
institutional
network
1 Gbps LAN
Scenario
•
•
•
•
access link rate: 1.54 Mbps
RTT from institutional router to server: 2 sec
web object size: 100K bits
average request rate from browsers to origin
servers: 15/sec
• avg data rate to browsers: 1.50 Mbps
Coût : cache web (bon marché !)
Performance
• LAN utilization: .?
• access link utilization = ?
• average end-end delay = ?
origin
servers
public
Internet
1.54 Mbps
access link
institutional
network
Comment calculer
l'utilisation du lien, le retard ?
Architecture des réseaux avancés : HTTP
1 Gbps LAN
local web cache
On suppose:
origin
servers
 40% des demandes sont servies par le cache(msec)
 60% satisfaites par le serveur d’origine
• rate to browsers over access link
= 0.6 * 1.50 Mbps = .9 Mbps
• access link utilization = 0.9/1.54 = .58 means
low (msec) queueing delay at access link
 Délais moyen
= 0.6 * (delay from origin servers)
+ 0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
public
Internet
1.54 Mbps
access link
institutional
network
1 Gbps LAN
local web cache
retard moyen à l'arrivée plus faible qu'avec une liaison de 154 Mbps (et moins cher aussi !)
Architecture des réseaux avancés : HTTP
serveur
client
ne pas envoyer l'objet si le
navigateur possède la dernière
version
HTTP request msg
If-modified-since: <date>
• aucun délai de transmission
HTTP response
HTTP/1.0
304 Not Modified
object
not
modifié
avant
<date>
• client: spécifier la date de la copie
en cache dans la requête HTTP
If-modified-since: <date>
• server: aucun objet n’est reçu si la
copie en cache est à jour :
HTTP request msg
If-modified-since: <date>
HTTP/1.0 304 Not Modified
Architecture des réseaux avancés : HTTP
HTTP response
HTTP/1.0 200 OK
<data>
object
modifié
après
<date>
• Le protocole HTTP1.1 permet d’envoyer multiples GETs en pipeline
sur une seule connexion TCP
• Le serveur répond dans l'ordre (FCFS : first-come-first-served) aux
requêtes GET.
• Avec l’algorithme FCFS, un petit objet peut devoir attendre la
transmission d’un ou plusieurs gros objets (Head of Line (HOL)
blocking).
• La récupération des pertes (retransmission des segments TCP
perdus) bloque la transmission des objets
Architecture des réseaux avancés : HTTP
• Le protocole HTTP/2 a été introduit en 2015 [RFC 7540]
• Diminue le délai relatis aux requêtes HTTP multi-objets.
• Offre une flexibilité plus grande aux serveur lors d’envoie des
objets.
• Utilises les même methodes, codes d’etats et presque tous les
champs d’entête que HTTP 1.1.
• Ordre de transmission des objets est basé sur la priorité des objets
spécifiée par le client (pas nécessairement FCFS).
• Envoyer (push) les objets non demandés vers le client.
• Diviser les objets en morceaux afin d’atténuer le blocage HOL.
Architecture des réseaux avancés : HTTP
HTTP 1.1 : le client demande un objet de grande taille (une vidéo) et trois
objets plus petits.
serveur
GET O4
GET O3
GET O2
GET O1
Objects demandés
client
O1
O1
O2
O3
O2
O3
O4
O4
les objets sont livrés dans l'ordre demandé : O2 ,O3 ,O4 attendent derrière O1
Architecture des réseaux avancés : HTTP
HTTP/2: objets divisés en morceaux
serveur
GET O4
GET O3
GET O2
GET O1
Objects demandés
client
O2
O4
O1
O3
O2
O3
O4
O1
O2 ,O3 ,O4 livrés rapidement, O1 légèrement retardé
Architecture des réseaux avancés : HTTP
• HTTP/2 sur une seule connexion TCP signifie :
• la récupération après une perte de paquets bloque toujours toutes
les transmissions d'objets
•
comme dans le protocole HTTP 1.1, les navigateurs sont incités à ouvrir
plusieurs connexions TCP parallèles afin de réduire les blocages et
d'augmenter le débit global.
• aucune sécurité sur une connexion TCP classique
• HTTP/3: Ajoute des mécanismes de sécurité, le contrôle d'erreur et
de congestion par objet (plus de pipelining) sur UDP.
Architecture des réseaux avancés : HTTP
E-mail
user
agent
Trois composantes majeures :
• user agents
• mail servers
• simple mail transfer protocol: SMTP
mail
server
user
agent
SMTP
SMTP
1. User Agent (lecteur d’emails)
• composer, éditer, lire des messages de
courrier
mail
server
• e.g., Outlook, Thunderbird
• messages sortants et entrants stockés sur
le serveur
user
agent
Architecture des réseaux avancés : E-mail
SMTP
mail
server
user
agent
user
agent
user
agent
outgoing
message queue
user mailbox
user
agent
2. mail servers
• mailbox contient les messages
entrants
• message queue file des messages à
envoyer
3. SMTP protocol entre les serveurs
de messagerie pour envoyer des
messages électroniques
•
•
client: serveur d'envoi de courier
server: serveur de réception
mail
server
user
agent
SMTP
SMTP
mail
server
user
agent
Architecture des réseaux avancés : E-mail
SMTP
mail
server
user
agent
user
agent
user
agent
outgoing
message queue
user mailbox
“client”
SMTP server
• protocole d'échange de messages
électroniques, défini dans la RFC 5321
• Utilise TCP, port 25
• Trois phases de transfert
“serveur”
SMTP server
Initier connexion TCP
RTT
Connexion ouverte
• SMTP handshaking (greeting)
• SMTP transfert de messages
• SMTP closure
220
SMTP
handshaking
250 Hello
• interaction commande/réponse (comme HTTP)
• commands: texte ASCII
• response: code d'état et phrase
HELO
SMTP transfer
time
Architecture des réseaux avancés : E-mail
1) Ahmed utilise l'UA pour composer un message
électronique "à" mohamed@someschool.edu.
4) Le client SMTP envoie le message
d'Ahmed via une connexion TCP.
2) L'UA d'Ahmed envoie un message à son serveur
de messagerie à l'aide du protocole SMTP ; le
message est placé dans la file d'attente
5) Le serveur de courrier de
Mohamed place le message
dans la boîte aux lettres
3) côté client du SMTP, le serveur de messagerie
ouvre une connexion TCP avec le serveur de
messagerie de Mohamed.
6) Mohamed invoque son UA
pour lire le message
1
user
agent
2
Ahmed
mail
server
3
user
agent
mail
server
4
Ahmed’s mail server
6
5
Mohamed’s mail server
Architecture des réseaux avancés : E-mail
Mohamed
•
•
•
•
•
•
•
•
•
•
•
•
HELO <domaine> : Initialisation de la session SMTP
MAIL FROM:<route-inverse> : déclaration de l’émetteur du mail
RCPT TO:<route-directe> : déclaration du destinataire du mail
DATA : initialisation de la séquence de saisie des données
RSET : initialisation de la séquence de saisie des données
SEND FROM:<route-inverse> : message direct plutôt que postage.
VRFY <chaîne> : vérification de l’existence d’un destinataire
EXPN <chaîne> : extraction des destinataires inscrits dans une liste de
diffusion
HELP [ <chaîne> ] : demande d’aide (éventuellement sur une commande)
NOOP : aucune opération
TURN : demande d’inversion des rôles d’émetteur et de récepteur
QUIT : clôture de la session SMTP
Architecture des réseaux avancés : E-mail
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <alice@crepes.fr>
250 alice@crepes.fr... Sender ok
RCPT TO: <bob@hamburger.edu>
250 bob@hamburger.edu ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
Architecture des réseaux avancés : E-mail
comparaison avec HTTP:
• HTTP: client pull-based
• SMTP: client push-based
• HTTP : chaque objet est encapsulé dans son propre message de
réponse.
• SMTP : envoi de plusieurs objets dans un message multipartite
• SMTP utilise des connexions persistantes.
• Le SMTP exige que le message (en-tête et corps) soit en ASCII 7 bits.
• Le serveur SMTP utilise CRLF.CRLF pour déterminer la fin du message.
Architecture des réseaux avancés : E-mail
La RFC 2822 définit la syntaxe du message électronique lui-même
(comme le HTML définit la syntaxe des documents Web).
• header lines, e.g.,
• To:
• From:
• Subject:
• Ces lignes, dans le corps du message
électronique, sont différentes des
commandes SMTP MAIL FROM :, RCPT TO:
• Body: le message en ASCII
Architecture des réseaux avancés : E-mail
header
body
blank
line
user
agent
SMTP
SMTP
e-mail access
protocol
user
agent
(e.g., IMAP,
HTTP)
Serveur e-mail
de l’emetteur
Serveur e-mail
du recepteur
• IMAP: Internet Mail Access Protocol [RFC 3501].
• IMAP permet de récupérer, de supprimer, de classer les messages stockés
sur le serveur.
• HTTP: Gmail, Hotmail, Yahoo!, etc. fournit une interface web en plus de
STMP (pour envoyer), IMAP (ou POP) pour récupérer les messages
électroniques.
Architecture des réseaux avancés : E-mail