La couche application
Marc Ibrahim
1
Plan
Concepts et architecture
WEB
DNS
Mail
DHCP
Autres
2
Couche application
❑ Application: c’est tout
software ou programme qui
fonctionne sur une machine
❑ Une application réseau est
destinée à être déployée sur
plusieurs hôtes, tout en
utilisant les réseaux pour la
communication et le transfert
des données.
❑ Les équipements
intermédiaires n’implémentent
pas des applications.
3
Couche application
❑ La localisation des applications réseaux au niveau
des hôtes (end-users) a favorisé le
développement rapide et la propagation d’une
multitude d’applications utiles.
❑ Une application réseau est un programme qui peut
être écrit en C, JAVA, etc.
▪ Ce programme doit savoir utiliser les services offerts
par le réseau pour communiquer
❑ Ex: e-mail, web, instant messaging, remote login,
P2P file sharing, multi-user network games,
streaming stored video clips
4
Couche application
❑ Dans TCP/IP on confond les trois couches 7, 6 et 5 du
modèle OSI
5
Architectures applicatives
❑ Une architecture applicative est conçue par le
développeur et dicte comment l’application est
struturée et distribuée sur les différents hôtes.
❑ NB: du point de vue de l’application, l’architecture
du réseau est unique et ne change pas.
❑ Trois grandes architectures applicatives:
▪ Client-serveur (client-server)
▪ Peer-to-peer (P2P)
▪ Mixte: client-serveur et P2P
6
Architecture
client-serveur
❑ Serveur:
▪ Hôte «toujours» en service pour
recevoir les requêtes des clients et
y répondre
▪ Adresse IP permanente et connue
des clients
▪ Data center: ensemble de machines
offrant un serveur virtuel (server
farms)
❑ Client:
▪ Communique avec le serveur
▪ Pas besoin de connectivité continue
▪ Peut ne pas avoir une adresse IP
fixe.
▪ Ne communique pas avec d’autres
clients.
❑ Flux upload/download: en général
download > upload
7
Architecture
client-serveur
❑ Les services basés sur l’architecture client-
serveur nécessitent une infrastruture qui va
être installée et maintenue par un opérateur
(infrastructure intensive).
❑ Ces services sont coûteux.
❑ Ex: WEB, moteurs de recherche (google, yahoo),
réseaux sociaux (facebook, MySpace), partage
de vidéo (Youtube), etc.
8
Architecture
P2P
❑ Pas de serveur en attente
❑ Tous les hôtes
implémentant l’application
communiquent
❑ Pas besoin d’une
connectivité continue ni
d’adresses IP fixes.
❑ Ex: distribution de
fichiers (bittorrent),
partage de fichiers
(eMule, LimeWire),
Internet telephony
(skype)
9
Architecture
mixte: P2P et client/serveur
❑ Souvent, pour les applications P2P, l’architecture
applicative est hybride.
▪ Existence d’un serveur principal pour le contrôle et la
gestion
❑ Ex: Skype
▪ Serveur centralisé: trouver l’adresse d’un destinataire.
▪ L’appel se fait entre les deux clients sans passer par le
serveur.
❑ Ex: instant messaging
▪ Serveur centralisé: détecte la présence des clients et
leur localisation
❑ Login du client au serveur
❑ Permet de trouver les adresses IP des amis
▪ Les messages sont échangés entre deux clients
sans passer par le serveur.
10
Architecture
Avantages et challenges du P2P
❑ Architecture extensible (self-scalable) mais
gestion difficile car distribuée.
❑ Challenges:
▪ Asymétrie des accès résidentiels: download >
upload. En P2P, les flux sont dans tous les sens.
❑ Le P2P doit être “ISP-friendly”.
▪ Sécurité.
11
Processus
❑ Un processus est un programme qui s’exécute sur
un ordinateur.
❑ L’application réseau se base sur des processus qui
communiquent via le réseau
❑ Un serveur n’est autre qu’un processus en
attente. Le client est un processus qui initie la
communication avec le serveur.
❑ Deamon: processus à l’écoute:
▪ Ex: httpd est le deamon de http, ftpd pour ftp
❑ On peut toujours parler, même en P2P, d’un
processus client et d’un processus serveur
12
Processus
❑ Un serveur n’est pas une machine. Une même
machine peut jouer les rôles de serveur et de
client selon l’application
❑ Dans les petites organisations, on peut dédier
une machine aux différents serveurs: mails,
web, transfert de fichier, etc.
❑ Dans les grandes entreprises, on peut avoir
plusieurs machines, chacune implémentant un
serveur donné
13
Processus
transport
❑ Le processus communicant doit passer ses
messages à la couche transport.
❑ Elle est responsable du contrôle de la livraison
des paquets
❑ Il y a plusieurs protocoles de transport qui
assurent différents services de livraison
▪ Ex: TCP, UDP, RTP
❑ Le choix du protocole de transport dépend de la
qualité de service requise par l’application
❑ Le transport est implémenté sur les terminaux
communicant.
14
Processus
Socket
❑ Pour communiquer
via le réseau, les
processus utilisent
une interface
logicielle appelée
socket.
❑ La programmation
socket permet au
programmeur
d’utiliser
facilement le
service de
transport.
15
Processus
Adressage
❑ Pour pouvoir envoyer un message à un processus, il faut pouvoir
l’identifier.
❑ Deux niveaux d’identification du processus:
▪ Identification de la machine sur laquelle le processus est exécuté:
adresse IP de la machine
❑ Ex: [Link]
▪ Identification du processus parmi d’autres sur la même machine: numéro
de port.
❑ Ex: 80 pour les serveurs WEB
❑ L’identificateur de port est utilisé par la couche transport pour
identifier l’application à laquelle il faut livrer les paquets
❑ Ex: [Link]:80
❑ Identificateur d’un communication unicast:
▪ Adresse IP source, Adresse IP destination, protocole de transport (TCP
ou UDP), numéro de port source, numéro de port destination.
❑ Test avec le browser
16
Processus
Adressage
❑ Un programme serveur doit avoir un numéro de port
fixe pour que tout le monde puisse y accéder
▪ Domain Name System (DNS) - TCP/UDP Port 53
▪ Hypertext Transfer Protocol (HTTP) - TCP Port 80
▪ Simple Mail Transfer Protocol (SMTP) - TCP Port 25
▪ Post Office Protocol (POP) - UDP Port 110
▪ Telnet - TCP Port 23
▪ Dynamic Host Configuration Protocol - UDP Ports 67 and 68
▪ File Transfer Protocol (FTP) - TCP Ports 20 and 21
17
Protocoles applicatifs
❑ C’est l’ensemble des règles qui définissent comment doivent
communiquer les processus d’une application réseau
❑ Le protocole dépend de l’application. Il est conçu pour répondre aux
besoins de l’application.
▪ le protocole du web (HTTP) est différent de celui du mail (SMTP)
❑ Un protocole définit:
▪ Types de messages échangé
❑ Ex: requête, réponse, …
▪ Syntaxe des messages:
❑ Les champs dont est formé un messages
▪ Sémantique des messages
❑ Siginification de l’information contenue dans les champs du message
▪ Règles d’échange des messages entre les processus
❑ Quand et comment envoyer les messages
❑ On distingue entre:
▪ les protocoles du domaine public qui sont définis dans les RFCs (Request
For Comment). Ex: HTTP, SMTP, FTP
▪ Les protocoles propriétaires. Ex: skype, applications P2P
18
Composantes d’une application
❑ Une application réseau est un ensemble de
composantes:
▪ Logiciels client et serveur avec interfaces graphiques ou non
▪ Des processus communicant
▪ Des protocoles
▪ Des données
❑ Ex: l’application mail comprend
▪ Des serveurs mail qui hébergent les boîtes des usagers
▪ Des logiciels de lecture de mail (ex: outlook)
▪ La structure des mails
▪ Le protocole SMTP qui définit comment les serveurs mails
s’échangent les messages, comment le mail est livré au client,
etc.
19
WEB
❑ WWW: World Wide Web. Prononcé (double-
you double-you double-you)
❑ «The World Wide Web is the only thing I
know of whose shortened form takes three
times longer to say than what it's short
for». Douglas Adams, The Independent on
Sunday, 1999
❑ Le Web n’est pas Internet:
▪ Internet est un réseau global de communication.
▪ Le Web est une application qui utilise Internet.
❑ Utilise le protocole HTTP (HyperText
Transfer Protocol)
20
WEB
Définition
❑ WWW: World Wide Web. Prononcé (double-you
double-you double-you)
❑ «The World Wide Web is the only thing I know
of whose shortened form takes three times
longer to say than what it's short for».
Douglas Adams, The Independent on Sunday,
1999
❑ Le Web n’est pas Internet:
▪ Internet est un réseau global de communication.
▪ Le Web est une application qui utilise Internet.
❑ WEB => architecture client-serveur
▪ Web server et web browser
❑ Utilise le protocole HTTP (HyperText Transfer
Protocol)
21
WEB
Ressources et URL
❑ Les ressources sont l’ensemble des données que
l’on peut manipuler dans le WEB. Elles peuvent
être du texte, de la vidéo, du multimédia etc.
❑ Les ressources Web sont disponibles sur les
serveurs Web à travers le monde.
❑ Une ressource est caractérisée par son URL
(Uniform Resource Locater ) RFC 3986.
❑ Un URL sert à identifier et à localiser une
ressource
22
WEB
Pages WEB
❑ Une page web est un ensemble de ressources
❑ Une page WEB est constituée d’un document
hypertexte (HTML) de base contenant du texte
et d’autres ressources.
❑ Un document hypertexte peut contenir des
hyperliens qui pointent vers d’autres documents
hypertexte ou d’autres ressources multimédia (on
parle d’hypermédia)
❑ Les documents hypertexte sont la ressource
principale du Web.
❑ HTML (HyperText Markup Language) est le
langage le plus utilisé pour écrire des documents
hypertextes (des pages Web)
23
WEB
Navigateur Web
❑ Le navigateur Web est un programme client qui
permet d’accéder aux ressources Web en y entrant
leurs URLs
❑ Le navigateur cherche le serveur contenant la
ressource, télécharge les données correspondantes et
les affichent.
▪ Pour les pages classiques, le navigateur télécharge le fichier
html correpondant.
❑ Les navigateurs savent interpréter plusieurs types de
ressources:
▪ Fondamentalement les documents HTML et texte
▪ D’autres format peuvent nécessiter des services ou
programmes souvent appelés: plug-ins ou add-ons
24
WEB
HTTP (RFC 2616)
❑ HyperText Transfer Protocol.
❑ HTTP suit le modèle client-
serveur. Explorer
Sous Windows
❑ Ce protocle permet à un client
de faire des requête à un
serveur Web pour obtenir des
ressources Web.
❑ HTTP manque de sécurité:
messages et données en clair.
▪ Solution: HTTPS. Navigateur
❑ Sites sécurisés: banques, mails, ... Sous MAX
25
WEB
HTTP
❑ Utilise le transport TCP:
▪ Le client initie une connexion TCP sur le port 80
▪ Le serveur accepte la connexion du client
▪ Les messages HTTP sont échangés.
▪ La connexion TCP est fermée.
❑ HTTP non-persistant:
▪ Un seul objet est transporté par connexion TCP
❑ HTTP persistant
▪ Plusieurs objets sont transportés par connexion TCP
❑ HTTP est sans mémoire (stateless):
▪ Le serveur ne mémorise pas les requêtes passées d’un
client. Il traite chaque requête d’une manière
indépendante
26
WEB
Requêtes HTTP
❑ Format d’une requêtes (ASCII)
▪ Request Line: type de requête
▪ Header lines: information générale comme la langue, la
version du navigateur, l’état de la connexion etc.
▪ Entity Body: information éventuelle envoyée par le client
27
WEB
Requêtes HTTP
❑ Exemple:
request line
(GET, POST, GET /somedir/[Link] HTTP/1.1
HEAD commands) Host: [Link]
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
Carriage return, (extra carriage return, line feed)
line feed
indicates end
of message
28
WEB
Requêtes HTTP
❑ Requêtes HTTP
▪ GET: demande une ressource
▪ POST: pour les formes où le client entre des
données
▪ HEAD: comme GET mais le serveur répond sans la
ressource
▪ PUT: pour l’upload
▪ DELETE: effacer une ressource sur le serveur
29
WEB
Réponses HTTP
status line
(protocol
status code HTTP/1.1 200 OK
status phrase) Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
header
Last-Modified: Mon, 22 Jun 1998 …...
lines
Content-Length: 6821
Content-Type: text/html
data, e.g., data data data data data ...
requested
HTML file
30
WEB
Réponses HTTP
200 OK
▪ request succeeded, requested object later in this message
301 Moved Permanently
▪ requested object moved, new location specified later in this
message (Location:)
400 Bad Request
▪ request message not understood by server
404 Not Found
▪ requested document not found on this server
505 HTTP Version Not Supported
31
WEB
Serveur proxy, WEB caching
❑ Un serveur mandataire, ou proxy server, qui
relaie les requêtes des clients vers les
serveurs web. origin
server
Proxy
server
client
client
origin
server
32
WEB
Serveur proxy, WEB caching
❑ Fonctions du proxy:
▪ Plus de contrôle et de sécurité
▪ Filtrage
▪ Web caching
❑ Le web caching permet de stocker les
ressources web déjà téléchargées.
▪ Les clients pourront y accéder plus rapidement
après
▪ Diminue la quantité de trafic sur l’accès à Internet.
33
WEB
test HTTP
❑ Test:
▪ telnet [Link] 80
▪ GET / HTTP/1.1
▪ host: [Link]
34
DNS
❑ Domain Name System: système responsable
de la gestion des noms dans Internet
❑ Association: nom <-> adresse IP
35
DNS
❑ Noms plus faciles à mémoriser que les
adresses.
▪ Utiliser un nom au lieu de l’adresse IP.
❑ Problème: comment stocker les
correspondances noms-adresses
❑ Solution directe: fournir le fichier
correspondant à chaque machine sur le réseau
▪ Nombre énorme
▪ La moindre modification entraîne la mise à jour
dans toutes les machines
36
DNS
solution centralisée
❑ Solution centralisée: un seul serveur contient
toute la base de données
❑ Problème
▪ Point of Failure
▪ Le serveur doit supporter un volume de requêtes
énorme
▪ Distance variable des différents usages
▪ Maintenance et mise à jour continuelle
❑ Conclusion: solution non extensible (non
scalable)
37
DNS
solution distribuée
❑ Problème semblable: numéros téléphoniques
▪ solution: indexage hiérarchique.
❑ Un ensemble de serveurs vont fournir le service de résolution (traduction).
❑ DNS:
▪ Base de données distribuée et hiérarchique composée d’une hiérarchie de serveurs
▪ Protocole pour faire des requêtes à cette base de données.
❑ Chaque serveur d’un niveau possède les adresses des serveurs “en-
dessous”
▪ Root DNS servers
▪ TLD servers (Top Level Domain)
▪ Authoritative servers
Root DNS Servers
Top level domain servers
com DNS servers org DNS servers edu DNS servers
Authoritative servers
[Link] [Link] [Link]
[Link] [Link]
DNS servers DNS serversDNS servers
DNS servers DNS servers
38
DNS
Hiérarchie de serveurs
❑ 13 serveurs racine dans le monde
▪ Un serveur est en fait un ensemble de serveur redondants.
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD k RIPE London (also 16 other locations)
g US DoD Vienna, VA
h ARL Aberdeen, MD i Autonomica, Stockholm (plus
j Verisign, ( 21 locations) 28 other locations)
e NASA Mt View, CA m WIDE Tokyo (also Seoul,
f Internet Software C. Palo Alto, Paris, SF)
CA (and 36 other locations)
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
❑ TLD servers: responsables des top-domains comme com,
org, edu, et les domaines de pays, lb, fr, uk, etc.
❑ Authoritative server: chaque organisation doit disposer
d’un serveur à autorité pour offrir publiquement les
entrées correspondant aux hôtes de cette organisation
39
DNS: Base de données distribuée et
hiérarchique.
40
DNS
fonctionnement
❑ Le client souhaitant avoir l’adresse IP d’un nom de
domaine fait une requête DNS à son serveur DNS
local
❑ Celui va interroger l’hiérarchie (aussi via le protocole
DNS) pour avoir une réponse
❑ La réponse est alors renvoyée au client
❑ Caching: pour éviter de faire la même requête
plusieurs fois, les serveurs et les clients stockent les
résultats provisoirement.
❑ Deamon: named
❑ Le serveur DNS stocke les informations sous forme
d’entrées (record) contenant: nom, adresse et type
d’entrée.
41
DNS
Types de requêtes iterated query:
root DNS server
recursive query:
root DNS server
2
2 3 3
TLD DNS server
6 4
7
TLD DNS 5
server
local DNS server
local DNS server [Link]
[Link] 5 4
7 6
1 8
1 8
authoritative DNS server
authoritative DNS server
[Link]
[Link]
requesting host requesting host
[Link] [Link]
[Link] [Link]
42
DNS
Entrées
DNS: Resoure Record (RR)
RR format: (name, value, type, ttl)
Type=A Type=CNAME
❖ name is hostname ❖ name is alias name for some
❖ value is IP address “canonical” (the real) name
[Link] is really
❑ Type=NS [Link]
❖ value is canonical name
▪ name is domain (e.g.
[Link])
▪ value is hostname of Type=MX
authoritative name ❖ value is name of mailserver
server for this domain associated with name
43
DNS
protocole et messages
Les requêtes et les réponses ont le même format de
message
identification: 16 bit pour
identifier la requête et la
réponse correspondante
flags:
❖ query or reply
❖ recursion desired
❖ recursion available
❖ reply is authoritative
44
Mail
Architecture
❑ Trois composantes:
▪ Mail user Agents
▪ Mail servers
▪ Protocole de transfert de
mail: SMTP
❑ Mail User Agent (MUA)
ou client e-mail:
▪ interface qu’utilise le
client pour écrire, envoyer
et recevoir des mails.
▪ Ex: Outlook, Mozilla
Thunderbird
45
Mail
Architecture
❑ Mail server ou MTA(mail transfer
agent):
▪ le coeur du système
▪ Mailbox: contient les messages entrant
(incoming) des clients
▪ Queue des messages sortant
(Outgoing)
❑ SMTP (Simple Mail Transfer
Protocol) entre les serveurs:
▪ Client: le MUA ou le serveur qui envoie
le mail
▪ Serveur: le serveur qui recoit le mail
❑ Pour recevoir un mail de sa boîte,
plusieurs protocoles d’accès peuvent
être utilisés:
▪ POP (Post Office Protocol)
▪ IMAP (Internet Message Access
Protocol)
▪ WEB-based
46
Mail
Architecture
47
Mail
SMTP (RFC 5321)
❑ SMTP utilise TCP pour un transfert fiable
▪ Port 25
❑ Trois phase de transfert:
▪ Handshake (greeting)
▪ Transfert du message
▪ Clôture
❑ Intéraction de type Commande/réponse
▪ Commandes: texte ASCII
▪ Réponses: code et phrase
❑ Messages en codage ASCII 7 bits
❑ SMTP = push vs. HTTP = pull
48
Mail
SMTP. Echange
S: 220 [Link]
C: HELO [Link]
S: 250 Hello [Link], pleased to meet you
C: MAIL FROM: <alice@[Link]>
S: 250 alice@[Link]... Sender ok
C: RCPT TO: <bob@[Link]>
S: 250 bob@[Link] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by
itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 [Link] closing connection
49
Mail
Format d’un mail
RFC 822: standard pour les
formats des mails. header
blank
❑ header lines, e.g.,
line
▪ To:
▪ From:
▪ Subject: body
❑ body
▪ Le contenu ASCII du mail.
50
Mail
Protocole d’accès
❑ POP: Post Office Protocol [RFC 1939]
▪ authorisation (agent <-->server) et download
▪ TCP : port 110
❑ IMAP: Internet Mail Access Protocol [RFC
1730]
▪ Plus d’options (plus complexe)
▪ manipulation des messages sur le serveur.
❑ HTTP: gmail, Hotmail, Yahoo! Mail, etc.
51
Mail
POP3S: +OK POP3 server ready
C: user bob
phase d’authorisation S: +OK
C: pass hungry
❑ Commandes clients: S: +OK user successfully logged on
▪ user: username C: list
▪ pass: password S: 1 498
❑ Réponses du serveur S: 2 912
▪ +OK S: .
C: retr 1
▪ -ERR S: <message 1 contents>
Phase de transaction, client: S: .
❑ list: lister les numéros de C: dele 1
C: retr 2
messages
S: <message 1 contents>
❑ retr: récupérer un message S: .
❑ dele: delete C: dele 2
❑ quit C: quit
S: +OK POP3 server signing off
52
FTP
❑ File Transfer Protocol. Permet d’échanger des fichier
avec un serveur.
❑ Deamon: ftpd
❑ Deux connexions: une pour le contrôle (port 21) et
l’autre pour les données échangées. (port 20)
53
DHCP
Comment obtenir une adresse IP
❑ Dans un réseau, tout équipement doit avoir une adresse IP, mais
aussi il doit connaître l’adresse IP de sa passerelle (gateway), de
son serveur DNS local etc.
❑ Cette configuration peut être manuelle:
▪ Windows: control-panel->network->configuration->tcp/ip-
>properties
▪ UBUNTU: /etc/network/interfaces
❑ Configuration automatique: DHCP: Dynamic Host Configuration
Protocol:
▪ Le terminal utilise le protocole DHCP pour obtenir
dynamiquement la configuration à partir d’un serveur DHCP
❑ Dans un réseau, les équipements intermédaires, les
serveurs, les imprimantes, etc. sont statiquement
configurées.
❑ DHCP est utilisé pour les clients et les visiteurs.
54
DHCP
❑ Facilite la configuration des réseaux
❑ Les données sont temporaires (lease)
❑ Les adresses IP peuvent être réutilisées dans le
même réseau
❑ “plug-and-play”
▪ C’est ce qui vous permet de vous connecter directement à un
hotspot sans configuration manuelle
❑ Aussi chez votre ISP.
❑ Utilise le transport UDP
55
DHCP
❑ Scénario
A DHCP [Link]
[Link]
server
[Link]
[Link] [Link]
B
[Link] Terminal qui arrive et qui
[Link] [Link] E Doit contacter le serveur
DHCP pour prendre
[Link] [Link]
Une configuration
dynamqiue
56
DHCP
DHCP server: [Link] arriving
DHCP discover
client
src : [Link], 68
dest.: [Link],67
yiaddr: [Link]
transaction ID: 654
DHCP offer
src: [Link], 67
dest: [Link], 68
yiaddrr: [Link]
transaction ID: 654
Lifetime: 3600 secs
DHCP request
src: [Link], 68
dest:: [Link], 67
yiaddrr: [Link]
transaction ID: 655
time Lifetime: 3600 secs
DHCP ACK
src: [Link], 67
dest: [Link], 68
yiaddrr: [Link]
transaction ID: 655
Lifetime: 3600 secs
57
SMB
❑ Server Message Block
❑ Partage de fichiers et répertoires,
d’imprimantes, ...
❑ Connection à long terme. Le client accède aux
ressources comme si c’était chez lui
❑ SAMBA: partage entre LINUX et WINDOWS
58
Telnet
❑ Accès à distance à une machine.
❑ Emulation de terminal texte. On a accès à la la ligne
de commande du serveur
❑ Quand accède au serveur via Telnet, on dit qu’on a
établit une session virtuelle (Virutal Terminal Session
- VTY).
❑ Telnet est est le nom du:
▪ protocole lui-même
▪ client
▪ Serveur
❑ Serveur: Telnet deamon
❑ Telnet n’est pas sécurisé. Utiliser ssh
59