RES 203 Applications Internet World Wide Web dario

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

Plan • World wide web Legende: le slide n’est pas objet l’examen • 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 Web. Qo. E et au TP • Avant /après TP: • Avant: Lectures obligatoires • Apres: Stages projets Orange

Histoire du World Wide Web (1/2) 1945 1965 1989 1993 1994 1995 1999 Vannevar Bush: “memex” Ted Nelson: “Hypertext” Tim Berners Lee: “Mesh” – 1 ere demo publique du “Web” Marc Andressen: “Netscape” – 1 ere demo publique du browser World Wide Web Consortium (http: //www. w 3 c. org) Hypertext Transfer Protocol -- HTTP/1. 0 (RFC 1945) Hypertext Transfer Protocol -- HTTP/1. 1 (RFC 2616) Watching the Waist of the Protocol Hourglass Steve Deering @IETF 51 (2001) . . only time will tell Evolution of the IP Model Dave Thaler @IETF 73 (2009)

Histoire recente • 05/2008 • 09/2010 • 08/2012 • 08/2013 • 07/2013 • 02/2015 • 05/2015 • 12/2015 • 06/2016 You. Tube 2 eme moteur de recherche Google annonce SPDY (alternative à HTTP sur TCP) HTTP/2 draft v 0 draft-ietf-httpbis-http 2 Google delivre QUIC (alternative à HTTP & TCP sur UDP) Premier HTTP/2 draft “implementable” (v 4) Google annonce qu’il abandonne SPDY en faveur de HTTP/2 RFC 7540 released (after v 17) Google etains QUIC completement (? ? !!) ----- Forwarded message ----IETF Berlin: QUIC Bo. F 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 <ingemarj 65@gmail. com> wrote: Hi http: //tstat. polito. it/cgi-bin/tstat_rrd. cgi? dir=rrd_data/Polito/Live&var=udp_bitrate&exclude=&include=&template=&hifreq=false&duration=1 m&bigpic=true&logscale=& direction=both Is QUIC currently enabled ?

Architecture du Web

Architecture du Web Client HTTP protocole HTTP Browser HTTP Proxies Interaction HTTP / TCP HTML Serveur HTTP Server Focus de RES 224 RES 240

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) Geo. Cities was shut down 26 Oct 2009. There were at least 38 million userbuilt pages.

Architecture du Web • Server farms –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

Architecture du Web • CDN –Specialisés dans la diffusion du contenu –Redirection des requetes • via DNS • (cfr optional readings) • via HTTP redirection • (plus loin dans le cours) –Multi-B$ business User CDN AS 1 AS 4 AS 2 CDN • ~30 market players • Akamai, Limelight CDN er Rout CDN Video Server AS 3

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 http: //y. x. com Agents utilisateur • Browser –MS Internet Explorer, Firefox, Chrome, . . • Crawler, spider –Wget, Deeper. Web, Web. Crawler, … Daemon • Server Web : –Apache, Google Web server, MS Internet Information Server, … • Proxy server –Squid cache, Apache Traffic Server, … Internet 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… –…mais aussi parametres (cfr plus tard), etc. et ils peuvent donc –devenir arbitrairement compliqué…

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

Pages web dynamiques (simpliste) • Contenu 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

Pages web (réelles) http: //httparchive. org/interesting. php#req. Total (b) http: //httparchive. org/interesting. php#connections

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

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é –HTTP 1. 0 : RFC 1945 –HTTP 1. 1 : RFC 2068 Win 95 IE 5 st p htt ue q e r h r p t t e spo nse he c a Ap ix Un Machine Unix Netscape Internet htt p res pon se req ues t Linux Firefox

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 Lignes d’entête User-agent: Mozilla/4. 0 Accept: text/html, image/gif, image/jpeg Accept-language: fr Ligne vide

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

Semantique des messages HTTP 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

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=ba

Semantique des messages HTTP Entetes

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

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 SYN 1 a. Le client HTTP initie une connexion TCP au serveur HTTP sur le port 80 (open active) SYN+ACK 5. Le client HTTP reçoit la réponse contenant le fichier HTML, l’affiche, et trouve les URLs référencées temps 2. Le client HTTP envoie les requêtes HTTP (contenant des URLs) sur la connexion TCP GET Data FIN 1 b. 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

Interaction avec TCP Temps de réponse: 2 RTT • Un RTT pour la connexion TCP • Un RTT pour la requete HTTP et le premier segment TCP de la reponse HTTP (~1460 octets) SYN Temps de completement: 2 RTT+t. TX • t. TX depends de l’etat de la connexion • Slow start: 1, 2, 4, 8, … segments par RTT au debut RTT 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 RTT Etablissement de connexion SYN+ACK + GET Transfert de données Data + FINACK Fermeture connexion

