RES 203 Applications Internet dario.rossi World Wide Web HTTP (& evolutions) Dario Rossi http://www.telecom-paristech.fr/~drossi RES203 v2016/12

Plan World wide web Avant /après TP: Après HTTP: SPDY, HTTP/2, QUIC Histoire du Web Architecture du Web Le protocole HTTP Après HTTP: SPDY, HTTP/2, QUIC Recap sur limites de HTTP Introduction au features de HTTP/2 Comparatif performances HTTP vs HTTP/2 Introduction au metriques WebQoE et au TP Avant /après TP: Avant: Lectures obligatoires Apres: Stages projets Legende: le slide n’est pas objet l’examen Orange 2 2

Histoire du World Wide Web (1/2) 1945 Vannevar Bush: “memex” Ted Nelson: “Hypertext” 1989 Tim Berners Lee: “Mesh” – 1ere demo publique du “Web” 1993 Marc Andressen: “Netscape” – 1ere demo publique du browser World Wide Web Consortium (http://www.w3c.org) Hypertext Transfer Protocol -- HTTP/1.0 (RFC1945) 1999 Hypertext Transfer Protocol -- HTTP/1.1 (RFC2616) Watching the Waist of the Protocol Hourglass Steve Deering @IETF51 (2001) ..only time will tell Evolution of the IP Model Dave Thaler @IETF73 (2009)

Histoire recente 05/2008 YouTube 2eme moteur de recherche 09/2010 Google annonce SPDY (alternative à HTTP sur TCP) 08/2012 HTTP/2 draft v0 draft-ietf-httpbis-http2 08/2013 Google delivre QUIC (alternative à HTTP & TCP sur UDP) 07/2013 Premier HTTP/2 draft “implementable” (v4) 02/2015 Google annonce qu’il abandonne SPDY en faveur de HTTP/2 05/2015 HTTP/2 RFC7540 released (after v17) 12/2015 Google etains QUIC completement (??!!) 06/2016 IETF Berlin: QUIC BoF ---------- Forwarded message --------- From: 'Alyssa (Rzeszutek) Wilk' via QUIC Prototype Protocol Discussion group <proto-quic@chromium.org> Date: Lun 14 Dic 2015 19:45 Subject: Re: [proto-quic] QUIC maintenance ? To: <proto-quic@chromium.org> Hey folks, Kudos to those of you who noticed less QUIC traffic this week; we found a bug we deemed serious enough we turned things off temporarily.  We have two patches landed which ensure it won't reoccur, and plan to have QUIC turned up again as soon as possible (given proximity to the holidays). cheers, Alyssa On Mon, Dec 14, 2015 at 4:39 AM, Ingemar Johansson <ingemarj65@gmail.com> wrote: Hi Is QUIC currently enabled ? http://tstat.polito.it/cgi-bin/tstat_rrd.cgi?dir=rrd_data/Polito/Live&var=udp_bitrate&exclude=&include=&template=&hifreq=false&duration=1m&bigpic=true&logscale=&direction=both 4

Architecture du Web 5

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

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) at least 38 million user-built pages. 7

Architecture du Web Server farms Google 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é Google

Architecture du Web CDN Specialisés dans la diffusion du contenu Redirection des requetes (cfr optional readings) (plus loin dans le cours) Multi-B$ business ~30 market players Akamai, Limelight User CDN AS1 AS4 CDN AS2 Router CDN CDN AS3 Server

Vocabulaire du Web Agents utilisateur Daemon Page Web: Internet 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, … Page Web: Ensemble d’objets Page HTML de base référencés par des URLs proto://nom.de.domaine:porte/chemin/d/acces.htm Internet http://y.x.com y.x.com

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… devenir arbitrairement compliqué… 11

Pages web statiques (simpliste) Page HTML interpreté par le browser Page HTML stoqué sur le server Web (b) 12

Pages web dynamiques (simpliste) Contenu dynamiquement crée en fonction des demande d’usager Plusieurs composant de l’architecture Web, coté serveur (e.g., CGI, PHP, SHTML) coté client (Javascript, Ajax,…) HTTP dans quelques cas HTTP HTTP 13

Pages web (réelles) http://httparchive.org/interesting.php#reqTotal http://httparchive.org/interesting.php#connections 14

Pages web (réelles) (b) http://httparchive.org/trends.php?s=All&minlabel=Dec+16+2010&maxlabel=Dec+1+2015 15

Le protocole HTTP Paradigme client/server Client: le browser, qui initie les demandes, reçoit interprète et affiche les objets Serveur: le serveur Web, qui envoie les réponses aux requêtes des browsers Protocole requête/réponse, format textuel, sans état Importance de normes: interoperabilité HTTP1.0 : RFC 1945 HTTP1.1 : RFC 2068 Apache Unix Win95 IE5 Linux Firefox http request http response http response http request Internet Netscape 16

Syntaxe des messages HTTP Requête Deux types de messages HTTP : requête, réponse Format ASCII Message de reponse HTTP : Ligne de requête (méthode, ressource, version) GET /~drossi/index.html HTTP/1.0 Host: www.enst.fr Connection: close User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr Lignes d’entête Ligne vide 17

Syntaxe des messages HTTP Réponse Deux types de messages HTTP : requête, réponse Format ASCII Message de reponse HTTP : Ligne d'état (version, code et message) HTTP/1.0 200 OK Connection: close Date: Thu, 06 Aug 2002 11:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Apr 2001 …... Content-Length: 621 Content-Type: text/html data data data data data ... Lignes d’entête Ligne vide Données (e.g., script, html, image) 18

Semantique des messages HTTP Méthodes 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 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 19

Semantique des messages HTTP Usage courant Méthode POST Une page web peut contenir des formulaires, e.g. pour une recherche Input envoyé au serveur dans le corps du message POST Méthode GET Abus de semantique Input encodedirectement dans le champ URL du message GET www.somesite.com/q?animal=monkeys&fruit=banana 20

