48
1: Introduction 1 Applications et protocole applicat if Application: communiquant, processus distribués S’exécutent dans les hôtes dans l’ « espace utilisateurs » Échangent des messages pour implanter des applis e.g., email, transfert de fichier, le Web Protocoles applicatifs Définissent les messages échangés entre les applis et les actions Certains services sont par proposés par les protocoles de couches inférieures applicat ion transpor t network data link physical applicat ion transpor t network data link physical applicat ion transpor t network data link physical

Applications et protocole applicat if

Embed Size (px)

DESCRIPTION

Application: communiquant , process u s distribués S’exécutent dans les hôtes dans l’ « espace utilisateurs » É change nt des messages pour implanter des app lis e.g., email, transfert de fichier , le Web P rotocol e s applicatifs - PowerPoint PPT Presentation

Citation preview

1: Introduction 1

Applications et protocole applicatif

Application: communiquant, processus distribués S’exécutent dans les hôtes

dans l’ « espace utilisateurs »

Échangent des messages pour implanter des applis

e.g., email, transfert de fichier, le Web

Protocoles applicatifs Définissent les messages

échangés entre les applis et les actions

Certains services sont par proposés par les protocoles de couches inférieures

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

1: Introduction 2

Applications réseaux : le jargon

Un processus est un programme qui s’éxécute sur un hôte

Deux processus communiquent dans un même hôtes avec des communication interprocessus defini par le système d’exploitation

Deux processus s’éxécutant sur deux hôtes communiquent avec un protocole de couche application

Un agent utilisateur est une interface entre l’utilisateur et l’application réseau Web:browser E-mail: eudora,

outlook streaming

audio/video: real player, media player

1: Introduction 3

Paradigme client-serveur

Les réseaux typiques ont deux parties : le client et le serveur

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

Client: Initie le contact avec le

serveur (“parle en premier”) Typiquement demande un

service du serveur Pour le Web, le client est

implanté dans le browser; pour le e-mail dans le lecteur de mail

Serveur: Propose les services

demandés par le client e.g., Le Web serveur envoi

les pages Web demandés l

request

reply

1: Introduction 4

Protocole applicatif

API: Application Programming Interface

Défini l’interface entre l’application et la couche transport

socket: API Internet Deux processus

communiquent en émettant et recevant des données via les sockets

Q: Comment un processus « identifie » un processus distant pour communiquer Adresse IP de l’hôte

distant “Numéro de port” –

permet de différencier les différents processus locaux auquel le message doit être transmis

1: Introduction 5

Quel est le service de transport nécessaire à une application?Pertes de données Certaines applis (e.g.,

audio) peuvent tolérer des pertes

D’autres applis (e.g., ftp, telnet) nécessitent une fiabilité à 100%

Timing Certaines applis (e.g.,

voix sur IP, jeux interactifs) nécessite un délai faible

Bande passante Certaines applis (e.g.,

multimedia) requiert une bande passante minimale

D’autre applis (“applis elastique”) utilisent la bande passante disponible

1: Introduction 6

Besoin en service de transport

Application

Transfer de fichiere-mail

WebAudio/video Temps/réel

Audio/video enregistréJeux interactifs

Applis financiére

Pertes

Sans pertesSans pertes toléranttolérant

toléranttolérantSans pertes

Bande passante

elastiqueelastiqueelastiqueaudio: 5Kb-1Mbvideo:10Kb-5Mbsimilaire Quelques kbpselastique

Sensibilité temp.

NonNonNonoui, 100’s msec

oui, quelques secsoui, 100’s msecOui et non

1: Introduction 7

Services proposés dans Internet

Service TCP: Orienté connexion:

connexion nécessaire entre le client et le serveur

Transport fiable entre le processus émetteur et récepteur

Contrôle de flot: l’émetteur ne submerge pas le récepteur

Contrôle de Congestion : réduit le débit de l’émetteur quand le réseau et congestionné

Ne propose pas: de garanties de délai ou de bande passante minimale

Service UDP: Transfert de

données non fiable Ne propose pas de

connexion, de fiabilité, de contrôle de flot, de contrôle de congestion, de garantie temporel ou de bande passante

1: Introduction 8

Applis Internet: protocols applicatif et transport

Application

e-mailAccès distant

Web Transfert de fichier

streaming multimedia

Fichier distantVoix sur IP

Protocol applicatif

smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]proprietaire(e.g. RealNetworks)NSFproprietaire(e.g., Vocaltec)

Protocole de transport

TCPTCPTCPTCPTCP or UDP

TCP or UDPtypically UDP

1: Introduction 9

