1 / 48

Applications et protocole applicat if

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

mackenzie-gibbs
Download Presentation

Applications et protocole applicat if

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 transport network data link physical application transport network data link physical application transport network data link physical Applications et protocole applicatif 1: Introduction

  2. Unprocessusest un programme qui s’éxécute sur un hôte Deux processus communiquent dans un même hôtes avec des communicationinterprocessus 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 utilisateurest une interface entre l’utilisateur et l’application réseau Web:browser E-mail: eudora, outlook streaming audio/video: real player, media player Applications réseaux : le jargon 1: Introduction

  3. Les réseaux typiques ont deux parties : le clientet leserveur request reply application transport network data link physical application transport network data link physical Paradigme client-serveur 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 1: Introduction

  4. 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 Protocole applicatif 1: Introduction

  5. 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 Quel est le service de transport nécessaire à une application? 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 Sensibilité temp. Non Non Non oui, 100’s msec oui, quelques secs oui, 100’s msec Oui et non Application Transfer de fichier e-mail Web Audio/video Temps/réel Audio/video enregistré Jeux interactifs Applis financiére Pertes Sans pertes Sans pertes tolérant tolérant tolérant tolérant Sans pertes Bande passante elastique elastique elastique audio: 5Kb-1Mb video:10Kb-5Mb similaire Quelques kbps elastique 1: Introduction

  7. Service TCP: Orienté connexion:connexion nécessaire entre le client etle 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 Services proposés dans Internet 1: Introduction

  8. Applis Internet: protocols applicatif et transport Protocol applicatif smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietaire (e.g. RealNetworks) NSF proprietaire (e.g., Vocaltec) Protocole de transport TCP TCP TCP TCP TCP or UDP TCP or UDP typically UDP Application e-mail Accès distant Web Transfert de fichier streaming multimedia Fichier distant Voix sur IP 1: Introduction

  9. 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 Le Web: jargon www.someSchool.edu/someDept/pic.gif 1: Introduction

  10. HTTP: hypertext transfer protocol Couche applicative Web Modèle client/serveur client: browser qui demande, reçoit, afficheles objets Web serveur:serveur Web envoit les réponses aux requêtes http1.0: RFC 1945 http1.1: RFC 2068 Le Web: le protocole HTTP http request PC exécutant Explorer http response http request Server exécutant Apache server http response Mac exécutant Netscape 1: Introduction

  11. HTTP: service de transport TCP : Le client initie un connexion TCP (crée une socket) au serveur, port 80 Le serveur acceptela 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 Le protocole HTTP 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. Si 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 Exemple HTTP 1b.Le serveur HTTPdu site www.someSchool.edu attend une connexion TCP sur le port 80. “accepte” la connexion, et l’annonce au client 2.Le client HTTP envoit les requêtesHTTP (contenant des URLs) par les sockets TCP 3.Le serveur HTTP reçoit le message de requêtes, génére lesmessages de réponse contenantl’objet requis (someDepartment/home.index), et l’envoie sur une socket time 1: Introduction

  13. 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 http example (cont.) 4.Le serveur HTTP ferme la connexion TCP 6.Les étapes 1-5 sont répétés pour chaque URLs référencés time 1: Introduction

  14. Non-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. Connexions Persistantes et Non-persistantes Mais la plupart des navigateurs de version 1.0 utilisent des connexions parallèle 1: Introduction

  15. Format de messagehttp : requête • Deux types demessages http : requête, réponse • message de requête http : • ASCII Ligne de requête (commandes GET, POST, HEAD) GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr Lignesd’entête Le retour chariot, indique la fin du message 1: Introduction

  16. Format de messagehttp : requête 1: Introduction

  17. Format de messagehttp : réponse Ligne de status (protocole Code de status Etat) 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 ... Lignes d’entêtes données, e.g., Le fichier html 1: Introduction

  18. 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 Code de réponse HTTP Dans la première ligne de la réponse serveur->client. 1: Introduction

  19. 1. Telnet à votre serveur web favori Essayer le serveur http telnet www.eurecom.fr 80 Ouvre une connexion TCP vers le port 80 de www.eurecom.fr. 2. Taper une requête HTTP GET /~ross/index.html HTTP/1.0 1: Introduction

  20. Le serveur envoit un “cookie” vers le client dans la reponse Set-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 requêtehttp+ cookie: # Réponse http Interaction entre le client et le serveur : cookies server client requêtehttp Réponse http + Set-cookie: # Opération Spécifique au cookie 1: Introduction

  21. 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 http If-modified-since: <date> serveur: la réponse est vide si la copie cachée est à jour HTTP/1.0 304 Not Modified Réponse http HTTP/1.0 304 Not Modified GET conditionel server client Requête http If-modified-since: <date> object Non modifié Requête http If-modified-since: <date> objet modifié Réponse http HTTP/1.1 200 OK … <data> 1: Introduction

  22. 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 Caches Web Goal: satisfaire la requête du client sans utiliser le serveur initial origin server Proxy server http request http request client http response http response http request http request http response http response client origin server 1: Introduction

  23. Hypothèse:le cache est proche du client Réduction du temps de réponse Réduction du débit vers les serveurs distant Pourquoi le Cache Web? origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN institutional cache 1: Introduction

  24. Gens:plusieurs identifiant: NSS, name, # Passeport Hôte, routeurs: Adresse IP (32 bit) “nom”, e.g., gaia.cs.umass.edu Q:Comment lier les adresseset 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 DNS: Domain Name System 1: Introduction

  25. 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 ! DNS name servers 1: Introduction

  26. 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 DNS: Root name servers 1: Introduction

  27. 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 local name server dns.eurecom.fr Simple DNS example root name server 2 4 3 5 authorititive name server dns.umass.edu 1 6 requesting host surf.eurecom.fr gaia.cs.umass.edu 1: Introduction

  28. Root name server: may not know authoratiative name server may know intermediate name server: who to contact to find authoritative name server local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS example root name server 6 2 3 7 5 4 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu 1: Introduction

  29. 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” local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS: iterated queries root name server iterated query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu 1: Introduction

  30. 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 DNS: caching and updating records 1: Introduction

  31. 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) DNS records • Type=CNAME • name is an alias name for some “cannonical” (the real) name • value is cannonical name • Type=A • name is hostname • value is IP address • Type=MX • value is hostname of mailserver associated with name 1: Introduction

  32. DNS protocol :queryand reply messages, both with same message format DNS protocol, messages 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 reponse to query records for authoritative servers additional “helpful” info that may be used 1: Introduction

  34. a host-local, application-created/owned, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another (remote or local) application process socket Socket programming Goal: learn how to build client/server application that communicate using sockets 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 1: Introduction

  35. process process TCP with buffers, variables TCP with buffers, variables socket socket 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 controlled by application developer controlled by application developer controlled by operating system controlled by operating system internet host or server host or server 1: Introduction

  36. 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 Socket programming with TCP 1: Introduction

  37. 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 Socket programming with TCP outToServer iinFromServer inFromUser client socket 1: Introduction

  38. create socket, connect to hostid, port=x create socket, port=x, for incoming request: clientSocket = Socket() welcomeSocket = ServerSocket() TCP connection setup wait for incoming connection request connectionSocket = welcomeSocket.accept() send request using clientSocket read request from connectionSocket write reply to connectionSocket read reply from clientSocket close connectionSocket close clientSocket Client/server socket interaction: TCP Server (running on hostid) Client 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()); Create input stream Create client socket, connect to server Create output stream attached to socket 1: Introduction

  40. Example: Java client (TCP), cont. Create input stream attached to socket 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(); } } Send line to server Read line from 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())); Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, 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); } } } Create output stream, attached to socket Read in line from socket Write out line to socket End of while loop, loop back and wait for another client connection 1: Introduction

  43. 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 UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server application viewpoint Socket programming with UDP 1: Introduction

  44. Client create socket, port=x, for incoming request: serverSocket = DatagramSocket() create socket, clientSocket = DatagramSocket() Create, address (hostid, port=x, send datagram request using clientSocket read request from serverSocket write reply to serverSocket specifying client host address, port umber read reply from clientSocket close clientSocket Client/server socket interaction: UDP Server (running on hostid) 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(); Create input stream Create client socket Translate hostname to IP address using DNS 1: Introduction

  46. Example: Java client (UDP), cont. Create datagram with data-to-send, length, IP addr, port 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(); } } Send datagram to server Read datagram from 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); Create datagram socket at port 9876 Create space for received datagram Receive datagram 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 addr port #, of sender Create datagram to send to client Write out datagram to socket End of while loop, loop back and wait for another datagram 1: Introduction

More Related