Semantique des messages HTTP Entetes 21

Semantique des messages HTTP Code de reponse 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 22

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

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é serveur Côté client (open active) SYN Il accepte la connexion, et l’annonce au client (open passive) SYN+ACK 2. Le client HTTP envoie les requêtes HTTP (contenant des URLs) sur la connexion TCP GET 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 client HTTP reçoit la réponse contenant le fichier HTML, l’affiche, et trouve les URLs référencées Data FIN temps (half close) (e.g. images à telechargér), potentiellement en parallel 25

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+tTX tTX 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 (sans compter TLS) Slow-start pour tous les objects SYN de connexion RTT SYN+ACK ACK + GET données RTT Data + FIN Fermeture connexion FINACK 26

Interaction avec TCP Temps de réponse: 2RTT D.Naylor et al. “The Cost of S in HTTPS”, CoNEXT 2014 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+tTX tTX 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 (sans compter TLS) Slow-start pour tous les objects SYN de connexion RTT SYN+ACK ACK + GET données RTT Data + FIN Fermeture connexion FINACK 27

Interaction avec TCP Temps de réponse: 2RTT D.Naylor et al. “The Cost of S in HTTPS”, CoNEXT 2014 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+tTX tTX 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 (sans compter TLS) Slow-start pour tous les objects SYN de connexion RTT SYN+ACK ACK + GET données RTT Data + FIN Fermeture connexion FINACK 28

HTTP persistant Côté serveur Côté client (open active) SYN Il accepte la connexion, et l’annonce au client (open passive) SYN+ACK 2. Le client HTTP envoie la requête HTTP sur la connexion TCP GET 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 Data 4. Le client HTTP reçoit la réponse HTML, les URLs référencées et envoye >1 requetes (pipelining) (ou sinon le server après un timeout de k*300s ) GETs 5. Le serveur envoye les reponses sur la meme connexion dès que l’algorithme de controle de congestionde TCP le permet (cwnd) Data temps 29

Connexions 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 precedent) Au moins 2 RTTs pour recevoir chaque objet (handshake) Chaque transfert doit subir le slow-start de TCP Penalité dans pages réelles conteant nombreux petits objects Connexion Persistante Par défaut dans HTTP/1.1 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 Moins de sockets => pas de saturation des res middleboxes (NAT, NAPT) Gain en performance pour le serveur Moins de ressources employés (socket) par client => ou plus de clients servis 30

HTTP persistant: HOL Connexion persistante avec pipelining Moins de defauts que connexion ephemeres, mais pas sans defauts! Problème du Head of Line (HOL) blocking Les objets doivent etre renvoyé dans l’ordre dans lesquels sont demandés Consequence, des petits objects peuvent etre retardés par: Objets volumineux Objets computationnellement dispendieux GET 1 GET 1 GET 2 GET 2 Data 1 (Object volumineux) Data 1 (Object couteux en temps de CPU) temps Data 2 temps Data 2 31

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

Contrôle d'accès Intérêt: accès restreint 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... 33

Cookies Pros/Cons Authorisation implicite Le cookie, soit Caddies (e-commerce) État session (Web e-mail) Publicité/offre personalisé Privacy issues ? http://www.mozilla.org/en-US/collusion/demo 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 Le cookie, soit Un identificatif unique, transporté dans l’entete HTTP Permettre de l’état dans un protocole sans état Elegant, simple, scalable, espion Flexible: interpretation arbitraire RFC 2109 Quatre composantes Cookie dans HTTP request Cookie dans HTTP response Fichier cookie chez l'utilisateur et géré par le browser Database derriere le site Web 34

