Chap 3

Chapitre : Services Applicatives
1
slides are modified from J. Kurose & K. Ross
Objectifs
 Conception d’une application réseau
 Comprendre le fonctionnement des principaux
protocoles de la couche application
 Web (http, URI, MIME, Web Socket)
 (FTP, DNS, DHCP, Email P2P, DHT (Distributed Hash
Table))
2
Création d’une application réseau
 Applications et protocoles applicatives
Protocoles applicatifs
 Une (grosse) partie des
applications
Applications •Web : HTML, browsers Web, serveurs
Web et HTTP pour définir l'échange des
 S’exécutent dans les hôtes messages
dans l’espace utilisateur •Mail : serveurs de mails, mail readers,
 Échangent des messages standard pour le format des mails et
protocole applicatif pour l'échange des
 Ex : éditeur de texte, transfert messages (ex : SMTP)
de fichier, Web  Définissent :
•le format et l'ordre des messages
échangés par les applications,
•les actions consécutives à l'émission ou
3
la réception d'un message
 écrire des programmes qui application
transport
network
 s’exécutant sur différents data link
physical
systèmes terminaux
 communiquent à travers le
réseau
 exemple : le logiciel d’un
serveur web qui communique
avec le logiciel du navigateur
application
 pas besoin d’écrire du logiciel pour transport
network
data link
application
 les équipements intermédiaires physical
transport
network
car ils n’exécutent pas les data link
physical
applications des utilisateurs
 Les applications sur les
équipements terminaux permettent
le développement rapide, …
 Un protocole applicatif définit
 Les types de messages échangés
 Protocoles du domaine
 e.g., demande, réponse publiques
 La syntaxe du message  définit dans les RFCs
 quels champs et comment  permettent
sont-ils délimités dans un l’interopérabilité
message
 exemple : HTTP, SMTP
 La sémantique d’un message
 Protocoles propriétaires
 La signification des
informations dans les champs  e.g., Skype
 Règles pour définir quand et

comment les processus
envoient/reçoivent les messages
 Un protocole applicatif : API (Application Programming
Interface)
Socket : API Internet
 Définit l’interface entre l’application et la couche transport
 Deux processus communiquent en émettant et recevant des
données via les sockets
controlled by
controlled by process application
application process
developer
developer socket socket
TCP with TCP with controlled by
controlled by
buffers, operating
operating buffers, internet system
system variables variables
host or host or
server server
 A quelle application est destiné le nouveau paquet?
IP: 74.125.115.99
Applications
Operating
System Web server
SSH server
Transport SSH client

Network Web browser
Link Layer
Skype
Link Layer
Physical Layer IM
Adressage au niveau de la couche de transport : les ports
Dest IP: 74.125.115.99 8

 Multiplexage de la couche du transport : TCP
Je souhaite Je souhaite
communiquerIP: 128.174.13.63 IP: 74.125.115.99 accepter les
avec 74.125.115.99 communications
sur le port 80 Operating Operating sur le port 80
System System
socket Web
Web
TCP port TCP port 80 server
browser 23421 Dest IP: 74.125.115.99
app
Source IP: 128.174.13.63
Dest port: 80 Network
app
Network Source port: 23421
Link layer
Link layer
 Une application réseau est identifiée par une @IP, protocole de transport et 9
un port
Je souhaite
IP: 128.174.13.63 communiquer IP: 74.125.115.99
avec 74.125.115.99
Operating
sur le port 80 Operating
System System
socket Web
Web socket TCP port TCP port 80 server
browser 23421 Dest IP: 128.174.13.63
app
Source IP: 74.125.115.99
app
Network Source port:80
Link layer
Link layer
un port
IP: 128.174.13.63 IP: 74.125.115.99
Operating Operating
System System
socket Web
Web socket TCP port TCP port 80 server
browser 23421 Dest IP: 74.125.115.99
socket app
app Source IP: 128.174.13.63
Link layer
Link layer
un port
Je veux envoyer les
données : IP: 74.125.115.99
IP: 128.174.13.63
XXSFGFEWRV
Operating Operating
System System
socket Web
Web socket Dest IP: 74.125.115.99
TCP port TCP
TCP port
port 80
80 server
browser 23421 Dest IP: 74.125.115.99
Source IP: 128.174.13.63
Protocol: TCP
socket app
app Source IP: 128.174.13.63
Protocol: TCP
Dest port: 80
Source port: 23421 Network
Network Dest port: 80 Data:
Data: XXSFGFEWRV
XXSFGFEWRV
Source port: 23421
Link layer
Link layer Data: XXSFGFEWRV
Dest IP: 74.125.115.99

Source IP: 128.174.13.63
Protocol: TCP
Dest port: 80
Source port: 23421
Data: XXSFGFEWRV
un port
 Multiplexage de la couche du transport :UDP
I would like to
I would like to
send/receive
IP:data
128.174.13.63 IP: 74.125.115.99
receive any data on
over UDP port
UDP port 1401
23421 Operating Operating
System System
socket IM
IM client socket UDP port UDP port 1401 Server
app 23421
Network
app
Network
Link layer
Link layer
 Une application réseau est identifiée par une @IP, protocole de transport et