Le Web: jargon

Page Web: Contient des “objects” Adressé par une URL

La plupart des pages Web pages contiennent : Page HTML de base Objets référencé

L’URL a deux composants: nom d’hôte et chemin d’accès

L’Agent Utilisateur pour le Web est le browser: MS Internet Explorer Netscape

Communicator

Le serveur Web: Apache (domaine

public) MS Internet

Information Server

www.someSchool.edu/someDept/pic.gif

1: Introduction 10

Le Web: le protocole HTTP

HTTP: hypertext transfer protocol

Couche applicative Web Modèle client/serveur

client: browser qui demande, reçoit, affiche les objets Web

serveur: serveur Web envoit les réponses aux requêtes

http1.0: RFC 1945 http1.1: RFC 2068

PC exécutantExplorer

Server exécutant

Apacheserver

Mac exécutantNetscape

http request

http re

quest

http response

http re

sponse

1: Introduction 11

Le protocole HTTP

HTTP: service de transport TCP :

Le client initie un connexion TCP (crée une socket) au serveur, port 80

Le serveur accepte la connexionTCP du client

Les messages HTTP (protocole applicatif) sont échangés entre le browser (client HTTP) et le serveur Web

La connexion TCP est close

HTTP est « sans état » Le serveur ne maintient

aucunes informations au sujets des requêtes précédentes des clients

Les protocoles gardant un “état” sont complexe!

L’histoire passée doit être gardée

Si le serveur ou le client se crashe les états peuvent être inconsistent

1: Introduction 12

Exemple HTTPSi un utilisateur entre l’URL www.someSchool.edu/someDepartment/home.index

1a. Le client HTTP initie une connexion TCP au serveur HTTP sur le site www.someSchool.edu. Le port 80 est choisi par défaut

2. Le client HTTP envoit les requêtes HTTP (contenant des URLs) par les sockets TCP

1b. Le serveur HTTP du site www.someSchool.edu attend une connexion TCP sur le port 80. “accepte” la connexion, et l’annonce au client

3. Le serveur HTTP reçoit le message de requêtes, génére les messages de réponse contenant l’objet requis (someDepartment/home.index), et l’envoie sur une socket

time

1: Introduction 13

http example (cont.)

5. Le client HTTP reçoit la réponse contenant le fichier HTML file, l’affiche. En décodant le fichier le browser trouve les URLs référés

6. Les étapes 1-5 sont répétés pour chaque URLs référencés

4. Le serveur HTTP ferme la connexion TCP

time

1: Introduction 14

Connexions Persistantes et Non-persistantesNon-persistante HTTP/1.0 Le serveur interprète

les requêtes, répond et ferme la connexion TCP

2 RTTs sont nécessaire pour lire chaque objet

Chaque transfert doit supporter le slow-start

Persistante Par défaut dans HTTP/1.1 Une seule connexion TCP

est ouverte vers le serveur

Le client envoit la requête de tout les objets requis dès qu’ils sont réferenciés dans le HTML

Moins de RTTs et moins de slow start.

Mais la plupart des navigateurs de version 1.0 utilisent des connexions parallèle

1: Introduction 15

Format de message http : requête Deux types de messages http : requête,

réponse message de requête http :

ASCII

GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr

Ligne de requête(commandes

GET, POST, HEAD)

Lignesd’entête

Le retour chariot, indique la fin du message

1: Introduction 16

Format de message http : requête

1: Introduction 17

Format de message http : réponse

HTTP/1.0 200 OK Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ...

Ligne de status(protocole

Code de status Etat)

Lignesd’entêtes

données, e.g., Le fichier

html

1: Introduction 18

Code de réponse HTTP

200 OK La requête a réussi et l’objet demandé est à la suite

301 Moved Permanently L’objet demandé a changé définitivement de place,

son nouvel emplacement est donné dans la suite du message

400 Bad Request La requête est erronée

404 Not Found Le document demandé n’est pas disponible sur le

serveur

505 HTTP Version Not Supported

Dans la première ligne de la réponse serveur->client.

1: Introduction 19

Essayer le serveur http

1. Telnet à votre serveur web favori

Ouvre une connexion TCP vers le port 80 de www.eurecom.fr.

telnet www.eurecom.fr 80

2. Taper une requête HTTP

GET /~ross/index.html HTTP/1.0

1: Introduction 20

Interaction entre le client et le serveur : cookies

Le serveur envoit un “cookie” vers le client dans la reponseSet-cookie: 1678453

Le client presente le cookie dans les requêtes suivantes cookie: 1678453

Le serveur vérifie le cookie avec ces informations enregistrées authentification Rappel des

