RES 224 Architecture des applications Internet Accès au données HTTP et FTP

Transcription

1 RES 224 Architecture des applications Internet dario.rossi Accès au données HTTP et FTP RES224 v Dario Rossi Web Histoire du Web Architecture du Web Le protocole HTTP Performance FTP Apercu du protocole Connectivité Plan 1

2 HTTP Histoire du World Wide Web 1945, Vannevar Bush's memex 1965, Ted Nelson invente le mot "Hypertext" 1989, Tim Berners Lee (CERN) debut du Web 1991, première demonstration publique 1993, Marc Anderson, (Univ. of Illinois at Urbana Champaign), Mosaic 1994, World Wide Web Consortium agreement ( signé par MIT et CERN 1994, Java (SUN Microsystems) rencontre le Web 1995, Netscape devient une societé à la bourse 1995, JavaScript 1996, Internet Explorer commence la guerre des browsers 2001, estimation de la taille du deep Web 2004, Web , AJAX 2008, YouTube deuxième moteur de recherche après Google 2009, Twitter et l Iran, 2010, facebook, ou comment inviter personne à ton anniversaire 2

3 Architecture du Web Architecture du Web Client HTTP protocole HTTP Serveur HTTP Browser HTML Server HTTP Proxies Interaction HTTP / TCP Focus de RES224 RES240 3

4 Architecture du Web Hebergement (Web hosting) Hebergement de plusieurs p tit sites sur une seule machine (eg. Geocites) Services d hebergement encore existent (eg. lately, virtual HTTP servers) GeoCities was shut down 26 Oct There were at least 38 million userbuilt pages. Server farms Architecture du Web Enormement de machines pour faire face a à la charge due aux nombre de clients Cela marche pour des bottleneck de CPU, mais pas de capacité (un des centres) Google 4

5 Architecture du Web CDN Specialisés dans la diffusion du contenu Redirection des requetes AS4 CDN User AS1 CDN via DNS (cfr optional readings) via HTTP redirection (plus loin dans le cours) Multi-B$ business ~30 market players Akamai, Limelight AS2 CDN Video Server CDN AS3 Vocabulaire du Web Page Web: Ensemble d objets Page HTML de base Objets (images, fichiers, ) référencés par des URLs Uniform Resource Locator (URL) proto://nom.de.domaine:porte/chemin/d/acces.htm Agents utilisateur Browser MS Internet Explorer, Firefox, Chrome,.. Crawler, spider Wget, DeeperWeb, WebCrawler, Daemon Server Web : Apache, Google Web server, MS Internet Information Server, Proxy server Squid cache, Apache Traffic Server, Internet y.x.com 5

6 Universal Resource Locators Une precision: non seulement les objet HTTP sont désignés par URLs URLs contients Protocole, machine, port, répertoire et fichier mais aussi parametres (cfr plus tard), etc. et ils peuvent donc devenir arbitrairement compliqué HTML HyperText Markup Language Page HTML interpreté par le browser Page HTML stoqué sur le server Web (b) 6

7 Documents dynamiques HTML pas seulement statique, mais dynamiquement crée en fonction des demande d usager HTTP Plusieurs composant de l architecture Web, coté serveur (e.g., CGI, PHP, SHTML) coté client (Javascript, Ajax, ) HTTP Remarque: HTTP intervient seulement dans quelques cas HTTP Le protocole HTTP Paradigme client/server Client: le browser, qui demande, reçoit, affiche les objets Web Serveur: le serveur Web, qui envoie les réponses aux requêtes des browsers Simple protocole requête/réponse Importance de normes: interoperabilité HTTP1.0 : RFC 1945 HTTP1.1 : RFC 2068 Win95 IE5 Linux Firefox Machine Unix Netscape Internet 7

8 Le protocole HTTP Service de transport (simplifié) Orienté données, donc TCP Le client initie une connexion TCP (socket) avec le serveur, port 80 Le serveur accepte la connexion TCP Quelle est la porte du client? Des messages HTTP (protocole applicatif) sont échangés entre le browser (client) et le serveur Web La connexion TCP est fermée Remarque: cela depends des options et/ou de la version du protocle HTTP est «sans état» Le serveur ne maintient aucune information au sujet des requêtes précédentes des clients Pro: simplicité d implementation, passage à l echelle Contre: manque d information Les protocoles «avec état» sont complexes! L histoire passée doit être gardée Si le serveur ou le client crashe les états peuvent être incohérents et il faut les resynchroniser Format des messages HTTP : requete Deux types de messages HTTP : requête, réponse Format ASCII Message de requête HTTP : Ligne de requête (methode, ressource, version protocole) Lignes d entête Le retour chariot indique la fin du message GET /~drossi/index.html HTTP/1.0 Host: Connection: close User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr 8