un port
 Multiplexage de la couche du transport :UDP
Send data to
IP:port
74.125.115.99 128.174.13.63 IP: 74.125.115.99
1401
Data: xxadre Operating Operating
System System
socket IM
IM client socket UDP port Dest IP: 74.125.115.99 UDP port 1401 Server
app 23421 Source IP: 128.174.13.63
Protocol: UDP
Network
app
Dest port: 1401
Data: xxadre Data: xxadre Link layer
Link layer
 Une application réseau est identifiée par une @IP, protocole de transport et
un port
 Règles pour création d’une application réseau
 Choix du protocole du transport
 Choix des ports
 API socket
 Chapitre suivant
Services applicatives
 Pile TCP/IP
16
From: John Doe <example@example.com>
MIME-Version: 1.0
 Web et MIME Content-Type: multipart/mixed;
 Multipurpose Internet boundary="XXXXboundary text"
Mail Extensions : MIME
This is a multipart message in MIME
 Standard internet qui format.
étend le format de données
attachées à un courrier --XXXXboundary text
mais aussi pour typer les Content-Type: text/plain
documents transférés par
this is the body text
HTTP
 Non seulement du texte --XXXXboundary text
ASCII mais, d’autres Content-Type: text/plain;
codages, multimédia, … Content-Disposition: attachment;
filename="test.txt"
this is the attachment text

17
--XXXXboundary text--
 Web et MIME
 L’entête MIME :
 les noms des en–têtes de messages et leurs valeurs sont
toujours en caractères ASCII, RFC 2822
 MIME-Version : contenu du message est formaté en MIME
 MIME-Version: 1.0
 Content-Type : il est composé par un type et un sous-type,
RFC 2046,
 Content-Type: text/plain
 Content-Transfer-Encoding : un ensemble de méthodes
pour représenter des données quelconques sous forme de
texte ASCII avant la transmission réseau.
 Content-Transfer-Encoding: base64
18
 Web et MIME
 Encodage du texte : encodage peut être précisé avec
l’attribut « charset= » de l’en-tête « Content-Type»
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Ceci est un message encod=C3=A9 en UTF-8, puis transform=C3=A9

en ASCII par la m=C3=A9thode "Quoted-Printable".
 Le texte orignal est codé en utilisant UTF-8 et le transfert se fera en

format Quoted-Printable
 « é » s’encode en UTF-8 par deux octets de valeurs hexadécimales C3
et A9, qui sont à leur tour encodés en Quoted-Printable par la
séquence «=C3=A9 ».
19
 Web et MIME
 Encodage de message en plusieurs parties : spécifie une
ligne de séparation dans l'en-tête « Content-type: », via
l’attribut « boundary= ».
Content-type: multipart/mixed; boundary="''frontière''"
MIME-version: 1.0
This is a multi-part message in MIME format.

--''frontière''
Content-type: text/plain
This is the body of the message.
--''frontière''
Content-type: application/octet-stream
Content-transfer-encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
20
--''frontière''--
 Web et MIME
 Content-type : Les types principaux sont les suivants
 Type application : fichiers pluri-usages.
 application/javascript : JavaScript ; défini dans la RFC 4329.
 application/octet-stream : flux de données arbitraire.
 application/ogg : Ogg, un flux de données multimedia,
conteneur ; RFC 3534.

 application/pdf: Portable Document Format, PDF; RFC 3778.
 application/xhtml+xml : XHTML ; RFC 3236.
 application/json : JavaScript Object Notation ; RFC 4627.
 application/xml : eXtensible Markup Language ; RFC 3023.
 application/zip : fichier ZIP.
 Type text : texte lisible par un être humain ou code source

 text/css : feuilles de style en cascade ; RFC 2318
 text/csv : comma-separated values ; RFC 4180.
 text/html : HTML ; défini dans la RFC 2854.

21
 text/plain : données textuelles ; RFC 2046 et la RFC 3676.
 Web et MIME
 Content-type : Les types principaux sont les suivants
 Type image
 image/gif : GIF ; défini dans la RFC 2045 et la RFC 2046.
 image/jpeg : JPEG image JFIF ; RFC 2045
 image/png : Portable Network Graphics
 image/tiff : Tagged Image File Format ; RFC 3302.
 image/vnd.microsoft.icon : icône ICO
 Type audio : audio.

 audio/mpeg : MP3 ou autres MPEG ; RFC 3003
 audio/x-ms-wma : Windows Media Audio
 audio/vnd.rn-realaudio : RealAudio ;
 audio/x-wav : WAV
22
 Web et MIME
 Pour déterminer le MIME d’un fichier, il existe plusieurs API
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
public class Test {

public static void main(String[] args) throws IOException {
Path source = Paths.get("c:/temp/0multipage.tif");
System.out.println(Files.probeContentType(source));
// output : image/tiff
}
}
 http://www.rgagnon.com/javadetails/java-0487.html
23
 Web et MIME
 Pour déterminer le MIME d’un fichier, il existe plusieurs API