préférences utilisateur

client server

requête http

Réponse http +Set-cookie: #

requête http+cookie: #

Réponse http

Opération Spécifiqueau cookie

1: Introduction 21

GET conditionel

Objectif : ne pas envoyer un objet que le clien a déjà dans son cache

client: specifie la date de la copie cachée dans la requête httpIf-modified-since:

<date> serveur: la réponse est

vide si la copie cachée est à jour HTTP/1.0 304 Not Modified

client server

Requête httpIf-modified-since:

<date>

Réponse http HTTP/1.0

304 Not Modified

object Non

modifié

Requête httpIf-modified-since:

<date>

Réponse http HTTP/1.1 200 OK

<data>

objet modifié

1: Introduction 22

Caches Web

L’utilisateur pointe son navigateur vers le cache :

Le client envoit toutes ses requête http vers le cache web Si l’objet est dans le

cache, on le retourne Sinon on demande

au serveur initial et on répond ensuite à la requête

Goal: satisfaire la requête du client sans utiliser le serveur initial

client

Proxyserver

client

http request

http re

quest

http response

http re

sponse

http re

quest

http re

sponse

http requesthttp response

origin server

origin server

1: Introduction 23

Pourquoi le Cache Web?

Hypothèse: le cache est proche du client

Réduction du temps de réponse

Réduction du débit vers les serveurs distant

originservers

public Internet

institutionalnetwork 10 Mbps LAN

1.5 Mbps access link

institutionalcache

1: Introduction 24

DNS: Domain Name System

Gens: plusieurs identifiant: NSS, name, # Passeport

Hôte, routeurs: Adresse IP (32 bit) “nom”, e.g.,

gaia.cs.umass.edu

Q: Comment lier les adresses et les noms ?

Domain Name System: Base de données

distribuées implantér dans plusieurs serveurs de nom hiérarchique

Protocole applicatif hote, routeurs, serveurs

de nom communique pour résoudre un nom

La complexité est repoussé à la bordure du réseau

1: Introduction 25

DNS name servers

Aucun serveur n’a tout les relations nom-vers-@IP

serveurs de noms local: Chaque ISP, entreprise a

son propre (default) name server

Les requêtes DNS vont en premier au serveur de nom local

authoritative name server: for a host: stores that host’s

IP address, name can perform name/address

translation for that host’s name

Pourquoi pas de DNS centralisé?

Tolérance aux pannes single point of failure

Volume de trafic maintenance

Ne passe pas à l’échelle !

1: Introduction 26

DNS: Root name servers

contacted by local name server that can not resolve name

root name server: contacts

authoritative name server if name mapping not known

gets mapping returns mapping to

local name server ~ dozen root name

servers worldwide

1: Introduction 27

Simple DNS example

host surf.eurecom.fr wants IP address of gaia.cs.umass.edu

1. Contacts its local DNS server, dns.eurecom.fr

2. dns.eurecom.fr contacts root name server, if necessary

3. root name server contacts authoritative name server, dns.umass.edu, if necessary

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

authorititive name serverdns.umass.edu

local name serverdns.eurecom.fr

1

23

4

5

6

1: Introduction 28

DNS example

Root name server: may not know

authoratiative name server

may know intermediate name server: who to contact to find authoritative name server

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

local name serverdns.eurecom.fr

1

23

4 5

6

authoritative name serverdns.cs.umass.edu

intermediate name serverdns.umass.edu

7

8

1: Introduction 29

DNS: iterated queries

recursive query: puts burden of

name resolution on contacted name server

heavy load?

iterated query: contacted server

replies with name of server to contact

“I don’t know this name, but ask this server”

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

local name serverdns.eurecom.fr

1

23

4

5 6

authoritative name serverdns.cs.umass.edu

intermediate name serverdns.umass.edu

7

8

iterated query

1: Introduction 30

DNS: caching and updating records once (any) name server learns mapping, it

caches mapping cache entries timeout (disappear) after

some time update/notify mechanisms under design by

IETF RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html

1: Introduction 31

DNS records

DNS: distributed db storing resource records (RR)

Type=NS name is domain (e.g.

foo.com) value is IP address of

authoritative name server for this domain

RR format: (name, value, type,ttl)

Type=A name is hostname value is IP address

Type=CNAME name is an alias name

for some “cannonical” (the real) name

value is cannonical name

Type=MX value is hostname of

mailserver associated with name

1: Introduction 32

DNS protocol, messagesDNS protocol : query and reply messages, both with same message format

msg header identification: 16 bit #

for query, repy to query uses same #