Cookies DB GET 200 OK Set-cookie: GET Operations specifiques au Cookie HTTP/1.1 200 OK Date: Wed, 20 Dec 2006 08:20:17 GMT Server: Apache/1.3.31 (Unix) PHP/4.4.4 mod_ssl/2.8.18 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%2F2006+%E0+09%3A20; expires=Wednesday, 27-Dec-06 08:20:18 GMT Keep-Alive: timeout=15, Connection: Keep-Alive GET /index.php?id=122 HTTP/1.1 Accept: */* Referer: http://www.test.fr/index.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 1.1.4322; .NET CLR 2.0.50727; InfoPath.2) Host: www.test.fr Connection: Keep-Alive Cookie: user=8441e98f05; TestCookieAlone=ok; Nombre_visite=6; Derniere_visite=20%2F12%2F2006+%E0+09%3A20 DB GET 200 OK Set-cookie: GET Cookie: 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 vous renvoye vers Spy.com pour envoye un cookie C, et sait que C a visité Site1 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 Site1.com Site2.com Spy.com HTML HTML <img src=spy.com/img-1.png> Img-1 Img-2 GET ,C GET SETC 36

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 Remarque Objectif Problème Solution Operation GET client a déjà dans son cache Problème les objets contenus dans le cache peuvent être obsolètes Solution GET conditionnel Operation If-modified-since: <date> serveur: la réponse est vide si la copie cachée est à jour HTTP/1.0 304 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/1.0 304 Not Modified GET If-modified-since: <date> HTTP/1.0 200 OK … Data

HTTP Redirection YouTube Frontend YouTube server GET get_video?video _id=XYZ HTTP/1.1 Geolocalisation de l’hote, choix d’un serveur video proche peu chargé HTTP/1.1 303 See other location: http://sjc-v110.sjc.youtube.com/get_video?video_id=XYZ GET get_video?video _id=XYZ HTTP/1.1 200 OK Video data

Proxy server (Cache Web) 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 la reponse, et répond ensuite Proxy = client et serveur 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é

Proxy server (Cache Web) 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 Performance moyenne dependent du cache “hit ratio”, i.e., la probabilité de trouver un objet dans le proxy Une fois le hit ratio h connu: E[RTT] = h RTTLAN + (1-h) RTTInternet E[C] = h CLAN + (1-h) CInternet Principe Le cache est proche du client 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) N 2 1 proxy …. Web Internet Netscape

HTTP/2   Connexion FTP Une connexion FTP est constituée d'une connexion full duplex qui permet de transmettre les commandes et que l'on appelle connexion de contrôle. Une fois le contrôle établi, il est nécessaire d'établir une autre connexion pour permettre le transfert des données. Il est commun de conserver le nom anglais "data connexion" pour désigner cette connexion. Le serveur FTP dispose d'un couple de port {L, L-1}. Le port L est utilisé pour la connexion de contrôle. Le port L-1 est utilisé pour la data connexion. Les ports attribués par l'IANA pour le FTP sont le 21 et le 20 pour le FTP-DATA. Le client dispose d'un port U pour la connexion de contrôle. Par défaut, c'est ce même port qui est utilisé pour la data connexion. Cependant ce port peut être changé par la commande PORT. La commande PORT permet de spécifier vers quel host et vers quel port le serveur FTP va initier la data connexion. Cette commande prend comme argument l'adresse IP de l'host et le port : PORT h1,h2,h3,h4,p1,p2 Attention ! Seul le client FTP peut changer le port FTP-DATA par défaut, par la commande PORT. La data connexion est toujours fermée par le serveur. Le serveur doit fermer la data connexion dans les cas suivants : le mode de transfert demande de terminer la connexion après le caractère de fin de fichier et l'envoi des données est fini ; le serveur a reçu une commande ABORT du client ; la spécification du port data a été changée par le client ; la connexion de contrôle est fermée, de façon normale ou anormale ; une erreur irrécupérable est survenue. FTP ACTIF Voici les différents rôles du client et du serveur FTP dans une connexion active : Client Serveur envoie les commandes FTP interprète les commandes interprète les réponses envoie les réponses ordonne au processus de transfert de donnée d'ouvrir une data connexion transfère les données Déroulement d'une connexion : - le serveur écoute sur le port L ; - le client initie la connexion de contrôle full-duplex. La connexion sera fermée par le serveur ; - le client écoute sur le port data spécifié : soit le port par défaut, soit le port donné dans la commande PORT - le serveur initie la connexion data de son port L-1 vers le port user U. La direction du transfert est déterminée par la commande de transfert FTP demandée (put, get ...) FTP PASSIF Le FTP PASSIF était utilisé à l'origine pour permettre le transfert de fichier entre deux serveurs à la demande d'un client. Tous les serveurs recoivent la connexion de commande sur le port 21 et initient la connexion de données à partir de leur port 20. Or si deux serveurs doivent communiquer ensemble, l'en d'entre eux doit attendre la connexion de données et non l'initier. Dans le cas d'une connexion passive, le client FTP contrôle les deux serveurs et demande à l'un d'entre eux de se mettre en écoute sur un port de données qui N'EST PAS le port de données par défaut (20). Ceci est fait par la commande PASV. Le client FTP reçoit l'accord du serveur passif avec en argument l'adresse IP et le port sur lequel il va attendre le flux de données. A ce moment là, le client FTP indique au serveur actif sur quel port et à quelle adresse il doit diriger sa connexion de données par la commande PORT {host, port}. Attention ! Seul un client FTP peut envoyer la commande PORT. L'avantage dans une connexion passive réside dans le fait que le serveur passif n'initie aucune connexion. Dans le cas de clients FTP sur un intranet voulant consulter un serveur FTP sur internet et devrant traverser un pare-feu, le mode FTP passif permettra de n'avoir que des flux sortants vers internet alors qu'avec du FTP actif, on aurait le flux de données qui serait entrant sur le réseau interne, ce qui n'est pas très sécurisé. Ce cas peut être simplifié en n'ayant qu'un client et un serveur. Le client demande au serveur FTP de passer en mode passif. Le serveur FTP lui envoie sur quel port et sur quelle adresse le client doit se connecter. Le client n'a plus qu'à initier une commande "CONNECT". Les Réponses FTP Chaque réponse FTP est constituée d'un nombre de trois chiffres, accompagnées ou non d'une chaîne de caractère qui explique le code de retour. Chacun de ces trois chiffres correspond à une catégorie de message. Le chiffre le plus à gauche est le plus générale et le chiffre le plus à droite est le plus détaillée. La RFC 959 sur FTP explicite les deux chiffres les plus à gauche. Voici les explications : 1yz Positive Preliminary reply la commande est acceptée et est en train d'être initiée 2yz Positive completion reply Terminée - Une autre action peut être faite 3yz Positive intermediate reply Commande acceptée mais nécessite d'autres informations 4yz Transient Negative Completion reply Commande non acceptée mais erreur temporaire 5yz Permanent Negative reply Commande non acceptée mais la commande peut être refaite. x0 SYNTAX erreur de syntaxe - commande non encore implémentée - commande superflu x1z INFORMATION demande d'autres informations comme le statut ou l'aide x2z CONNECTION relatif à la connexion de commande ou de données x3z Authentification and accounting relatif au processus de login et à la gestion des comptes utilisateurs x4z Unspecified as yet x5z FILE SYSTEM indique le statut du système de fichier vis_à_vis du transfert demandé ou d'un autre système de fichier Commandes ACCESS CONTROL COMMANDS The following commands specify access control identifiers (command codes are shown in parentheses). USER NAME (USER) The argument field is a Telnet string identifying the user. The user identification is that which is required by the server for access to its file system. This command will normally be the first command transmitted by the user after the control connections are made (some servers may require this). Additional identification information in the form of a password and/or an account command may also be required by some servers. Servers may allow a new USER command to be entered at any point in order to change the access control and/or accounting information. This has the effect of flushing any user, password, and account information already supplied and beginning the login sequence again. All transfer parameters are unchanged and any file transfer in progress is completed under the old access control parameters. PASSWORD (PASS) The argument field is a Telnet string specifying the user’s password. This command must be immediately preceded by the user name command, and, for some sites, completes the user’s identification for access control. Since password information is quite sensitive, it is desirable in general to "mask" it or suppress typeout. It appears that the server has no foolproof way to achieve this. It is therefore the responsibility of the user-FTP process to hide the sensitive password information. ACCOUNT (ACCT) The argument field is a Telnet string identifying the user’s account. The command is not necessarily related to the USER command, as some sites may require an account for login and others only for specific access, such as storing files. In the latter case the command may arrive at any time. There are reply codes to differentiate these cases for the automation: when account information is required for login, the response to a successful PASSword command is reply code 332. On the other hand, if account information is NOT required for login, the reply to a successful PASSword command is 230; and if the account information is needed for a command issued later in the dialogue, the server should return a 332 or 532 reply depending on whether it stores (pending receipt of the ACCounT command) or discards the command, respectively. CHANGE WORKING DIRECTORY (CWD) This command allows the user to work with a different directory or dataset for file storage or retrieval without altering his login or accounting information. Transfer parameters are similarly unchanged. The argument is a pathname specifying a directory or other system dependent file group designator. CHANGE TO PARENT DIRECTORY (CDUP) This command is a special case of CWD, and is included to simplify the implementation of programs for transferring directory trees between operating systems having different syntaxes for naming the parent directory. The reply codes shall be identical to the reply codes of CWD. See Appendix II for further details. STRUCTURE MOUNT (SMNT) This command allows the user to mount a different file system data structure without altering his login or accounting information. Transfer parameters are similarly unchanged. The argument is a pathname specifying a directory or other system dependent file group designator. REINITIALIZE (REIN) This command terminates a USER, flushing all I/O and account information, except to allow any transfer in progress to be completed. All parameters are reset to the default settings and the control connection is left open. This is identical to the state in which a user finds himself immediately after the control connection is opened. A USER command may be expected to follow. LOGOUT (QUIT) This command terminates a USER and if file transfer is not in progress, the server closes the control connection. If file transfer is in progress, the connection will remain open for result response and the server will then close it. If the user-process is transferring files for several USERs but does not wish to close and then reopen connections for each, then the REIN command should be used instead of QUIT. An unexpected close on the control connection will cause the server to take the effective action of an abort (ABOR) and a logout (QUIT). TRANSFER PARAMETER COMMANDS All data transfer parameters have default values, and the commands specifying data transfer parameters are required only if the default parameter values are to be changed. The default value is the last specified value, or if no value has been specified, the standard default value is as stated here. This implies that the server must "remember" the applicable default values. The commands may be in any order except that they must precede the FTP service request. The following commands specify data transfer parameters: DATA PORT (PORT) The argument is a HOST-PORT specification for the data port to be used in data connection. There are defaults for both the user and server data ports, and under normal circumstances this command and its reply are not needed. If this command is used, the argument is the concatenation of a 32-bit internet host address and a 16-bit TCP port address. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A port command would be: where h1 is the high order 8 bits of the internet host address. PASSIVE (PASV) This command requests the server-DTP to "listen" on a data port (which is not its default data port) and to wait for a connection rather than initiate one upon receipt of a transfer command. The response to this command includes the host and port address this server is listening on. REPRESENTATION TYPE (TYPE) The argument specifies the representation type as described in the Section on Data Representation and Storage. Several types take a second parameter. The first parameter is denoted by a single Telnet character, as is the second Format parameter for ASCII and EBCDIC; the second parameter for local byte is a decimal integer to indicate Bytesize. The parameters are separated by a <SP> (Space, ASCII code 32). The following codes are assigned for type: / A - ASCII | | N - Non-print |-><-| T - Telnet format effectors E - EBCDIC| | C - Carriage Control (ASA) I - Image L <byte size> - Local byte Byte size The default representation type is ASCII Non-print. If the Format parameter is changed, and later just the first argument is changed, Format then returns to the Non-print default. FILE STRUCTURE (STRU) The argument is a single Telnet character code specifying file structure described in the Section on Data Representation and Storage. The following codes are assigned for structure: F - File (no record structure) R - Record structure P - Page structure The default structure is File. TRANSFER MODE (MODE) The argument is a single Telnet character code specifying the data transfer modes described in the Section on Transmission Modes. The following codes are assigned for transfer modes: S - Stream B - Block C - Compressed The default transfer mode is Stream. FTP SERVICE COMMANDS The FTP service commands define the file transfer or the file system function requested by the user. The argument of an FTP service command will normally be a pathname. The syntax of pathnames must conform to server site conventions (with standard defaults applicable), and the language conventions of the control connection. The suggested default handling is to use the last specified device, directory or file name, or the standard default defined for local users. The commands may be in any order except that a "rename from" command must be followed by a "rename to" command and the restart command must be followed by the interrupted service command (e.g., STOR or RETR). The data, when transferred in response to FTP service commands, shall always be sent over the data connection, except for certain informative replies. The following commands specify FTP service requests: RETRIEVE (RETR) This command causes the server-DTP to transfer a copy of the file, specified in the pathname, to the server- or user-DTP at the other end of the data connection. The status and contents of the file at the server site shall be unaffected. STORE (STOR) This command causes the server-DTP to accept the data transferred via the data connection and to store the data as a file at the server site. If the file specified in the pathname exists at the server site, then its contents shall be replaced by the data being transferred. A new file is created at the server site if the file specified in the pathname does not already exist. STORE UNIQUE (STOU) This command behaves like STOR except that the resultant file is to be created in the current directory under a name unique to that directory. The 250 Transfer Started response must include the name generated. APPEND (with create) (APPE) This command causes the server-DTP to accept the data transferred via the data connection and to store the data in a file at the server site. If the file specified in the pathname exists at the server site, then the data shall be appended to that file; otherwise the file specified in the pathname shall be created at the server site. ALLOCATE (ALLO) This command may be required by some servers to reserve sufficient storage to accommodate the new file to be transferred. The argument shall be a decimal integer representing the number of bytes (using the logical byte size) of storage to be reserved for the file. For files sent with record or page structure a maximum record or page size (in logical bytes) might also be necessary; this is indicated by a decimal integer in a second argument field of the command. This second argument is optional, but when present should be separated from the first by the three Telnet characters <SP> R <SP>. This command shall be followed by a STORe or APPEnd command. The ALLO command should be treated as a NOOP (no operation) by those servers which do not require that the maximum size of the file be declared beforehand, and those servers interested in only the maximum record or page size should accept a dummy value in the first argument and ignore it. RESTART (REST) The argument field represents the server marker at which file transfer is to be restarted. This command does not cause file transfer but skips over the file to the specified data checkpoint. This command shall be immediately followed by the appropriate FTP service command which shall cause file transfer to resume. RENAME FROM (RNFR) This command specifies the old pathname of the file which is to be renamed. This command must be immediately followed by a "rename to" command specifying the new file pathname. RENAME TO (RNTO) This command specifies the new pathname of the file specified in the immediately preceding "rename from" command. Together the two commands cause a file to be renamed. ABORT (ABOR) This command tells the server to abort the previous FTP service command and any associated transfer of data. The abort command may require "special action", as discussed in the Section on FTP Commands, to force recognition by the server. No action is to be taken if the previous command has been completed (including data transfer). The control connection is not to be closed by the server, but the data connection must be closed. There are two cases for the server upon receipt of this command: (1) the FTP service command was already completed, or (2) the FTP service command is still in progress. In the first case, the server closes the data connection (if it is open) and responds with a 226 reply, indicating that the abort command was successfully processed. In the second case, the server aborts the FTP service in progress and closes the data connection, returning a 426 reply to indicate that the service request terminated abnormally. The server then sends a 226 reply, indicating that the abort command was successfully processed. DELETE (DELE) This command causes the file specified in the pathname to be deleted at the server site. If an extra level of protection is desired (such as the query, "Do you really wish to delete?"), it should be provided by the user-FTP process. REMOVE DIRECTORY (RMD) This command causes the directory specified in the pathname to be removed as a directory (if the pathname is absolute) or as a subdirectory of the current working directory (if the pathname is relative). See Appendix II. MAKE DIRECTORY (MKD) This command causes the directory specified in the pathname to be created as a directory (if the pathname is absolute) or as a subdirectory of the current working directory (if the pathname is relative). See Appendix II. PRINT WORKING DIRECTORY (PWD) This command causes the name of the current working directory to be returned in the reply. See Appendix II. LIST (LIST) This command causes a list to be sent from the server to the passive DTP. If the pathname specifies a directory or other group of files, the server should transfer a list of files in the specified directory. If the pathname specifies a file then the server should send current information on the file. A null argument implies the user’s current working or default directory. The data transfer is over the data connection in type ASCII or type EBCDIC. (The user must ensure that the TYPE is appropriately ASCII or EBCDIC). Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user. NAME LIST (NLST) This command causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor; a null argument implies the current directory. The server will return a stream of names of files and no other information. The data will be transferred in ASCII or EBCDIC type over the data connection as valid pathname strings separated by <CRLF> or <NL>. (Again the user must ensure that the TYPE is correct.) This command is intended to return information that can be used by a program to further process the files automatically. For example, in the implementation of a "multiple get" function. SITE PARAMETERS (SITE) This command is used by the server to provide services specific to his system that are essential to file transfer but not sufficiently universal to be included as commands in the protocol. The nature of these services and the specification of their syntax can be stated in a reply to the HELP SITE command. SYSTEM (SYST) This command is used to find out the type of operating system at the server. The reply shall have as its first word one of the system names listed in the current version of the Assigned Numbers document [4]. STATUS (STAT) This command shall cause a status response to be sent over the control connection in the form of a reply. The command may be sent during a file transfer (along with the Telnet IP and Synch signals—see the Section on FTP Commands) in which case the server will respond with the status of the operation in progress, or it may be sent between file transfers. In the latter case, the command may have an argument field. If the argument is a pathname, the command is analogous to the "list" command except that data shall be transferred over the control connection. If a partial pathname is given, the server may respond with a list of file names or attributes associated with that specification. If no argument is given, the server should return general status information about the server FTP process. This should include current values of all transfer parameters and the status of connections. HELP (HELP) This command shall cause the server to send helpful information regarding its implementation status over the control connection to the user. The command may take an argument (e.g., any command name) and return more specific information as a response. The reply is type 211 or 214. It is suggested that HELP be allowed before entering a USER command. The server may use this reply to specify site-dependent parameters, e.g., in response to HELP SITE. NOOP (NOOP) This command does not affect any parameters or previously entered commands. It specifies no action other than that the server send an OK reply. The File Transfer Protocol follows the specifications of the Telnet protocol for all communications over the control connection. Since the language used for Telnet communication may be a negotiated option, all references in the next two sections will be to the "Telnet language" and the corresponding "Telnet end-of-line code". Currently, one may take these to mean NVT-ASCII and <CRLF>. No other specifications of the Telnet protocol will be cited. Code de retour 110 Restart marker reply. In this case, the text is exact and not left to the particular implementation; it must read: MARK yyyy = mmmm Where yyyy is User-process data stream marker, and mmmm server’s equivalent marker (note the spaces between markers and "="). 120 Service ready in nnn minutes. 125 Data connection already open; transfer starting. 150 File status okay; about to open data connection. 200 Command okay. 202 Command not implemented, superfluous at this site. 211 System status, or system help reply. 212 Directory status. 213 File status. 214 Help message. On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user. 215 NAME system type. Where NAME is an official system name from the list in the Assigned Numbers document. 220 Service ready for new user. 221 Service closing control connection. Logged out if appropriate. 225 Data connection open; no transfer in progress. 226 Closing data connection. Requested file action successful (for example, file transfer or file abort). 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). 230 User logged in, proceed. 250 Requested file action okay, completed. 257 "PATHNAME" created. 331 User name okay, need password. 332 Need account for login. 350 Requested file action pending further information. 421 Service not available, closing control connection. This may be a reply to any command if the service knows it must shut down. 425 Can’t open data connection. 426 Connection closed; transfer aborted. 450 Requested file action not taken. File unavailable (e.g., file busy). 451 Requested action aborted: local error in processing. 452 Requested action not taken. Insufficient storage space in system. 500 Syntax error, command unrecognized. This may include errors such as command line too long. 501 Syntax error in parameters or arguments. 502 Command not implemented. 503 Bad sequence of commands. 504 Command not implemented for that parameter. 530 Not logged in. 532 Need account for storing files. 550 Requested action not taken. File unavailable (e.g., file not found, no access). 551 Requested action aborted: page type unknown. 552 Requested file action aborted. Exceeded storage allocation (for current directory or dataset). 553 Requested action not taken. File name not allowed. Copyright © Teamlog 2002/2003 - Tous droits réservés     42

Agenda Recap sur le limites de HTTP Pourquoi a-t-on besoin d’un remplacant? Introduction aux features de HTTP/2 Brievement dans le cours Plus longuement dans les lectures obligatoires Comparatif de peformances HTTP vs HTTP/2 Introduction en cours Comparatif directe par les usagers, pendant le TP

Agenda Recap sur le limites de HTTP Pourquoi a-t-on besoin d’un remplacant? Introduction aux features de HTTP/2 Brievement dans le cours Plus longuement dans les lectures obligatoires Comparatif de peformances HTTP vs HTTP/2 Introduction en cours Comparatif directe par les usagers, pendant le TP

Limites de HTTP Simple HTTP/1.0 HTTP/1.1 KISS raison de son succès Limite de ses performance HTTP/1.0 Connexions ephèmeres, possiblement en parallel HTTP/1.1 Connexions persistentes avec pipelining SYN SYN+ACK ACK GET Webpage time

Limites de HTTP Simple HTTP/1.0 HTTP/1.1 KISS raison de son succès Limite de ses performance HTTP/1.0 Connexions ephèmeres, possiblement en parallel HTTP/1.1 Connexions persistentes avec pipelining SYN Round Trip Time (RTT) SYN+ACK ACK GET Webpage Ouverture de connexion TCP Negociation TLS/SSL time

Limites de HTTP Simple HTTP/1.0 HTTP/1.1 KISS raison de son succès Limite de ses performance HTTP/1.0 Connexions ephèmeres, possiblement en parallel HTTP/1.1 Connexions persistentes avec pipelining SYN SYN+ACK ACK+GET Webpage+FIN FIN+ACK SYN SYN+ACK ACK+GET Object1+FIN FIN+ACK SYN Délai inutile Petite fenêtre en debut de connexion SYN+ACK ACK+GET ObjectN+FIN

Limites de HTTP Simple HTTP/1.0 HTTP/1.1 KISS raison de son succès Limite de ses performance HTTP/1.0 Connexions ephèmeres, possiblement en parallel HTTP/1.1 Connexions persistentes avec pipelining SYN SYN+ACK ACK+GET Webpage FIN SYN SYN+ACK ACK+GET Object1… ObjectN +FIN Usage de plusieurs connexion en parallel pour masquer le delai d’établissement Limite au nombre de connections TCP par domaine Diffusion du “Sharding” i.e., diviser le contenu sur plusieurs domaines pour contourner cela

Limites de HTTP Simple HTTP/1.0 HTTP/1.1 KISS raison de son succès Limite de ses performance HTTP/1.0 Connexions ephèmeres, possiblement en parallel HTTP/1.1 Connexions persistentes avec pipelining SYN SYN+ACK ACK+GET Webpage+FIN ACK+GETs Object1… ObjectN Moins de ouverture de connexion Moins de slow starts

Limites de HTTP Simple & stateless HTTP/1.0 HTTP/1.1 KISS reason of its success Curse of its performance HTTP/1.0 Ephemeral connections, possibly parallel HTTP/1.1 Persistent connections with pipelining SYN SYN+ACK ACK+GET Webpage+FIN ACK+GETs Head of Line blocking (objets volumineux ou couteux de CPU) Moins tolerant au pertes HoL blocking Object1… ObjectN

Agenda Recap sur le limites de HTTP Pourquoi a-t-on besoin d’un remplacant? Introduction aux features de HTTP/2 Brievement dans le cours Plus longuement dans les lectures obligatoires Comparatif de peformances HTTP vs HTTP/2 Introduction en cours Comparatif directe par les usagers, pendant le TP

Introduction à HTTP/2 Significativement plus complexe Binarire, comprimé et encripté par default Compression d’entetes (HPACK RFC) Protocole de session, supports de plusieus “streams” Priorité des streams pour éviter HOL “Server push” pour le prefetch des données D’ou commencer SPDY: An experimental protocol for a faster web, Google whitepaper Daniel Stenberg HTTP2 explained [CACM’12] Bryce Thomas, Raja Jurdak and Ian Atkinson. SPDYing up the web, Communications of the ACM, Vol. 55. No. 12, pp. 64-73, December 2012

Introduction à HTTP/2 Binary Streams [CACM’12]

Introduction à HTTP/2 HPACK (RFC7541) [CACM’12]

Introduction à HTTP/2 Server push [CACM’12]

Introduction à HTTP/2 TLS by default [CACM’12]

Agenda Recap sur le limites de HTTP Pourquoi a-t-on besoin d’un remplacant? Introduction aux features de HTTP/2 Brievement dans le cours Plus longuement dans les lectures obligatoires Comparatif de peformances HTTP vs HTTP/2 Introduction en cours Comparatif directe par les usagers, pendant le TP

Titre deceptif; en realité HTTP vs HTTP/2 Qui est mieux? Voir par example chrome http://www.httpvshttps.com/ Titre deceptif; en realité HTTP vs HTTP/2

Mesure de performance Trois familles de metriques Quality of Service Objective Generiques Pas tjrs pertinent Facile à obtenir Delay, Jitter Loss rate, Reordering Throughput, Goodput Fairness Quality of Experience Objective Specifique à application Potentiellement pertinent Facile/Difficile à obtenir Completion time Startup delay Rebuffering, quality switch PSNR/PEVQ/SSim User feedback Subjective Specifique à application Souvent très pertinent Difficile à obtenir Rating Free form Notre focus par la suite

Mesure de performance Rappel cours QoS vs QoE Echelles de temps de perception humaine Que disent les industriels? Accord de fond: Délai metrique primaire Industry : 400ms delai réduit recherches de 0.7% (=ads (=$)) : 500ms (2sec) réduit recherches de 1.2% (4.8%) : 5sec réduction delai, +25% visites, +12% chiffre d’affaires : resultats du PageRank ont un (faible) poids basé sur la latence de la page

30+ connections en mediane Mesure de performance Rappel: page Web complexes! Latence de quel objet?? http://httparchive.org/interesting.php#reqTotal 100 objects en moyenne 200+ dans 5% des cas http://httparchive.org/interesting.php#connections 30+ connections en mediane http://httparchive.org/trends.php?s=All&minlabel=Dec+16+2010&maxlabel=Dec+1+2015 20+ javascript en moyenne

Web QoE ~ Webpage Gantt chart Waterfall Instants Integrales Evenements réseau Evenements navigateur Instants Integrales Time to the First Byte (TTFB) Time to the First Paint (TTFP) Document Object Model (DOM) Above the fold view Time to the First Interaction (TTFI) OnLoad Speed Index Byte Index Object Index Cfr [InternetQoE’16] pour definitions

Web QoE ~ Webpage Gantt chart Waterfall Instants Integrales Evenements réseau Evenements navigateur Instants Integrales Time to the First Byte (TTFB) Time to the First Paint (TTFP) Document Object Model (DOM) Above the fold view Time to the First Interaction (TTFI) OnLoad Speed Index Byte Index Object Index Common Approx Cfr [InternetQoE’16] pour definitions

Waterfall (Réseaux) Evénements liés au réseau e.g., DNS, connect, send, wait, receive, SSL

WebQoE: Instants de temps Evénements liés au réseau e.g., DNS, connect, send, wait, receive, SSL TTFB Premier paquet avec donnés applicatives Document Object Model Loaded Document HTML reçu et interpreté Pas encore d’images, photos, styles, … On Load Toutes les resources de la page ont été téléchargé et affichés

Waterfall (Navigateur) Evenement liés au navigateur e.g., Loading, scripting, rendering, painting

WebQoE: Integrales dans le temps Speed Index: Progres visuel de la page Pros: proche à la perception des usagers Cons: computationellement couteux, peu homogene (PC, mobile) WebPagetest, April 2012 http://www.webpagetest.org/

Prends en compte tous les instants de temps Speed Index: Theorie https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index Le plus faible, le mieux   TTFB ≤ TTFP ≤ ≤ onLoad %Affiché(t) Prends en compte tous les instants de temps %Manquant(t) Cfr [InternetQoE’16]

OnLoad avec Speed Index Speed Index: Pratique Problèmes de deployment Lourd: Complexe, change la durée meme des pages! Approximé: Pixel-par-pixel VS histogramme Inhomogène: Capture video VS events d’affichage Espace: Pas de bias spatiale (centre VS coins de l’ecran) WebPage DOM OnLoad OnLoad avec Speed Index Inflation www.telecom-paristech.fr 1,79s 2,34s 5,33s +227% www.polito.it 0,53s 0,95s 3,60s +379% Cfr [InternetQoE’16]

Speed Index: Approximation Similar to Speed Index but based on network measurements PROS:easier to compute, browser rendering not needed CONS:not as close to user experience, unbounded Byte Index 𝐵𝑦𝑡𝑒 𝐼𝑛𝑑𝑒𝑥= 𝑏𝑒𝑔𝑖𝑛 𝑒𝑛𝑑 1 − 𝑑𝑜𝑤𝑛𝑙𝑜𝑎𝑑𝑒𝑑_𝑏𝑦𝑡𝑒𝑠 𝑡𝑜𝑡𝑎𝑙_𝑏𝑦𝑡𝑒𝑠 𝑑𝑡 Object Index 𝑂𝑏𝑗𝑒𝑐𝑡 𝐼𝑛𝑑𝑒𝑥= 𝑏𝑒𝑔𝑖𝑛 𝑒𝑛𝑑 1 − 𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒_𝑜𝑏𝑗𝑒𝑐𝑡𝑠 𝑡𝑜𝑡𝑎𝑙_𝑜𝑏𝑗𝑒𝑐𝑡𝑠 𝑑𝑡 Approximation du SpeedIndex Pros: proche à la definition du SpeedIndex Cons: computationellement simple Cfr [InternetQoE’16]

Integrale dans le temps WebQoE: summaire Qu’est-ce qu’on peut mesurer, et à quel niveau? Metric Type Complexité L3 L4 L7 TTFB Instant de temps Faible ✓* ✓ DOM OnLoad Speed Index Integrale dans le temps Elevée ✓ Byte Index Faible Object Index *Approximation (TCP handshake, SSL/TLS negotiations ) Cfr [InternetQoE’16]

Aperçu du TP: Testbed Web server Hébergement locale de vraies pages Web Apache servers (un par domaine, controle du protocole L7) Client Navigateur chrome standard (DNS hijacking via /etc/hosts) Interfaces virtuelles (controle du réseau)

Additional Latency – Loss Aperçu du TP: scenario Web server Hébergement locale de vraies pages Web Apache servers (un par domaine, controle du protocole L7) Client Navigateur chrome standard (DNS hijacking via /etc/hosts) Exp No. Web page Proto Obj Num Size [MB] Domain Additional Latency – Loss 1 HTTP 361 0.90 0ms – 0% 2 HTTPS 3 H2 4 China Daily 212 3.23 16 5 6 LCL Banque et Assurance 103 1.59 7 8 Leroy Merlin 66 0.87 11 9 10 Darty 143 2.24 33 +100ms – 0% 12 Amazon.fr 215 5.52 0ms – 2% 13 Interfaces virtuelles (controle du réseau) Examples de scénarios

Additional Latency – Loss Aperçu du TP: serveur <VirtualHost 10.0.0.1:443> ServerName api.zanox.com DocumentRoot /home/server/apache2-007/api.zanox.com ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined Protocols http/1.1 h2 SSLEngine on SSLCertificateFile /etc/apache2-007/ssl/apache-007.crt SSLCertificateKeyFile /etc/apache2-007/ssl/apache-007.key </VirtualHost> Web server Local controlled hosting of real webpages Apache servers (one per sharded domain, control L7 Protocol) Client Unmodified chrome browser (DNS hijacking via /etc/hosts) Exp No. Web page Proto Obj Num Size [MB] Domain Additional Latency – Loss 1 HTTP 361 0.90 0ms – 0% 2 HTTPS 3 H2 4 China Daily 212 3.23 16 5 6 LCL Banque et Assurance 103 1.59 7 8 Leroy Merlin 66 0.87 11 9 10 Darty 143 2.24 33 +100ms – 0% 12 Amazon.fr 215 5.52 0ms – 2% 13 Interfaces virtuelles (controle du réseau)

Orchestrateur d’experience Aperçu du TP: clients Web server Hébergement locale de vraies pages Web Apache servers (un par domaine, controle du protocole L7) Client Navigateur chrome standard (DNS hijacking via /etc/hosts) Config Interfaces virtuelles (controle du réseau) 10.0.0.1 www.leroymerlin.fr 10.0.0.2 s2.lmcdn.fr 10.0.0.5 s1.lmcdn.fr 10.0.0.5 pixel.mathtag.com … Orchestrateur d’experience (PageX, ProtocolY, networkZ) Pas si

Aperçu du TP: experience Web server Hébergement locale de vraies pages Web Apache servers (un par domaine, controle du protocole L7) Client Navigateur chrome standard (DNS hijacking via /etc/hosts) Webpage Interfaces virtuelles (controle du réseau) Orchestrateur d’experience (PageX, ProtocolY, networkZ)

Aperçu du TP: qualité d’experience Web server Hébergement locale de vraies pages Web Apache servers (un par domaine, controle du protocole L7) Client Navigateur chrome standard (DNS hijacking via /etc/hosts) HAR Interfaces virtuelles (controle du réseau) User MOS User MOS evaluation =bad… =pretty bad =pretty good Orchestrateur d’experience (PageX, ProtocolY, networkZ)

Aperçu du TP: 3 phases Rechauffement Execution Analyse Crowdsourcing “Toy case” example on illustrational unrealistic page Prise en main des outils Execution Collection de donnés: experience (HAR) et qualité (MOS) Pas de connaissance de condition réseau/application Analyse Inspection des donnés: deviner quel protocole utilisé dans quelle experience QoS vs QoE: comparaison de metriques (avec connaissance) Crowdsourcing Partager les données et étudier un echantillon plus large de la population (difficile; potentiellement dans la fenetre sur la recherche)

Après TP (1/2) L’inverse d’un TP habituel Pas de compte rendu redigé par les étudiants Document de synthèse redigé par les encadrants sur la base des experiences que vous avez effectué (voir http://goo.gl/Injnr5) Il n’existe pas de bonne reponse au TP Personne ne connait la reponse à ce jour: vous aidez à la construire pendant votre apprentissage Il n’existe pas de reponse facile Au quotidien, pas de solution prete, que des methode pour l’atteindre Methodologie Proche à celle de la recherche (n’hesitez pas à demander si interessé) Formation de l’exprit critique

Après TP (2/2) Possibilité de Projet libre/Stage Examples contenu Orange Mesure systematique de la QoE des top 100 Alexa depuis 100 villes Analyse de l’impacte des condition réseaux sur HTTP2 Implementation d’un plugin Chrome {Byte,Object}Index Modele de regression du MOS à partir de la QoE (forecast) Etude de QUIC (avec methode similaire) Propose Your own

References (1/2) Lectures obligatoires Lectures optionnelles A partir de la page Web du cours. Accessiles depuis ENST, ou en VPN PPTP, ou via LMGTFY (eg. https://lmgtfy.com/?q=SPDYing+up+the+web ) Lectures optionnelles J.C. Mogul, The case for persistent-connections HTTP, ACM SIGCOMM 1995 http://dl.acm.org/citation.cfm?id=217465 [InternetQoE’16] E. Bocchi et al. “Measuring the Quality of Experience of Web users”. In ACM SIGCOMM 2016, Workshop on QoE-based Analysis and Management of Data Communication Networks (Internet-QoE)

References (2/2) Lectures optionnelles Page Web plutot “recherche” Avec code, dataset, articles http://goo.gl/Injnr5 https://perso.telecom-paristech.fr/~drossi/index.php?n=Dataset.WebMOS

?? || // 83