9 Format de message HTTP : reponse Deux types de messages HTTP : requête, réponse Format ASCII Message de reponse HTTP : Ligne d'état (version, code et message d'état) Données (e.g., html, image) Lignes d entête Vide HTTP/ OK Connection: close Date: Thu, 06 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Apr Content-Length: 621 Content-Type: text/html data data data data data... Méthodes HTTP/1.0 GET Rapatrie des objet POST Envoie des objet HEAD Requete d information de l entete concernant l objet; Le serveur laisse l objet hors de la réponse HTTP/1.1 GET, POST, HEAD PUT Charge le fichier dans le corps vers le chemin spécifié dans l URL DELETE Efface le fichier indiqué dans le champ URL 9

10 (Charger du contenu de formulaire) Méthode POST Une page web peut contenir des inputs de formulaires Input envoyé au serveur dans le corps du message POST Méthode GET Input envoyé directement dans le champ URL du message GET Examples d Entetes 10

11 Codes de réponse HTTP 200 OK La requête a réussi et l objet demandé est à la suite dans le corps du message 301 Moved Permanently L objet demandé a changé définitivement de place (voir corps 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 Mechanismes HTTP Interaction avec le niveau transport Connexion persistantes Pipelining des requetes Contourner l absence d etat de HTTP Authorization Cookies Architecture et performance GET Conditionnel Redirection Proxy HTTP 11

12 Mechanismes HTTP Interaction avec le niveau transport Connexion persistantes Pipelining des requetes Contourner l absence d etat de HTTP Authorization Cookies Architecture et performance GET Conditionnel Redirection Proxy HTTP HTTP non persistant Côté client 1a. Le client HTTP initie une connexion TCP au serveur HTTP sur le port 80 (open active) 2. Le client HTTP envoie les requêtes HTTP (contenant des URLs) sur la connexion TCP 5. Le client HTTP reçoit la réponse contenant le fichier HTML, l affiche, et trouve les URLs référencées temps SYN SYN+ACK GET Data FIN Côté serveur 1b. Le serveur HTTP attend une connexion TCP sur le port 80. Il accepte la connexion, et l annonce au client (open passive) 3. Le serveur HTTP reçoit le message de requête, génère le message de réponse contenant l objet requis, et l envoie sur la connexion TCP 4. Le serveur ferme la connexion TCP (half close) 6. Les étapes 1-5 sont répétées pour chaque URL référencée (e.g. images à telechargér), potentiellement en parallel 12

13 Interaction avec TCP Temps de réponse: 2RTT Un RTT pour la connexion TCP Un RTT pour la requete HTTP et le premier segment TCP de la reponse HTTP (~1460 octets) Temps de completement: 2RTT+t TX t TX depends de l etat de la connexion Slow start: 1,2,4,8, segments par RTT au debut World Wide Wait! Le browser ne peut que commencer à afficher les données apres 2 RTT Slow-start pour tous les objects RTT RTT SYN SYN+ACK ACK + GET Data + FIN FINACK Etablissement de connexion Transfert de données Fermeture connexion HTTP persistant Côté client 1a. Le client HTTP initie une connexion TCP au serveur HTTP sur le port 80 (open active) 2. Le client HTTP envoie la requête HTTP sur la connexion TCP 4. Le client HTTP reçoit la réponse HTML, les URLs référencées et envoye >1 requetes (pipelining) 6. Une fois la page completé, le browser ferme la connexion (ou sinon le server après un timeout de k*300s ) temps SYN SYN+ACK GET Data GETs Data Côté serveur 1b. Le serveur HTTP attend une connexion TCP sur le port 80. Il accepte la connexion, et l annonce au client (open passive) 3. Le serveur HTTP reçoit le message de requête, génère le message de réponse contenant l objet requis, et l envoie sur la connexion TCP 5. Le serveur envoye les reponses sur la meme connexion dès que l algorithme de controle de congestionde TCP le permet (cwnd) 13

14 Connexion Persistantes et Pipelining Connexion non-persistante HTTP/1.0 Le serveur interprète les requêtes, répond et ferme la connexion TCP Probleme(cfr slide suivant) Au moins 2 RTTs pour lire chaque objet (handshake) Chaque transfert doit subir le slow-start de TCP Exemple : page contenant: 1 HTML + 10 petits JPEG Remarque Les navigateurs HTTP/1.0 utilisent plusieurs connexion en parallel!! Connexion Persistante Par défaut dans HTTP/1.1 introduite ensuite dans HTTP/1.0 Une seule connexion TCP Pipelining: le client envoie les requête de tous les objets requis dès qu ils sont référencés dans le HTML => pas obligé d attendre une reponse pour envoyer une nouvelle requete Performance Gain en performance pour le client Moins de RTTs en debut de connexion => moins de delai Moins de slow start (maintien des parametres) => plus de bande passante Gain en performance pour le serveur Moins de ressources employés (socket) => plus de clients servis Mechanismes HTTP Interaction avec le niveau transport Connexion persistantes Pipelining des requetes Contourner l absence d etat de HTTP Authorization Cookies Architecture et performance GET Conditionnel Redirection Proxy HTTP 14

15 Intérêt: accès restreint Contrôle d'accès HTTP fournit des codes et des entêtes d'état pour permettre l'authentification Server: 401 Authorization Required Client : Authorization : user name Password (en clair! HTTP est sans état Le client doit être autorisé à chaque requête Necessaire d utiliser l en-tête Autorisation: dans chaque requête Autrement erreur 401 Totalement insecure sauf si utilisé avec SSL/TLS (Secure Socket Layer / Transport Layer Security) GET 401: authorization req. WWW authenticate: GET Authorization: <cred> 200 OK... GET Authorization: <cred> 200 OK... Cookies Le cookie, soit Un identificatif unique, transporté dans l entete HTTP Introduisent de l etat dans un protocole sans etat Elegant, simple, scalable, espion Flexible: interpretation arbitraire RFC 2109 Quatre composantes 1) Cookie dans HTTP request 2) Cookie dans HTTP response 3) Fichier cookie chez l'utilisateur et géré par le browser 4) Database derriere le site Web Pros/Cons Authorisation implicite Caddies (e-commerce) État session (Web ) Publicité/offre personalisé Privacy issues Proprietés Transportés par HTTP Gérés au dela de HTTP >300 cookies par browser >4096 bytes par cookie >20 cookie par domaine Remarque: 1 cookie = plusieurs segments TCP 15