flags: query or reply recursion desired recursion available reply is authoritative

1: Introduction 33

DNS protocol, messages

Name, type fields for a query

RRs in reponseto query

records forauthoritative servers

additional “helpful”info that may be used

1: Introduction 34

Socket programming

Socket API introduced in BSD4.1

UNIX, 1981 explicitly created, used,

released by apps client/server paradigm two types of transport

service via socket API: unreliable datagram reliable, byte stream-

oriented

a host-local, application-created/own

ed, OS-controlled interface (a “door”) into which

application process can both send and

receive messages to/from another (remote

or local) application

process

socket

Goal: learn how to build client/server application that communicate using sockets

1: Introduction 35

Socket-programming using TCP

Socket: a door between application process and end-end-transport protocol (UCP or TCP)

TCP service: reliable transfer of bytes from one process to another

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperating

system

host orserver

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperatingsystem

host orserver

internet

1: Introduction 36

Socket programming with TCP

Client must contact server server process must first

be running server must have

created socket (door) that welcomes client’s contact

Client contacts server by: creating client-local TCP

socket specifying IP address,

port number of server process

When client creates socket: client TCP establishes connection to server TCP

When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with

multiple clients

TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server

application viewpoint

1: Introduction 37

Socket programming with TCP

Example client-server app: client reads line from

standard input (inFromUser stream) , sends to server via socket (outToServer stream)

server reads line from socket

server converts line to uppercase, sends back to client

client reads, prints modified line from socket (inFromServer stream)

Input stream: sequence of bytes into process

Output stream: sequence of bytes out of process

client socket

inFromUser outToServer

iinFromServer

1: Introduction 38

Client/server socket interaction: TCP

wait for incomingconnection requestconnectionSocket =welcomeSocket.accept()

create socket,port=x, forincoming request:welcomeSocket =

ServerSocket()

create socket,connect to hostid, port=xclientSocket =

Socket()

closeconnectionSocket

read reply fromclientSocket

closeclientSocket

Server (running on hostid) Client

send request usingclientSocketread request from

connectionSocket

write reply toconnectionSocket

TCP connection setup

1: Introduction 39

Example: Java client (TCP)

import java.io.*; import java.net.*; class TCPClient {

public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence;

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));

Socket clientSocket = new Socket("hostname", 6789);

DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());

Createinput stream

Create client socket,

connect to server

Createoutput stream

attached to socket

1: Introduction 40

Example: Java client (TCP), cont.

BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + '\n');

modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close(); } }

Createinput stream

attached to socket

Send lineto server

Read linefrom server

1: Introduction 41

Example: Java server (TCP)import java.io.*; import java.net.*;

class TCPServer {

public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence;

ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept();

BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));

Createwelcoming socket

at port 6789

Wait, on welcomingsocket for contact

by client

Create inputstream, attached

to socket

1: Introduction 42

Example: Java server (TCP), cont

DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + '\n';

outToClient.writeBytes(capitalizedSentence); } } }

Read in linefrom socket

Create outputstream,

attached to socket

Write out lineto socket

End of while loop,loop back and wait foranother client connection

1: Introduction 43

Socket programming with UDP

UDP: no “connection” between client and server

no handshaking sender explicitly attaches

IP address and port of destination

server must extract IP address, port of sender from received datagram

UDP: transmitted data may be received out of order, or lost

application viewpoint

UDP provides unreliable transfer of groups of bytes (“datagrams”)

between client and server

1: Introduction 44

Client/server socket interaction: UDP

closeclientSocket

Server (running on hostid)

read reply fromclientSocket

create socket,clientSocket = DatagramSocket()

Client

Create, address (hostid, port=x,send datagram request using clientSocket

create socket,port=x, forincoming request:serverSocket = DatagramSocket()

read request fromserverSocket

write reply toserverSocketspecifying clienthost address,port umber

1: Introduction 45

Example: Java client (UDP)

import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine();

sendData = sentence.getBytes();

Createinput stream

Create client socket

Translate hostname to IP

address using DNS

1: Introduction 46

Example: Java client (UDP), cont.

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); }

}

Create datagram with data-to-send,

length, IP addr, port

Send datagramto server

Read datagramfrom server

1: Introduction 47

Example: Java server (UDP)

import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

serverSocket.receive(receivePacket);

Createdatagram socket

at port 9876

Create space forreceived datagram

Receivedatagra

m

1: Introduction 48

Example: Java server (UDP), cont

String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } }

}

Get IP addrport #, of

sender

Write out datagramto socket

End of while loop,loop back and wait foranother datagram

Create datagramto send to client