import java.net.URLConnetion;
mimeType= URLConnection.guessContentTypeFromName(file.getName());
Ou
InputStream is = new BufferedInputStream(new FileInputStream(file));

mimeType = URLConnection.guessContentTypeFromStream(is);
//...close stream
24
 Web et URI
 Objectif : identifier une ressource de manière permanente, même si
la ressource est déplacée ou supprimée (dans l’absolu).
 URI : Uniform Ressource Identifier (RFC 3986, 01/2005)

 Un système de désignation de ressources via le Web sous
forme de chaines de caractères
 Technologie de base du World Wide Web car tous les
hyperliens du Web sont exprimés sous forme d'URI
 Uniform : s’affranchir des mécanismes d’accès aux ressources
(protocoles)
 Ressource : HTML, image, son, forum Usenet, boîte aux lettres
électronique, tout sans limite
 Identifier : distinguer les ressources 26
 Web et URI
 ftp://ftp.is.co.za/rfc/rfc1808.txt
 gopher://spinalap.micro.umn.edu/00/Weather/California/Los%20Angeles
 http://www.math.uio.no/faq/compression-faq/part1.html
 mailto:mduerst@ifi.unizh.ch
 news:comp.infosystems.www.servers.unix
 telnet://melvyl.ucop.edu/
 irc://irc.freenode.net/ubuntu-fr
 ssh://utilisateur@example.com
 sftp://utilisateur@example.com
 http://example.org/URI/absolu/avec/chemin/absolu/vers/une/ressource
 /URI/relatif/avec/chemin/absolu/vers/une/ressource
 chemin/relatif/vers/une/ressource ou ../../../ressource
27
 ./ressource#fragment ou ressource ou #fragment
 Web et URI
 Un URI peut être de type « locator » ou « name » ou les deux.
 URL : Uniform Resource Locator

 Fournit les moyens d'agir sur une ressource ou d'obtenir
une représentation de la ressource en décrivant son mode
d'accès primaire ou « emplacement » réseau.
 Fait référence à des protocoles existants : http, ftp, ..
 Pointe sur un document sur un serveur
 URN : Uniform Resource Name

 URI globalement unique, persistant et indépendant de la
localité. Par exemple, urn:isbn:0-395-36341-1 est un URI
qui, étant un numéro de l'International Standard Book
Number (ISBN), permet de faire référence à un livre, mais
28
ne suggère ni où, ni comment en obtenir une copie réelle.

 Web et URI
Syntaxe d’un URI :
<scheme name> : <hierarchical part> [ ? <query> ] [ #
<fragment> ]
 scheme name : urn, ftp, http, mailto, ..
 hierarchical part : est composée d’une authority et d’un path
 Authority : [user:password]+a host+ [a port]
 Path : une séquence de segments séparée par /
 query : requête sous forme de clé=valeur séparée par &

 fragment : sous ensemble d’un objet, un attribut d’un élément
de la page
 Si l'autorité est liée à un serveur, elle a la forme suivante:
[<userinfo>@]<machine>[:<port>] 29
 Si port n'est pas spécifié, port par défaut associé au schéma

 Web et URI
 Exemple d’un URI :
30
 Web et URI
 URL et http:
 Le schéma et le host peuvent être omit si l’objet référencé
se trouve sur la même machine que le document de
référence
 Un chemin complet est utilisé lorsqu’il s’agit d’un autre
serveur. Un chemin relatif dans le cas contraire
 Le port peut être aussi omit : la valeur par défaut du
protocole listée dans le fichier /etc/services
généralement 80
 Un chemin complet est utilisé lorsqu’il s’agit d’un autre
serveur
 Les fragments permettent de faire un saut à l’étiquette de
la page (Anchor)
31
 http://www.x.y/z#foo
 Web et URI
 API Java : java.net.URI
 Méthodes
 Très peu utilisée
32
 Web et URI
 API Java : java.net.URL et java.net.URLConnection
 Accéder aux informations du Web en utilisant des URLs.
 new URL("http://massena.univ-mlv.fr/index.html");
 new URL("http","massena.univ-mlv.fr",80,"index.html");
 new URL("http://massena.univ-mlv.fr/","index.html")
 Pour accéder aux informations contenues dans l'URL,

 il faut construire un objet URLConnection en utilisant la