Interaction avec TCP D. Naylor et al. “The Cost of S in HTTPS”, Co. NEXT 2014 Temps de réponse: 2 RTT • Un RTT pour la connexion TCP • Un RTT pour la requete HTTP et le premier segment TCP de la reponse HTTP (~1460 octets) SYN Temps de completement: 2 RTT+t. TX • t. TX depends de l’etat de la connexion • Slow start: 1, 2, 4, 8, … segments par RTT au debut RTT 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 RTT Etablissement de connexion SYN+ACK + GET Transfert de données Data + FINACK Fermeture connexion

HTTP persistant Côté serveur Côté client SYN 1 a. Le client HTTP initie une connexion TCP au serveur HTTP sur le port 80 (open active) SYN+ACK 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) temps 6. Une fois la page completé, le browser ferme la connexion (ou sinon le server après un timeout de k*300 s ) GET Data GETs Data 1 b. 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)

Connexions Persistantes et Pipelining Connexion non-persistante Connexion Persistante • HTTP/1. 0 • Par défaut dans HTTP/1. 1 • Le serveur interprète les requêtes, répond • Une seule connexion TCP et ferme la 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 Probleme (cfr slide precedent) pour envoyer une nouvelle requete • Au moins 2 RTTs pour recevoir chaque objet (handshake) • Chaque transfert doit subir Performance le slow-start de TCP • Gain en performance pour le client • Penalité dans pages réelles conteant –Moins de RTTs en debut de connexion nombreux petits objects => 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

HTTP persistant: HOL Connexion persistante avec pipelining GET 1 GET 2 Data 1 (Object volumineux) Data 1 (Object couteux en temps de CPU) Data 2 temps 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 temps Moins de defauts que connexion ephemeres, mais pas sans defauts! Data 2

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 GET 401: authorization req. WWW authenticate: GET Authorization: <cred> 200 OK. . . • Totalement insecure –sauf si utilisé avec SSL/TLS (Secure Socket Layer / Transport Layer Security) GET Authorization: <cred> 200 OK. . .

Cookies 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 Pros/Cons • Authorisation implicite • Caddies (e-commerce) • État session (Web e-mail) • Publicité/offre personalisé • Privacy issues ? http: //www. mozilla. org/en. US/collusion/demo 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 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