16 Cookies GET /index.php?id=122 HTTP/1.1 Accept: */* Referer: php?id=19 Accept-Language: fr Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;.NET CLR ;.NET CLR ; InfoPath.2) Host: Connection: Keep-Alive Cookie: user=8441e98f05; TestCookieAlone=ok; Nombre_visite=6; Derniere_visite=20%2F12 %2F2006+%E0+09%3A20 GET 200 OK Setcookie: GET Cookie: HTTP/ OK Date: Wed, 20 Dec :20:17 GMT Server: Apache/ (Unix) PHP/4.4.4 mod_ssl/ OpenSSL/0.9.6b X-Powered-By: PHP/4.4.4 Set-Cookie: user=8441e98f05; Nombre_visite=6; expires=wednesday, 27-Dec-06 08:20:18 GMT Set-Cookie: Derniere_visite=20%2F12%2F2 006+%E0+09%3A20; expires=wednesday, 27-Dec-06 08:20:18 GMT Keep-Alive: timeout=15, Connection: Keep-Alive DB Operations specifiques au Cookie 200 OK Contenu personalisé Espionnage avec les Cookies et representent des image 1x1 pixels, de couleur transparent et ne sont pas hebergés sur site1.com, mais sur spy.com Site1.com <img src=spy.com/img-1.png> HTML Site2.com HTML Spy.com Img-1 Img-2 Site1.com vous renvoye vers Spy.com pour Spy.com recoit une requete pour img-1, vous envoye un cookie C, et sait que C a visité Site1 Quand vous visitez Site2.com, votre browser doit utiliser le meme cookie C pour obtenir img-2, etc. Spy.com peut alors connaître le comportement de C En moyenne, environ 80 sites comme spy.com par session GET SETC GET,C 16

17 Mechanismes HTTP Interaction avec le niveau transport Connexion persistantes Pipelining des requetes Contourner l absence d etat de HTTP Authorization Cookies Architecture et performance GET Conditionnel Redirection Proxy HTTP GET Conditionnel Objectif ne pas envoyer un objet que le client a déjà dans son cache Problème les objets contenus dans le cache peuvent être obsolètes Solution GET conditionnel Operation client: spécifie la date de la copie cachée dans l entete If-modified-since: <date> serveur: la réponse est vide si la copie cachée est à jour HTTP/ Not Modified Remarque Plus efficace que effectuer une requete HEAD, verifier la date de l objet et telecharger si modifié HEAD aurait besoin d un RTT en plus GET If-modified-since: <date> HTTP/ Not Modified GET If-modified-since: <date> HTTP/ OK Data 17

18 HTTP Redirection YouTube Web Frontend GET get_video?video _id=xyz HTTP/1.1 HTTP/ See other location: et_video?video_id=xyz YouTube video server Geolocalisation de l hote, choix d un serveur video proche peu chargé GET get_video?video _id=xyz HTTP/ OK Video data Proxy server (Cache Web) Proxy server Web server Interet ne contacter le serveur d origine que si necessaire Remarque Le cache locale HTTP permet aux browsers de garder les pages lues (~/.mozilla/cache) Ce cache n est pas partagé Deux types de proxy Explicite: configuration du browser pour qu'il pointe vers le proxy server Transparent: intercepte et modifie les packets Fonctionnement Si l objet est dans le cache, le proxy le renvoie tout de suite Sinon il demande au serveur d origine, cache, et répond ensuite Proxy = client et serveur 18

19 Proxy server (Cache Web) Principe Le cache est proche du client Cache partagé par tous les clients du meme reseau Cout Réduction du débit à l acces, economie de bande passante dans le coeur Réduction du Opex (facture ISP) avec investissement Capex (serveur proxy) Performance Réduction du temps de réponse Delai plus faible en LAN (<1ms) que sur Internet (parfois >100ms) Capacité plus importante en LAN (Gbps) que sur le lien d acces Privacy? N. 2 1 Machine InternetUnix Netscape FTP 19

20 File Transfer Protocol (FTP) Service Transfert de fichiers entre hôtes Chatacteristiques RFC 959 Server FTP: port 21 Deux connexion: control et data Protocole à etat (repertoire, authentication,...) Paradigme client/server, Requete/reponse; format binaire, textuel, ou compression Eventuellement le client peut instruir une communicaton entre plusieurs serveurs Machine Unix Netscape Internet FTP : commandes, réponses Example de commandes: Envoyées comme du texte ASCII sur le canal de contrôle USER username PASS password LIST renvoie la liste des fichiers du répertoire courant RETR filename : rappatrie le fichier (get) STOR filename : stocke le fichier sur l'hôte distant (put) Example de réponses: status code et explication (similaire à HTTP) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can t open data connection 452 Error writing file 20

21 FTP : commandes, réponses % ftp hostname Connected to hostname Name (hostname:moi): 331 Password required for moi 331 Guest login ok, send address as password Password: 230 user moi logged in ftp> Commande internes du logiciel ftp qui implemente le protocole FTP Commandes internes?, cd, lcd, ls, dir, pwd, open, close, bin, ascii, get, put, prompt, hash, mget, mput, del, mkdir, quit. Active FTP Connexion de contrôle Role: échange des commandes et des réponses entre le client et le serveur contrôle hors-bande (mais capacité physique partagée avec données) Client: open active depuis le port non privilegié N vers le port 21 du serveur Client: envoye PORT N+1 au serveur et open passive du port N+1 Connexion de données Role: echange de fichiers de données vers/depuis l'hôte distant Server: open active vers le port N+1 du client à partir du port 20 Souci de connectivité si hote derriere NAT ou Firewall (SYN vers port N+1 bloqué) => passive FTP N N SYN ACK PORT N+1 SYN+ACK SYN+ACK SYN TCP ports Connexion de control Connexion data ACK 21

22 Passive FTP Connexion de contrôle Role: échange des commandes et des réponses entre le client et le serveur contrôle hors-bande (mais capacité physique partagée avec données) Client: open active depuis le port non privilegié N vers le port 21 du serveur Client: envoye PASV au serveur Server: envoye PORT P (P>1023) au client et open passive du port P Connexion de données Role: echange de fichiers de données vers/depuis l'hôte distant Client: open active vers le port P du serveur à partir du port N+1 Sens interdit respecté dans le cas du Firewall Table de association de NAT respecté en cas d addresse intranet du client SYN TCP ports N N+1 21 P>1023 ACK PASV SYN ACK SYN+ACK PORT P SYN+ACK Connexion de control Connexion data Mandatory readings References S. Alckok, R. Nelson, Application flow control in YouTube video streams, ACM SIGCOMM CCR Vol. 41, No. 2, April A. Finamore et al. YouTube everywhere: Impact of Device and Infrastructure Synergies on User Experience, ACM IMC 11, Nov Optional readinds J.C. Mogul, The case for persistent-connections HTTP, ACM SIGCOMM

23 ?? // 23