méthode : openConnection()
 Cette méthode crée (si elle n'existe pas déjà) un objet
permettant de créer une connexion vers la ressource
référée par l'URL en invoquant le bon gestionnaire de
protocole (HTTP par exemple). 33
 Web et URI
 API Java : java.net.URL
34
 Web et URI Lecture d’un
 API Java : java.net.URLConnection enregistrement
35
 Web et URI
 API Java : java.net.URLConnection
Entête d’un
message http
36
HTTP
 Hypertext Transfer Protocol
 Inventé par Tim Berners-Lee avec les
adresses Web et le langage HTML pour
créer le World Wide Web
 Protocole de transfert de plusieurs
formats de données : PC exécutant
Firefox
 Plaintext
 Hypertext
 Images,Video, Sound Server
 Meta-information exécutant
Apache
 Modèle client-serveur server
 Client : demande, reçoit, affiche les Mac exécutant

pages Web Chrome
 Serveur : envoie les réponses aux 37
requêtes
HTTP
 Liste de quelques serveurs HTTP
 C : Apache, Zeus Web Server, nginx, lighttpd, Cherokee,
Hiawatha Webserver
 ASP/ASP.Net(C#, VB.net) : IIS
 Java : Tomcat, Jetty, GlassFish, JBoss, JOnAS, Vert.x
 Python : Zope
 Pike : Caudium
 Ruby : WEBrick, Mongrel, Thin
 Erlang : Yaws
 Javascript : Node.js

38
HTTP
 Page web
 Une page web peut contenir plusieurs types d’information
 Des informations perçues
 Textuelles : texte avec mise en forme
 Non-textuelles : objets graphiques, audio, vidéo, applet,
 Interactives : hyperliens, forms, boutons, …
 Des informations cachées
 Commentaires, Méta-données; Script

 D’une façon abstraite, la plupart des pages web contiennent :
 Une page texte de base : style HTML adressée par une URL
 Objets référencés : images, vidéo, audio, …, adressés par
des URL
 Le navigateur demande d’abord la page de base. Ensuite les39
objets référencés par la page ou qu’ils soient
HTTP
 Historique
Plusieurs versions :
• HTTP/0.9
• HTTP/1.0
• HTTP/1.1
• HTTP/2 40
HTTP
 Principe Requête/Réponse
 Connexion TCP établie entre un client et le port 80 (en
général) du serveur HTTP
 Envoi par le client d'un message HTTP, dit requête
 Traitement de cette requête et envoi par le serveur d'un
message, dit réponse, au client.
 En HTTP 0.9 et 1.0, la connexion est fermée par le serveur
après chaque réponse
 En HTTP 1.1, il est possible de conserver la même
connexion TCP pour plusieurs échanges de
requêtes/réponses (persistance)
 En HTTP 2.0, le serveur peut envoyer des mises à jours
aux clients sans demandes (Server Push), orienté bit 41
HTTP
 En HTTP 2.0
 Negotiation mechanism that allows clients and servers to
elect to use HTTP 1.1, 2.0, or other non-HTTP protocols.
 Maintain high-level compatibility with HTTP 1.1 (for
example with methods, status codes, and URIs, and most
header fields)
 Decrease latency to improve page load speed in web
browsers by considering:
 Data compression of HTTP headers
 Server push technologies
 Pipelining of requests
 Fixing the head-of-line blocking problem in HTTP 1.x
 Multiplexing multiple requests over a single TCP 42
connection
HTTP
 En HTTP 2.0
 Support common existing use cases of HTTP, such as
desktop web browsers, mobile web browsers, web APIs,
web servers at various scales, proxy servers, reverse proxy
servers, firewalls, and content delivery networks
 HTTP/2 is a binary, rather than text, protocol, making it
more compact and efficient
43
HTTP
 Format des messages HTTP
 Des types de messages : requête
Ligne de requête GET /somedir/page.html HTTP/1.1

(methodes Host: www.someschool.edu
GET, POST, HEAD) Connection: close
User-agent: Mozilla/4.0
Lignes Accept: text/html, image/gif,image/jpeg
d’entête Accept-language:fr
Le retour chariot
indique la fin
du message
44
HTTP
 Format des messages HTTP
 Des types de messages : réponse
200 OK
 La requête a réussi et l’objet
Status de la demande demandé est à la suite
(protocol
301 Moved Permanently
status code HTTP/1.1 200 OK
status phrase) Connection: close  L’objet demandé a changé
Date: Thu, 06 Aug 1998 12:00:15 GMT définitivement de place, son

nouvel emplacement est donné
Server: Apache/1.3.0 (Unix) dans la suite du message
header Last-Modified: Mon, 22 Jun 1998 …...
lines Content-Length: 6821 400 Bad Request
Content-Type: text/html  La requête est erronée
data data data data data ... 404 Not Found

data, e.g.,
 Le document demandé n’est pas
requested disponible sur le serveur
HTML file
505 HTTP Version Not Supported
45
HTTP
 Format des Requêtes HTTP
 Constitution de la première ligne de requête
Message requête : ASCII (human-readable format)
46
HTTP
 Constitution de la première ligne de requête
 Méthode URL Version
Exemple: GET /index.html HTTP/1.1
Host: www.univ-mlv.fr
 Méthode: GET, HEAD, POST, PUT, DELETE, TRACE,...
Représente le type d'opération à effectuer

 URL: identifie la ressource recherchée
HTTP/1.1 exige que le champ « Host » soit spécifié

 Version: identifie la version du protocole utilisée
Si rien n'est spécifié, la version HTTP 0.9 est considérée
47
HTTP
 Exemple requête
 URLs can only be sent over the Internet using the ASCII character-set.
Outside the ASCII set, has to be converted into a valid ASCII format.
 URL encoding replaces unsafe ASCII characters with a "%" followed by
two hexadecimal digits.
 URLs cannot contain spaces. URL encoding normally replaces a space
with a plus (+) sign or with %20. 48
HTTP
 Format des Réponses HTTP
 Constitution de la réponse
49
HTTP
 Constitution de la ligne dite « de statut » : 5 catégories
 1xx « informatifs »: acceptés uniquement dans les
versions 1.1. Réponse « intermédiaire » du serveur.
Ex: 100 Continue
 2xx « de succès »: la réception, la compréhension ou
l'acceptation de la requête est réussie. Ex: 200 OK
 3xx « de redirection »: d'autres actions sont requises pour
traiter la requête. Ex: 301 Moved Permanently
 4xx « erreurs du client »: erreur de syntaxe ou de
spécification. Ex: 404 Not Found
 5xx « erreurs du serveur »: serveur incapable de
répondre. Ex: 501 Method Not Implemented
50
HTTP
 Exemple réponse
51
HTTP
 HTTP Headers
 Headers are name/value pairs that appear in both request
and response messages. The name of the header is separated
from the value by a single colon. For example, this line in a
request message:
 HTTP clients use headers in the request message to

identify themselves and control how content is returned.
 HTTP servers use headers in the response message to
specify how content is being returned and how it should
be handled.
52
HTTP
 HTTP Headers
 Spécifiques (requêtes/réponses) ou bien généraux:
 Server (réponse): informations sur le serveur HTTP
 Host (client): site web concerné par la requête (name
based virtual host, hôte virtuel basé sur le nom). C'est le
seul en-tête réellement important.
 User-Agent (client) : Indique le logiciel utilisé pour se
connecter.
 Date (général): estampille les messages HTTP
 Last-modified (serveur): date de dernière modification
 ETag (): identifiant de la ressource géré par le serveur
 Content-type (général): type MIME du corps du message
 Content-length (général): nombre d'octets du corps
53
HTTP
 HTTP Headers
 Spécifiques (requêtes/réponses) ou bien généraux:

 Connection: close; update, keep-alive
 Accept: text/plain (requête): ce qu'accepte le client
 Accept-charset, Accept-language, Accept-encoding,
Content-encoding, Transfert-encoding
 Referer (requête) : Indique l'URI du document qui a
donné un lien sur la ressource demandée.
 Expires (réponses) : Indique le moment après lequel la
ressource devrait être considérée obsolète ;
54
HTTP
 Headers
 Demandes
55
HTTP
 Headers
 Réponses
56
HTTP
 HTTP Pipelining
 HTTP pipelining is a technique in which multiple HTTP
requests are sent on a single TCP connection without
waiting for the corresponding responses.
 Non-idempotent methods like POST should not be pipelined. Sequences

of GET and HEAD requests can always be pipelined. A sequence of
other idempotent requests like PUT and DELETE can be pipelined or not
depending on whether requests in the sequence depend on the effect of
others. 57
HTTP
 HTTP Persistance ou « keep alive »
 Avant 1.1, champ Content-length pas obligatoire:
Comme le serveur fermait la connexion à la fin de la
réponse, ce champ servait simplement à vérifier que OK
 Avec la connexion persistante (keep alive)
 Serveur peut garder la connexion après la fin de réponse
 Plus efficace (délais d'ouverture et fermeture de
connexion)
 Possibilité d'exploiter le fullduplex de la connexion TCP
(plusieurs transactions peuvent se recouvrir)

 Toutes les réponses doivent contenir Content-length (sauf
réponses sans corps de message ou chunked)
 Indispensable pour déterminer la fin d'un message
58
HTTP
Non-persistante Persistante
 HTTP/1.0  Par défaut dans HTTP/1.1 et plus
 Le serveur interprète les requêtes,  Une seule connexion TCP est
répond et ferme la connexion TCP ouverte vers le serveur
 2 RTTs sont nécessaires pour lire  Le client envoie la requête de tous
chaque objet les objets requis dès qu’ils sont
réferencés dans le HTML
 Chaque transfert doit supporter le
slow-start  Moins de RTTs et moins de slow
start.
 Exemple : page contenant :
 Deux versions : avec/sans pipeline
 1 fichier HTML
 10 images JPEG
Mais la plupart des navigateurs de version 1.0 utilisent des

connexions parallèles 59
HTTP
Non-persistent Persistent
initiate TCP connection initiate TCP connection
RTT RTT
Request file
Request file
time to time to
RTT transmit RTT transmit
Base received file file
Base received
initiate TCP connection Request files
RTT RTT
Request file Object 1 received

Object 2 received
time to time to
RTT transmit transmit
Object 1 received file file
60
10 objects require 20RTT+10 data transmit times 10 objects require 3RTT+10 data transmit times
HTTP
 Messages avec chunked
 Lorsqu'une requête génère une réponse longue
 On devrait attendre toute la génération de la réponse afin de
connaître sa taille AVANT de créer l'entête de la réponse et
son champ Content-Length
 On peut alors « découper » la réponse en morceaux (chunked)
et commencer à envoyer les premiers avant d'avoir fini de
générer la totalité du document
 Utilise le champ Transfert-Encoding: chunked
 Il n'y a plus de champ d'entête Content-length
 Chaque morceau est préfixé par sa taille
 Le premier morceau de taille nulle indique la fin du corps
61
HTTP
 Messages avec chunked
GET /search?q=test HTTP/1.1
Host: www.google.fr
HTTP/1.1 200 OK
Server: GWS/2.0
Date: Mon, 23 Sep 2002 11:58:56 GMT
Transfer-Encoding: chunked
Content-Type: text/html
b3f
<html><head>
..... Premier morceau ...
3ce2
..... Deuxième morceau ...
</body></html>
62
0
HTTP
 Exemple de requêtes HTTP
63
HTTP
 Exemple de requêtes HTTP
64
HTTP
 Quelques Requêtes HTTP
 GET: récupérer une ressource (peut causer des side-effects)
 POST : transmettre des données en vue d'un traitement à
une ressource.
 HEAD: identique à GET, mais sans corps de msg
Peut servir à savoir si une ressource existe et si elle a
changé, sans nécessairement la récupérer
 TRACE: écho de la requête
le serveur renvoie, dans le corps du message, le message
qu'il a reçu du client (diagnostique)
 OPTIONS: demande d'information sur les méthodes
 Le serveur renvoie toutes les méthodes qu'il implante
dans le champ d'entête « Allow »
65
HTTP
 Formulaire avec GET
 Permet de définir des zones de saisie pour le client
 <form enctype="application/xwwwformurlencoded"
action="http://www.monsite.fr/path" method="GET">
<input type="text" name="user" value="votre nom">
<input type="submit" name="ok" value="Envoyer">
</form>
 Un clic sur Envoyer crée une requête GET à l'URL suivant:

http://www.monsite.fr/path?user=Toto &ok=Envoyer
66
HTTP
 Formulaire avec POST
<form action="http://www.monsite.fr/path" method="POST">
<input type="text" name="user" value="votre nom">
<input type="submit" name="ok" value="Envoyer">
</form>
 Même apparence dans un navigateur
Un clic sur Envoyer crée une requête POST à l'URL

http://www.monsite.fr/path,
 Avec comme champs d'entête
Host: www.monsite.fr
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
dont le corps du message contient user=votre+nom& ok=Envoyer
67
HTTP
 Formulaire avec POST
<form enctype="application/x-www-form-urlencoded" action="http://www.monsite.fr/path"
method="GET"> Zone de texte (nom) :
<input type="text" size="30" name="user" value="votre nom"><hr>
<textarea name="srctext" rows="6" cols="40">Tapez votre message ici. </textarea><hr>
Zone de boutons (age) : Quel âge avez vous?
moins de 18 ans <input type="radio" name="age" value="18">
de 19 à 35 ans <input type="radio" name="age" value="1935">
de 36 à 50 ans <input type="radio" name="age" value="3650" checked>
plus de 50 ans<input type="radio" name="age" value="50"><hr>
Zone de menu (disponibilité) : Vous êtes
<select name="dispo">
<option value="ok">disponible
<option selected value="ko">indisponible
</select><hr>
<input type="hidden" name="client" value="a12345678901">
<input type="submit" name="choix1" value="Accepter">
<input type="submit" name="choix2" value="Refuser">
68
<input type="reset" value="Réinitialiser"> <hr>
</form>
HTTP
 Envoyer des fichiers
<form enctype="multipart/formdata"
action="/sendfile" method="POST">
Fichier 1 : <input type="file"
name="fichier1" size="20"><br><br>
Fichier 2 : <input type="file"
name="fichier2" size="20"><br><br>
<input type="hidden" name="ID" value=« test">
<input type="submit" name="submit" value="Envoyer">
</form>
 Supposons que le fichier contienne le texte suivant:

 Test de fichier
 Alors la requête générée par un click sur Envoyer sera la
suivante 69
HTTP
POST /sendfile HTTP/1.1
Host: server
Content-Type: multipart/form-data; boundary=ABCDEF
Content-Length: 372
--ABCDEF
Content-Disposition: form-data; name="fichier1"; filename="test.txt"
Content-Type: text/plain
Test de fichier
--ABCDEF
Content-Disposition: form-data; name="fichier2"; filename=""
Content-Type: application/octet-stream
70
HTTP
--ABCDEF
Content-Disposition: form-data; name="ID"
Test
--ABCDEF
Content-Disposition: form-data; name="submit«
Envoyer
--ABCDEF--
71
HTTP
 GET vs POST
 Les deux méthodes sont utilisables dans un formulaire
 Différences principales
 POST transmet les données dans le corps
 GET transmet les données dans l'URL
 POST + Ésthétique (arguments n'apparaissent pas)
 POST non limité en taille (les serveurs limitent une taille
maximale pour les URLs). Dans ce cas, code de statut 414
Requested-URI Too Large
 Un formulaire GET peut être « rejoué » en conservant
l'URL (bookmarks du navigateur) : side-effect
72
HTTP
 Autres requêtes HTTP
 PUT permet d'envoyer au serveur HTTP des données
(fichiers) qu'il devra stocker
 Différent de POST, dont les données sont destinées à une
ressource identifiée par l'URL (qui doit normalement
interpréter les données)
 Dans le cas de PUT, les données sont la ressource à placer
à l'endroit spécifié par l'URL

 Mise à jour (200 OK) ou création (201 Created)
 DELETE permet de supprimer des données

 Requièrent le droit d'accès (authentification)
73
HTTP
 L’authentification HTTP
 De nombreux sites demandent un identifiant et un mot de
passe Pour limiter l'accès aux ressources à qq clients
 Mécanisme de challenge/crédit pour l'authentification
des requêtes
 Trois modes d'identification (RFC 2617) :
 Basic : transmet le mot de passe en clair, et ne doit donc
être utilisé qu'avec le protocole HTTPS.
 Digest : une identification sans transmettre le mot de
passe en clair. L'identification est cependant souvent
effectuée par une couche applicative supérieure à HTTP
(hashage).
 NTLM : This uses a secure challenge/response
mechanism that prevents password capture or replay 74
attacks over HTTP.
HTTP
75
HTTP
 Lors d'une requête sur une ressource protégée
 Serveur répond 401 Unauthorized avec, un champ WWW-
Authenticate qui contient au moins un challenge applicable
à la ressource concernée (une liste)
 Un challenge est constitué d'un schéma (mot, ex: Basic),
suivi de paires attribut=valeur.
 Exemple: Basic realm= "zoneprotection2"
realm: set of pages/resources where credentials are
required
 Le client doit alors réémettre sa requête avec un crédit dans
le champ Autorization.
 Exemple: Autorization: Basic blablabla
où blablabla représente le codage en base 64 de la chaîne76
«
login:passwd ». Attention, base 64 est réversible, et le
HTTP
 Schéma Basic
77
HTTP
 Autre schéma: Digest
 Requiert une valeur d'autorisation obtenue par hachage
cryptographique utilisant, en plus de user et passwd de
client, des informations liées à la requête et une valeur
aléatoire tirée par le serveur
78
HTTP
 Tracking Client
 HTTP protocole sans état. Comment savoir quelle était la
précédente requête du même client?
 Idée: faire « sauvegarder un état » par le client, qu'il devra
renvoyer dans la prochaine requête
 Champs « hidden » des formulaires
 Réécriture des URL des liens hypertextes contenus dans
les documents retournés. Exemple: <a

href="http://serveur/request_for_client_03728612">
Ne requiert aucune participation du client
 Cookies (plus simple pour le serveur)
 introduit par Netscape, puis RFC 2109

 Requiert la participation du client
79
HTTP
 HTTP Cookies
 Utilités des cookies
 Serveur nécessitant une authentification, sans demander
systématiquement un identifiant et un mot de passe
 Trace des préférences de l'utilisateur, par exemple pour
faire de la publicité ciblée

 Garder une trace des achats de l'utilisateur lors d'achats
en ligne
 Problème : utilisateurs nomades accédant à un même
site depuis différentes machines
 C'est une paire <clé>=<valeur>
 Initialement fournie par le serveur dans une réponse
 Stockée par le client (navigateur)
80
 Puis retransmise par le client lorsqu'il émet des requêtes
HTTP
 HTTP Cookies
Example:
Many major Web sites use
cookies  Susan always access
Internet always from PC
Four components:
1) cookie header line of  visits specific e-commerce
HTTP response message site for first time
2) cookie header line in  when initial HTTP requests
HTTP request message arrives at site, site creates:
3) cookie file kept on user’s  unique ID
host, managed by user’s  entry in backend
browser database for ID
4) back-end database at Web
site
81
HTTP
 HTTP Cookies