Cookies GET /index. php? id=122 HTTP/1. 1 Accept: */* Referer: http: //www. test. fr/index. php? i d=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; Info. Path. 2) Host: www. test. fr Connection: Keep-Alive Cookie: user=8441 e 98 f 05; Test. Cookie. Alone=ok; Nombre_visite=6; Derniere_visite=20%2 F 12%2 F 2 006+%E 0+09%3 A 20 GET 200 OK Set-cookie: GET Cookie: 200 OK Contenu personalisé 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 Open. SSL/0. 9. 6 b X-Powered-By: PHP/4. 4. 4 Set-Cookie: user=8441 e 98 f 05; Nombre_visite=6; expires=Wednesday, 27 -Dec-06 08: 20: 18 GMT Set-Cookie: Derniere_visite=20%2 F 12%2 F 2 006+%E 0+09%3 A 20; expires=Wednesday, 27 -Dec-06 08: 20: 18 GMT Keep-Alive: timeout=15, Connection: Keep-Alive DB Operations specifiques au Cookie

Espionnage avec les Cookies • et representent des image 1 x 1 pixels, de couleur transparent ne sont pas hebergés sur site 1. com, … mais sur spy. com Site 1. com Site 2. com <img src=spy. com/img-1. png> HTML Spy. com Img-1 Img-2 HTML GET • Site 1. 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é Site 1 • Quand vous visitez Site 2. 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 , C SETC

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/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 You. Tube Web Frontend GET get_video? video _id=XYZ HTTP/1. 1 303 See other location: http: //sjcv 110. sjc. youtube. com/g et_video? video_id=XYZ GET get_video? video _id=XYZ HTTP/1. 1 200 OK Video data You. Tube video server Geolocalisation de l’hote, choix d’un serveur video proche peu chargé

Proxy server (Cache Web) Proxy 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é Web server 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

Proxy server (Cache Web) Principe • Le cache est proche du client • Cache partagé par tous les • clients du meme reseau …. 2 1 eb N W pr ox y Performance • Réduction du temps de réponse –Delai plus faible en LAN (<1 ms) que sur Internet (parfois >100 ms) –Capacité plus importante en LAN Cout (Gbps) que sur le lien d’acces • Réduction du débit à l’acces, economie de • Performance moyenne dependent du bande passante dans le coeur cache “hit ratio”, i. e. , la probabilité de • Réduction du Opex (facture ISP) avec trouver un objet dans le proxy investissement Capex (serveur proxy) • Une fois le hit ratio h connu: E[RTT] = h RTTLAN + (1 -h) RTTInternet E[C] = h CLAN + (1 -h) CInternet Machine Internet. Unix Netscape

HTTP/2

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 lectures obligatoires • Comparatif de peformances HTTP vs HTTP/2 – Introduction en cours – Comparatif directe par les usagers, pendant le TP

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

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

Limites de HTTP • Simple – KISS raison de son succès – Limite de ses performance SYN+ACK ACK+GET Webpage+FIN • HTTP/1. 0 – Connexions ephèmeres, possiblement en parallel • HTTP/1. 1 FIN+ACK SYN+ACK ACK+GET Object 1+FIN – Connexions persistentes avec pipelining • Délai inutile FIN+ACK SYN • Petite fenêtre en ACK+GET debut de connexion SYN+ACK Object. N+FIN

Limites de HTTP • Simple – KISS raison de son succès – Limite de ses performance SYN ACK+GET • HTTP/1. 0 – Connexions ephèmeres, possiblement en parallel • HTTP/1. 1 – Connexions persistentes avec pipelining SYN+ACK Webpage FIN SYN+ACK ACK+GET Object 1… Object. N +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 – KISS raison de son succès – Limite de ses performance SYN+ACK ACK+GET • HTTP/1. 0 – Connexions ephèmeres, possiblement en parallel • HTTP/1. 1 – Connexions persistentes avec pipelining Webpage+FIN ACK+GETs Object 1… Object. N • Moins de ouverture de connexion • Moins de slow starts

Limites de HTTP • Simple & stateless – KISS reason of its success – Curse of its performance SYN+ACK ACK+GET • HTTP/1. 0 Webpage+FIN ACK+GETs – Ephemeral connections, • Head of Line blocking possibly parallel • HTTP/1. 1 – Persistent connections with pipelining (objets volumineux ou couteux de CPU) • Moins tolerant au pertes Ho. L blocking Object 1… Object. N

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 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 HTTP 2 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 (RFC 7541) [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 lectures obligatoires • Comparatif de peformances HTTP vs HTTP/2 – Introduction en cours – Comparatif directe par les usagers, pendant le TP

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 Quality of Experience User feedback Objective Generiques Pas tjrs pertinent Facile à obtenir Subjective Specifique à application Souvent très pertinent Difficile à obtenir • Delay, Jitter • Loss rate, Reordering • Throughput, Goodput • Fairness Objective Specifique à application Potentiellement pertinent Facile/Difficile à obtenir • Completion time • Startup delay • Rebuffering, quality switch • PSNR/PEVQ/SSim • Rating • Free form Notre focus par la suite

Mesure de performance • Rappel cours Qo. S vs Qo. E • Echelles de temps de perception humaine Industry • Que disent les industriels? : 400 ms delai réduit recherches de 0. 7% (=ads (=$)) : 500 ms (2 sec) réduit recherches de 1. 2% (4. 8%) : 5 sec réduction delai, +25% visites, +12% chiffre d’affaires • : resultats du Page. Rank ont un (faible) poids basé sur la latence de la page • • Accord de fond: Délai metrique primaire

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

Web Qo. E ~ Webpage Gantt chart • Waterfall § Evenements réseau § Evenements navigateur Instants Integrales • Speed Index • Time to the First Byte (TTFB) • Byte Index • Time to the First Paint (TTFP) • Object Index • Document Object Model (DOM) • Above the fold view • Time to the First Interaction (TTFI) • On. Load Cfr [Internet. Qo. E’ 16] pour definitions

Web Qo. E ~ Webpage Gantt chart • Waterfall § Evenements réseau § Evenements navigateur Common Instants Integrales • Speed Index • Time to the First Byte (TTFB) • Byte Index • Time to the First Paint (TTFP) • Object Index • Document Object Model (DOM) • Above the fold view • Time to the First Interaction (TTFI) • On. Load Approx Cfr [Internet. Qo. E’ 16] pour definitions

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

Web. Qo. E: 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

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

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

Speed Index: Pratique Problèmes de deployment § Lourd: Complexe, change la durée meme des pages! Web. Page DOM On. Load avec Speed Index Inflation www. telecom-paristech. fr 1, 79 s 2, 34 s 5, 33 s +227% www. polito. it 0, 53 s 0, 95 s 3, 60 s +379% § 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) Cfr [Internet. Qo. E’ 16]

Speed Index: Approximation du Speed. Index • §Pros: proche à la definition du Speed. Index §Cons: computationellement simple Cfr [Internet. Qo. E’ 16]

Web. Qo. E: summaire • Qu’est-ce qu’on peut mesurer, et à quel niveau? Metric TTFB DOM On. Load Speed Index Byte Index Object Index Type Complexité Instant de temps Integrale dans le temps L 3 L 4 L 7 ✓* ✓ ✓ Faible ✓ ✓ Elevée Faible ✓ ✓ ✓ *Approximation (TCP handshake, SSL/TLS negotiations ) Cfr [Internet. Qo. E’ 16]

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

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

Aperçu du TP: serveur <Virtual. Host 10. 0. 0. 1: 443> Web server Apache servers Server. Name api. zanox. com Local controlled (one per sharded domain, Document. Root /home/server/apache 2 -007/api. zanox. com control L 7 Protocol) hosting of real Client Error. Log ${APACHE_LOG_DIR}/error. log webpages Custom. Log ${APACHE_LOG_DIR}/access. log combined Additional Unmodified chrome. Obj browser Exp Size Web page Proto Domain Latency – No. hijacking via /etc/hosts) Num [MB] (DNS Loss 1 2 3 4 5 6 Protocols HTTP http/1. 1 h 2 HTTPS 361 0. 90 1 0 ms – 0% H 2 SSLEngine on HTTPS China 212 3. 23 16 0 ms – 0% /etc/apache 2 -007/ssl/apache-007. crt H 2 Daily SSLCertificate. File /etc/apache 2 -007/ssl/apache-007. key LCL SSLCertificate. Key. File HTTPS 103 1. 59 5 0 ms – 0% Banque et </Virtual. Host> 7 H 2 Assurance 8 HTTPS Leroy 66 0. 87 11 0 ms – 0% 9 H 2 Merlin 10 HTTPS +100 ms – Darty 143 2. 24 33 0% 11 H 2 12 HTTPS Amazon. fr 215 5. 52 11 0 ms – 2% 13 H 2 Interfaces virtuelles (controle du réseau)

Aperçu du TP: clients Client Navigateur chrome standard (DNS hijacking via /etc/hosts) Web server Hébergement locale de vraies pages Web Con fig 10. 0. 0. 1 10. 0. 0. 2 10. 0. 0. 5 … Pas si Apache servers (un par domaine, controle du protocole L 7) Interfaces virtuelles (controle du réseau) www. leroymerlin. fr s 2. lmcdn. fr s 1. lmcdn. fr pixel. mathtag. com Orchestrateur d’experience (Page. X, Protocol. Y, network. Z)

Aperçu du TP: experience Web server Hébergement locale de vraies pages Web Client Navigateur chrome standard (DNS hijacking via /etc/hosts) Apache servers (un par domaine, controle du protocole L 7) ge a p b e W Interfaces virtuelles (controle du réseau) Orchestrateur d’experience (Page. X, Protocol. Y, network. Z)

Aperçu du TP: qualité d’experience Web server Hébergement locale de vraies pages Web Client Navigateur chrome standard (DNS hijacking via /etc/hosts) User MOS evaluation � =bad… =pretty bad =pretty good HAR r. M OS Apache servers (un par domaine, controle du protocole L 7) Interfaces virtuelles (controle du réseau) Orchestrateur d’experience (Page. X, Protocol. Y, network. Z)

Aperçu du TP: 3 phases • Rechauffement – “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 – Qo. S vs Qo. E: 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/Injnr 5) • 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 Orange – Examples contenu Mesure systematique de la Qo. E des top 100 Alexa depuis 100 villes Analyse de l’impacte des condition réseaux sur HTTP 2 Implementation d’un plugin Chrome {Byte, Object}Index Modele de regression du MOS à partir de la Qo. E (forecast) Etude de QUIC (avec methode similaire) Propose Your own

References (1/2) • Lectures obligatoires –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 –[Internet. Qo. E’ 16] E. Bocchi et al. “Measuring the Quality of Experience of Web users”. In ACM SIGCOMM 2016, Workshop on Qo. E-based Analysis and Management of Data Communication Networks (Internet. Qo. E)

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