INF4032 Réseaux Informatiques (2022-2023) PDF

INF4032 Réseaux Informatiques Bassem Haidar 2022- 2023 Couche Application HTTP – DNS Chapter 03  Web et HTTP la page Web se compose d'objets l'objet peut être un fichier HTML, une image JPEG, une applet Java, un fichier audio,… la...

INF4032 Réseaux Informatiques Bassem Haidar 2022- 2023 Couche Application HTTP – DNS Chapter 03  Web et HTTP la page Web se compose d'objets l'objet peut être un fichier HTML, une image JPEG, une applet Java, un fichier audio,… la page Web se compose d'un fichier HTML de base qui comprend plusieurs objets référencés chaque objet est adressable par une URL, par exemple, www.someschool.edu/someDept/pic.gif host name path name  Présentation HTTP HTTP : protocole de transfert hypertexte Protocole de couche application PC running du Web Firefox browser modèle client/serveur – client : navigateur qui demande, reçoit, (en utilisant le protocole server HTTP) et « affiche » des objets running Web Apache Web – serveur : le serveur Web envoie server (en utilisant le protocole HTTP) des objets en réponse aux iPhone running requêtes Safari browser  HTTP overview (continued) utilise TCP : HTTP est « sans état » le client initie la connexion TCP le serveur ne conserve aucune (crée un socket) au serveur, port 80 information sur les demandes le serveur accepte la connexion passées des clients TCP du client aside les protocoles qui maintiennent Messages HTTP (messages de « l'état » sont complexes ! protocole de couche application) l'histoire passée (état) doit être échangés entre le navigateur maintenue (client HTTP) et le serveur Web si le serveur/client tombe en panne, leurs points de vue sur (serveur HTTP) « l'état » peuvent être Connexion TCP fermée incohérents.  Connexions HTTP HTTP non persistant HTTP persistant au plus un objet envoyé via plusieurs objets peuvent être une connexion TCP envoyés via une seule – connexion puis fermée connexion TCP entre le client, le téléchargement de plusieurs le serveur objets nécessite plusieurs connexions  HTTP non persistant supposons que l'utilisateur entre l'URL : (contient du texte, www.someSchool.edu/someDepartment/home.index références à 10 images jpeg) 1a. Le client HTTP initie la connexion TCP au serveur 1b. Serveur HTTP sur l'hôte HTTP (processus) sur www.someSchool.edu en www.someSchool.edu sur le attente d'une connexion TCP port 80a au port 80. « accepte » la 2. Le client HTTP envoie un connexion, notifiant le client message de requête HTTP (contenant l'URL) dans le 3. Le serveur HTTP reçoit un socket de connexion TCP. Le message de demande, forme message indique que le client un message de réponse veut l'objet contenant l'objet demandé et someDepartment/home.index envoie un message dans son temps socket  HTTP non persistant (suite) 4. Le serveur HTTP ferme la connexion TCP. 5. Le client HTTP reçoit un message de réponse contenant un fichier html, affiche html. Analyse du fichier html, trouve 10 objets jpeg référencés temps 6. Étapes 1 à 5 répétées pour chacun des 10 objets jpeg  HTTP non persistant : temps de réponse RTT (définition) : temps nécessaire à un petit paquet pour voyager du client au serveur et vice-versa initiate TCP Temps de réponse HTTP : connection RTT – un RTT pour initier la connexion TCP request file – un RTT pour la requête HTTP et time to RTT les premiers octets de la réponse transmit HTTP à renvoyer file file – temps de transmission du fichier received temps de réponse HTTP non persistant = Temps de time time transmission du fichier 2RTT+ 2-  Persistent HTTP problèmes HTTP non HTTP persistant : persistants : le serveur laisse la connexion nécessite 2 RTT par objet ouverte après l'envoi de la réponse Surcharge du système messages HTTP suivants entre le d'exploitation pour chaque même client/serveur envoyés via connexion TCP une connexion ouverte les navigateurs ouvrent le client envoie des requêtes dès souvent des connexions TCP qu'il rencontre un objet référencé parallèles pour récupérer les aussi peu qu'un RTT pour tous les objets référencés objets référencés  Message de requête HTTP deux types de messages HTTP : requête, réponse Message de requête HTTP : – ASCII (human-readable format) carriage return character line-feed character request line (GET, POST, GET /index.html HTTP/1.1\r\n HEAD commands) Host: www-net.cs.umass.edu\r\n User-Agent: Firefox/3.6.10\r\n Accept: text/html,application/xhtml+xml\r\n header Accept-Language: en-us,en;q=0.5\r\n lines Accept-Encoding: gzip,deflate\r\n carriage return, Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n line feed at start Keep-Alive: 115\r\n Connection: keep-alive\r\n of line indicates \r\n end of header lines * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Message de requête HTTP : format général method sp URL sp version cr lf request line header field name value cr lf header ~ ~ ~ ~ lines header field name value cr lf cr lf ~ ~ entity body ~ ~ body  Uploading form input POST method: URL method: la page Web comprend utilise la méthode GET souvent une entrée de l'entrée est téléchargée dans formulaire le champ URL de la ligne de l'entrée est téléchargée sur le demande : serveur dans le corps de l'entité www.somesite.com/animalsearch?monkeys&banana Application Layer 2-13  Types de méthode HTTP/1.0: HTTP/1.1: GET GET, POST, HEAD POST PUT HEAD – uploads file in entity – asks server to leave body to path specified requested object out in URL field of response DELETE – deletes file specified in the URL field 2-14  Message de réponse HTTP status line (protocol status code HTTP/1.1 200 OK\r\n status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n header ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n lines Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=ISO-8859- 1\r\n data, e.g., \r\n requested data data data data data... HTML file * Check out the online interactive exercises for more Application Layer examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ 2-15  Codes d'état de réponse HTTP le code d'état apparaît sur la 1ère ligne dans le message de réponse serveur-client. quelques exemples de codes : 200 OK – request succeeded, requested object later in this msg 301 Moved Permanently – requested object moved, new location specified later in this msg (Location:) 400 Bad Request – request msg not understood by server 404 Not Found – requested document not found on this server 505 HTTP Version Not Supported Application Layer 2-16  Essayer HTTP (côté client) par vous-même 1. Telnet à votre serveur Web préféré : telnet gaia.cs.umass.edu 80 ouvre la connexion TCP au port 80 (port du serveur HTTP par défaut) sur gaia.cs.umass. édu. tout ce qui est tapé sera envoyé vers le port 80 sur gaia.cs.umass.edu 2. saisissez une requête HTTP GET : GET /kurose_ross/interactive/index.php HTTP/1.1 Host: gaia.cs.umass.edu en tapant ceci (appuyez sur carriage retourner deux fois), vous envoyez ce minime (mais complet) GET requête au serveur HTTP 3. regardez le message de réponse envoyé par le serveur HTTP ! (ou utilisez Wireshark pour regarder la requête/réponse HTTP capturée) 2-17  Etat utilisateur-serveur : cookies Exemple: de nombreux sites Web utilisent des cookies Susan accède toujours à quatre composants : Internet depuis un PC 1) ligne d'en-tête de cookie visite un site de commerce du message de réponse électronique spécifique HTTP pour la première fois 2) ligne d'en-tête de cookie dans le prochain lorsque les requêtes HTTP message de requête initiales arrivent sur le site, HTTP le site crée : 3) fichier cookie conservé sur l'hôte de l'utilisateur, – identifiant unique géré par le navigateur de – entrée dans la base de l'utilisateur données principale pour 4) base de données l'ID principale sur le site Web 2-18  Cookies : conserver « état » (suite) client server ebay 8734 usual http request msg Amazon server cookie file creates ID usual http response 1678 for user create backend ebay 8734 set-cookie: 1678 entry database amazon 1678 usual http request msg cookie: 1678 cookie- access specific usual http response msg action one week later: access ebay 8734 usual http request msg amazon 1678 cookie: 1678 cookie- specific usual http response msg action  Cookies (continued) aside à quelles fins les cookies peuvent-ils être utilisés : cookies et confidentialité : autorisation les cookies permettent aux sites paniers d'en apprendre beaucoup sur recommandations vous état de session utilisateur (courriel Web) comment garder « état » : points de terminaison de protocole : maintien de l'état au niveau de l'expéditeur/du destinataire sur plusieurs transactions cookies : les messages http portent l'état 2-20  Caches Web (serveur proxy) objectif : satisfaire la demande du client sans impliquer le serveur d'origine navigateur définit l'utilisateur : accès Web via le cache proxy le navigateur envoie toutes server les requêtes HTTP au cache client origin – objet dans le cache : le server cache renvoie l'objet – sinon le cache demande l'objet du serveur d'origine, puis renvoie l'objet au client client origin server Application Layer 2-21  En savoir plus sur la mise en cache Web le cache agit à la fois comme pourquoi la mise en cache Web ? client et serveur réduire le temps de réponse à – serveur pour le client la demande du client demandeur d'origine réduire le trafic sur le lien – client vers serveur d'origine d'accès d'un établissement généralement le cache est installé par le FAI (université, entreprise, FAI résidentiel)  GET conditionnel client server Objectif : ne pas envoyer d'objet si le cache a une version mise en HTTP request msg cache à jour If-modified-since: object – pas de délai de transmission not d'objet modified HTTP response – utilisation de la liaison inférieure before HTTP/1.0 cache : spécifiez la date de la 304 Not Modified copie en cache dans la requête HTTP – If-modified-since: serveur : la réponse ne contient HTTP request msg aucun objet si la copie en cache If-modified-since: object est à jour : modified after – HTTP/1.0 304 Not Modified HTTP response HTTP/1.0 200 OK DNS  DNS: domain name system personnes : de nombreux Système de noms de domaines: identifiants : base de données distribuée – SSN, nom, passeport # implémentée dans la Hôtes Internet, routeurs : hiérarchie de nombreux – Adresse IP (32 bits) - utilisée pour serveurs de noms l'adressage des datagrammes – "nom", par exemple, protocole de la couche www.yahoo.com - utilisé par les application : les hôtes, les humains serveurs de noms Q : comment mapper entre communiquent pour résoudre l'adresse IP et le nom, et vice les noms (traduction versa ? d'adresse/de nom)  DNS: services, structure DNS services pourquoi ne pas centraliser le DNS traduction du nom d'hôte en ? adresse IP point de défaillance unique alias d'hôte le volume de circulation – canonique, noms d'alias base de données centralisée alias de serveur de messagerie distante Répartition de la charge maintenance – serveurs Web répliqués : plusieurs adresses IP correspondent à un nom  DNS : une base de données distribuée et hiérarchique Root DNS Servers … … com DNS servers org DNS servers edu DNS servers pbs.org poly.edu umass.edu yahoo.com amazon.com DNS servers DNS serversDNS servers DNS servers DNS servers le client veut une IP pour www.amazon.com ; 1ère approximation : le client interroge le serveur racine pour trouver le serveur DNS com le client interroge le serveur DNS.com pour obtenir le serveur DNS amazon.com le client interroge le serveur DNS amazon.com pour obtenir l'adresse IP de www.amazon.com  DNS : serveurs de noms racine contacté par le serveur de noms local qui ne peut pas résoudre le nom serveur de noms racine : – contacte le serveur de noms faisant autorité si le mappage de noms n'est pas connu – obtient la cartographie – renvoie le mappage vers le serveur de noms local c. Cogent, Herndon, VA (5 other sites) d. U Maryland College Park, MD k. RIPE London (17 other sites) h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites) e. NASA Mt View, CA m. WIDE Tokyo f. Internet Software C. (5 other sites) Palo Alto, CA (and 48 other sites) a. Verisign, Los Angeles CA 13 logical root name (5 other sites) b. USC-ISI Marina del Rey, CA “servers” worldwide l. ICANN Los Angeles, CA each “server” replicated (41 other sites) g. US DoD Columbus, many times OH (5 other sites)  TLD, authoritative servers top-level domain (TLD) servers: – responsable de com, org, net, edu, aero, jobs, musées et de tous les domaines nationaux de premier niveau, par exemple : uk, fr, ca, jp – Network Solutions maintient des serveurs pour le TLD.com – Educause pour le TLD.edu authoritative DNS servers: – le(s) propre(s) serveur(s) DNS de l'organisation, fournissant un nom d'hôte faisant autorité aux mappages IP pour les hôtes nommés de l'organisation – peut être maintenu par l'organisation ou le fournisseur de services 2-29  Serveur de noms DNS local n'appartient pas strictement à la hiérarchie chaque fournisseur d'accès Internet (FAI résidentiel, entreprise, université) a un – également appelé « serveur de noms par défaut » lorsque l'hôte fait une requête DNS, la requête est envoyée à son serveur DNS local – a un cache local de paires de traductions nom-à-adresse récentes (mais peut être obsolète !) – agit en tant que proxy, transmet la requête dans la hiérarchie Application Layer 2-30  DNS name root DNS server resolution example 2 3 l'hôte de cis.poly.edu TLD DNS server veut une adresse IP pour 4 gaia.cs.umass.edu 5 requête itérative : local DNS server dns.poly.edu  le serveur contacté 7 6 répond avec le nom 1 8 du serveur à contacter  "Je ne connais pas ce authoritative DNS server nom, mais demandez à requesting host dns.cs.umass.edu ce serveur" cis.poly.edu gaia.cs.umass.edu Application Layer 2-31  DNS : mise en cache, mise à jour des enregistrements une fois que (n'importe quel) serveur de noms apprend le mappage, il met en cache le mappage – délai d'expiration des entrées de cache (disparition) après un certain temps (TTL) – Serveurs TLD généralement mis en cache dans des serveurs de noms locaux donc les serveurs de noms racine ne sont pas souvent visités les entrées mises en cache peuvent être obsolètes (traduction nom-adresse au mieux !) – si le nom de l'hôte change d'adresse IP, peut ne pas être connu sur Internet jusqu'à ce que tous les TTL expirent mécanismes de mise à jour/notification proposés norme IETF – RFC 2136 Application Layer 2-32  DNS records DNS: distributed database storing resource records (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  www.ibm.com is really type=NS – name is domain (e.g., servereast.backup2.ibm.c foo.com) om – value is hostname of  value is canonical name authoritative name type=MX server for this domain  value is name of mailserver associated with name Application Layer 2-33  DNS protocol, messages query and reply messages, both with same message format 2 bytes 2 bytes message header identification flags  identification: 16 bit # for query, reply to query uses same # # questions # answer RRs  flags:  query or reply # authority RRs # additional RRs  recursion desired  recursion available questions (variable # of questions)  reply is authoritative answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) Application Layer 2-34 DNS protocol, messages 2 bytes 2 bytes identification flags # questions # answer RRs # authority RRs # additional RRs name, type fields questions (variable # of questions) for a query RRs in response answers (variable # of RRs) to query records for authority (variable # of RRs) authoritative servers additional “helpful” additional info (variable # of RRs) info that may be used Application Layer 2-35  Attacking DNS DDoS attacks redirect attacks bombard root servers  man-in-middle with traffic Intercept queries – not successful to date  DNS poisoning – traffic filtering  Send bogus relies to – local DNS servers cache IPs DNS server, which of TLD servers, allowing caches root server bypass exploit DNS for DDoS bombard TLD servers  send queries with – potentially more spoofed source dangerous address: target IP  requires amplification Application Layer 2-36