client server
ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response 1678 for user create
Set-cookie: 1678
ebay 8734 entry
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action backend
one week later: database
access
usual http request msg
cookie: 1678 cookie-
spectific
usual http response msg action 82
HTTP
 HTTP Cookies
 Spécifié par un champ d'entête dans la réponse
 Set-Cookie: <clé>=<valeur> [; expires=<DATE>]
[; path=<PATH>]
[; domain=<DOM>]
[; secure]
 Rejoué par les clients:
 Cookie: <clé1>=<valeur1>; <clé2>=<valeur2> ...
83
HTTP
 HTTP Cookies
 Attributs optionnels
 expires: pour la date de péremption. Au delà, le client ne
doit pas conserver le cookie
 domain et path servent à déterminer les URL pour lesquels
ce cookie doit être utilisé (par défaut, ceux de l'URL de la
requête sont utilisés)
 Les cookies s’appliquent sur le domain et sous-domain
 Les cookies dont la valeur de domain est différente du
domaine du serveur ayant généré la réponse doivent
être ignorés
 Les cookies trop larges (moins de deux « . ») ignorés
 secure: cookie à n'utiliser que si connexion sécurisée
 Si même path et même domain, le nouveau écrase l'ancien. 84
Si path diffère, on stocke et renvoie les deux
HTTP
 Java API for HTTP
 Transport abstraction :
Google HTTP Client Library for Java
 Low-level library
 java.net.HttpURLConnection,
 URL Fetch 85
 Apache HttpClient,
HTTP
 java.net.URL
 A simple way to get the contents of a page at a URL is to create
a java.net.URL object, then call its openStream() method. The
method handles the details of creating the connection, issuing
an HTTP GET request, and retrieving the response data.
86
HTTP
 java.net.URLConnection
 The abstract class URLConnection is the superclass of all
classes that represent a communications link between the
application and a URL. Instances of this class can be used both
to read from and to write to the resource referenced by the
URL. In general, creating a connection to a URL is a multistep
process:
1. The connection object is created by invoking the
openConnection method on a URL.
2. The setup parameters and general request properties are
manipulated.
3. The actual connection to the remote object is made, using
the connect method.
4. The remote object becomes available. The header fields
and the contents of the remote object can be accessed. 87
HTTP
 The setup parameters are modified using the following
methods:
 setDoInput
 setDoOutput
 setIfModifiedSince
 and the general request properties are modified using the

method
 setRequestProperty
88
HTTP
 The following methods are used to access the header fields
and the contents after the connection is made to the remote
object:
 getContent
 getHeaderField
 getInputStream
 getOutputStream
 Certain header fields are accessed frequently

 getContentEncoding
 getContentLength
 getContentType
 getDate 89
 getExpiration
HTTP
 HTTP/1.1
 Troisième version HTTP/1.1: En janvier 1997, puis juin 1999
puis en février 2014, devient finalement standard de l'IETF
 connexion persistante
 support du transfert en pipeline : plusieurs envois sur la même
connection
 une meilleure gestion du cache.
 en-tête Host devient obligatoire dans les requêtes.
 la négociation de type de contenu (format de données, langue) :
Accept, Accept-language.
Les soucis majeurs des deux premières versions
• le nombre important de connexions lors du chargement d'une page
complexe (contenant beaucoup d'images ou d'animations
• le temps d'ouverture d'une connexion entre client et serveur : pour
chaque nouvelle requête, l'établissement d'une connexion TCP prend
un temps triple de la latence entre client et serveur). 90
HTTP
 Historique
 Quatrième version HTTP/2 : En mars 2012, les travaux à propos
de HTTP/2.0 démarrent à l'IETF adoptant SPDY de goofle
(speedy) comme matériel de départ.
 approuvée en février 2015 par le groupe de pilotage de l'IETF..
91

Chap 3

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

Chap 3

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre : Services Applicatives

 Règles pour définir quand et

Transport SSH client

Adressage au niveau de la couche de transport : les ports

Dest IP: 74.125.115.99 8

Dest IP: 74.125.115.99

 Choix du protocole du transport

 Choix des ports

this is the attachment text

Ceci est un message encod=C3=A9 en UTF-8, puis transform=C3=A9

 Le texte orignal est codé en utilisant UTF-8 et le transfert se fera en

This is a multi-part message in MIME format.

This is the body of the message.

 application/octet-stream : flux de données arbitraire.

 application/ogg : Ogg, un flux de données multimedia,

conteneur ; RFC 3534.

 application/xhtml+xml : XHTML ; RFC 3236.

 application/json : JavaScript Object Notation ; RFC 4627.

 application/xml : eXtensible Markup Language ; RFC 3023.

 application/zip : fichier ZIP.

 Type text : texte lisible par un être humain ou code source

 text/csv : comma-separated values ; RFC 4180.

 text/html : HTML ; défini dans la RFC 2854.

 image/jpeg : JPEG image JFIF ; RFC 2045

 image/png : Portable Network Graphics

 image/tiff : Tagged Image File Format ; RFC 3302.

 image/vnd.microsoft.icon : icône ICO

 Type audio : audio.

 audio/x-ms-wma : Windows Media Audio

public class Test {

InputStream is = new BufferedInputStream(new FileInputStream(file));

 URI : Uniform Ressource Identifier (RFC 3986, 01/2005)

 URL : Uniform Resource Locator

 Pointe sur un document sur un serveur

 URN : Uniform Resource Name

ne suggère ni où, ni comment en obtenir une copie réelle.

 query : requête sous forme de clé=valeur séparée par &

 Si port n'est pas spécifié, port par défaut associé au schéma

 Très peu utilisée

 Pour accéder aux informations contenues dans l'URL,

 Client : demande, reçoit, affiche les Mac exécutant

 Serveur : envoie les réponses aux 37

 Commentaires, Méta-données; Script

Ligne de requête GET /somedir/page.html HTTP/1.1

Date: Thu, 06 Aug 1998 12:00:15 GMT définitivement de place, son

data data data data data ... 404 Not Found

Représente le type d'opération à effectuer

HTTP/1.1 exige que le champ « Host » soit spécifié

Si rien n'est spécifié, la version HTTP 0.9 est considérée

 HTTP clients use headers in the request message to

 Spécifiques (requêtes/réponses) ou bien généraux:

 Non-idempotent methods like POST should not be pipelined. Sequences

(plusieurs transactions peuvent se recouvrir)

Mais la plupart des navigateurs de version 1.0 utilisent des

initiate TCP connection initiate TCP connection

Request file Object 1 received

 Un clic sur Envoyer crée une requête GET à l'URL suivant:

 Supposons que le fichier contienne le texte suivant:

à l'endroit spécifié par l'URL

 DELETE permet de supprimer des données

les documents retournés. Exemple: <a

 introduit par Netscape, puis RFC 2109

faire de la publicité ciblée