Projet individuel 2 - Analyse d`un site web

1
Projet individuel 2 - Analyse d’un site web
Alexandre Hauet - SINF10PM
I. INTRODUCTION
CE pr´
esent document rapporte l’analyse d’un site
web dans le cadre du cours LINGI1341 - R´ eseaux
informatiques de l’Universit´ e catholique de Louvain.
Cette ´ etude porte sur le site www.imdb.com et comprend
trois parties qui analysent premi` erement les requˆ etes
Http rec¸ues et envoy´ ees, deuxi` emement son DNS et
finalement, l’impact de TCP sur les performances de ce
site.
Le site Internet Movie Database est une base de donn´ ees
en ligne sur le cin´ ema mondial, sur la t´ el´ evision, et
secondairement sur les jeux vid´ eo. Il a ´ et´ e achet´ e en
1998 par Amazon. Cette information pourrait expliquer
certains r´ esultats obtenus.
II. REQUˆ ETES HTTP
DANS cette section, les diff´
erentes analyses seront
bas´ ees sur deux sc´ enarios :
•l’acc` es ` a la page principale du site
•l’acc` es ` a la fiche d’un film
Chacun des sc´ enarios a ´ et´ er
´
ep´ et´ e 10 fois pour
les navigateurs web suivants : Google Chrome,
Firefox et Internet Explorer1, afin de pouvoir comparer
les diff´ erentes donn´ ees obtenues pour chaque navigateur
mais ´ egalement pour observer s’il est possible d’obtenir
des r´ esultats diff´ erents concernant un mˆ eme navigateur.
A. Requˆ etes et domaines
Nous pouvons remarquer, comme indiqu´ e dans le
tableau ci-dessous, que le nombre de requˆ etes varie ` a
chaque fois et entre chaque navigateur.
1 2 3 4 5 6 7 8 9 10 moy.
Chrome 146 161 148 149 154 149 148 149 152 144 151.1
Firefox 145 142 150 145 144 143 150 148 140 155 145.1
IE 163 163 166 165 165 160 164 165 165 164 164
TABLE I: Nombre de requˆ ete pour acc´ eder ` a www.imdb.
com
Les diff´ erentes variations peuvent ˆ etre expliqu´ ees
par le fait qu’Internet Explorer acc` ede ` a un domaine
1Google Chrome Version 39.0.2171.95 m, Mozilla Firefox 34.0.5
& Internet Explorer 11 Version : 11.096000.17498
suppl´ ementaire : cache.btrll.com, diff´ erent des deux
autres navigateurs. D’autre part, Firefox, Chrome et
Internet Explorer acc` ede respectivement 53, 56 et 68 fois
au domaine ia.media-imdb.com mais il est difficile de
justifier concr` etement cette diff´ erence.
En ce qui concerne la diff´ erence du nombre de
requˆ etes au sein d’un mˆ eme navigateur, celle-ci est
principalement expliqu´ ee par l’acc` es au domaine fls-na.
amazon.com. En g´ en´ eral la requˆ ete suivante http://fls-na.
amazon.com/1/batch/1/OP est appel´ ee deux ou sept fois.
Cependant, il arrive parfois que le service http://fls-na.
amazon.com/1/display-ads-cx/1/OP soit, quant ` a lui, ap-
pel´ e cinq fois, il semble agir comme un parseur mais son
rˆ ole reste tr` es obscur.
B. Diff´ erents fichiers t´ el´ echarg´ es
Diff´ erents types de fichier sont t´ el´ echarg´ es. Voici les
types r´ epertori´ es :
1) application/javascript 2) application/x-javascript
3) image/gif 4) image/jpeg
5) image/png 6) text/css
7) text/html 8) text/javascript
9) text/plain
En observant la liste pr´ ec´ edente, nous remarquons que
les fichiers javascript envoy´ es peuvent ˆ etre de trois types
diff´ erents. Selon les normes RFC2, l’utilisation correcte
est application/javascript,text/javascript ´ etant obsol` ete.
La notation application/x-javascript jusqu’au moment o` u
elle est normalis´ ee, comme dans le cas pr´ esent, peut ˆ etre
aussi consid´ er´ ee comme obsol` ete.
Fig. 1: Graphique repr´ esentant les diff´ erents types de
contenus t´ el´ echarg´ es
2http://www.rfc-editor.org/rfc/rfc4329.txt

2
Quand on observe le graphique pr´ ec´ edent repr´ esentant
la proportion respective des diff´ erents types de fichiers
t´ el´ echarg´ es, la plupart d’entre eux sont des images. Ce
qui semble tout ` a fait normal car ce site utilise beaucoup
d’images. Mais en regardant plus attentivement, nous
remarquons que certaines d’entre elles sont simplement
des images d’un 1x1 pixel. Elles sont appel´ es les pixels
espions et permettent de collecter de l’information sur
les utilisateurs.
Un pixel espion est une image num´ erique transparente
de petite taille qui rassemble des informations sur les ac-
tivit´ es de l’utilisateur. Il permet ` a un service de collecter
des donn´ ees lorsque l’image est t´ el´ echarg´ ee.
En pratique sur le site, les donn´ ees sont collect´ ees via
l’en-tˆ ete des requˆ etes grˆ ace aux champs Cookie, Referer
par exemple comme semble le faire le service fls-na.
amazon.com abord´ e pr´ ec´ edemment.
C. HTTP request headers
Au sein des en-tˆ etes des requˆ etes HTTP, il existe des
diff´ erences selon le navigateur utilis´ e:
1) Chrome:
Nous observons pour certaines requˆ etes l’apparition du
champs X-Client-Data. Il ne contient aucune information
personnelle et ne fait que strictement d´ ecrire l’´ etat de
l’installation du navigateur lui-mˆ eme3
On aperc¸oit ´ egalement que Chrome accepte une
troisi` eme m´ ethode de compr´ ehension des paquets http
: SDCH (nldr : les deux autres ´ etant gzip et deflate).
Google propose donc un codage suppl´ ementaire pour
HTTP qui s’appelle SDCH, et qui peut s’ajouter avant
gzip ou deflate.
2) User-Agent:
Le user agent est un code envoy´ e par chaque navigateur
web lors d’une connexion ` a un serveur. Le code permet
`
a un site web de savoir, entres autres, quel navigateur
et quel syst` eme d’exploitation sont utilis´ es par un inter-
naute.
Nous pouvons remarqu´ e, comme indiqu´ e dans le
tableau suivant, que les User-Agents des navigateurs sont
diff´ erents :
Chrome Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Firefox Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101
Firefox/34.0
I.E. Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like
Gecko
Ces r´ esultats sont assez intriguants car on observe que
les diff´ erents navigateurs semblent se faire passer pour
Mozilla.
3Selon le Livre blanc sur la confidentialit´
e dans Google Chrome
Il apparait que pour des raisons historiques, les nav-
igateurs aient ´ et´ e contraints de mentir dans leurs User
Agents4.
D. HTTP reponse headers
De nombreux champs dans les requˆ etes ne sont pas
standards. Voici une liste avec une br` eve description de
ceux-ci :
a) x-amz-cf-id: Contient une chaˆ ıne crypt´ ee qui
identifie une demande d’aide ou de d´ epannage. Elle est
utilis´ ee pour les requˆ etes venant du serveur Amazon
Cloudfront.
b) x-amzn-RequestId: Valeur cr´ e´ ee par
ADM(Amazon Device Messaging) qui identifie la
requˆ ete. En cas de probl` eme avec ADM, Amazon ne
peut utiliser cette valeur pour retrouver la requˆ ete.
c) x-fb-debug: Identifiant qui permet ` a Facebook de
retrouver plus simplement une requˆ ete lors d’un rapport
de bug.
d) x-cache: Indique si la cache provient d’un proxy
: Hit pour oui et Miss pour non.
e) x-cache-hits: Indique si l’objet demand´ e se
trouve dans le cache.
f) x-connection-hash: Remplace X-Transaction
g) x-content-type-options: Empˆ eche le navigateur
de faire MINE sniffing. MIME-type sniffing permet au
navigateur de d´ eduire les types des fichiers. La valeur de
cette en-tˆ ete est toujours ` anosniff
h) x-frame-options: Ce champ pour but d’empˆ echer
le navigateur d’ouvrir une page web dans une iframe.
Il peut prendre les valeurs : DENY, SAMEORIGIN et
ALLOW-FROM.
i) x-response-time: Permet d’afficher la dur´ ee de la
r´ eponse en millisecondes.
j) X-N: Permet d’augmenter la taille de l’en-tˆ ete
HTTP afin d’´ eviter certains bugs.
k) x-Served-By: Indique quel serveur a aliment´ e
Varnish. Varnish est un serveur de cache HTTP utilis´ e
par exemple par Twitter.
l) x-timer: Fournit des informations sur le voyage
d’une requˆ ete du d´ ebut ` a la fin. La valeur attribu´ ee ` a cette
en-tˆ ete est constitu´ ee de trois parties. Une premi` ere partie
qui commence par s, repr´ esente un Unix timestamp du
d´ ebut de la requˆ ete. La seconde section commence par
vs, pour varnish start, qui repr´ esente le d´ ebut du voyage
de la requˆ ete ; cette valeur doit ˆ etre toujours ´ egale ` a 0.
Et finalement, la derni` ere partie commence par ve, pour
varnish end, qui repr´ esente la longueur des sommes du
trajet.
4Pour plus d’information, je vous invite `
a visiter le site suivant
http://letrainde13h37.fr/28/les-user-agents-cest-le-mal/

3
m)x-transaction: Indique le num´ ero de la transac-
tion
n) x-xss-protection: ” Xss Protection ” est une pro-
tection cot´ e client pr´ esente dans la plupart des naviga-
teurs r´ ecents. Il s’agit en fait d’un composant, appel´ e
filtre XSS, charg´ e d’analyser les r´ eponses HTTP afin
de d´ etecter des comportements suspects typiques d’une
attaque par XSS r´ efl´ echi. Le filtre peut prendre la valeur 0
et 1 qui indique respectivement que celui-ci est d´ esactiv´ e
ou activ´ e. Lorsque le filtre est actif, il existe le mode
“block” qui en cas de d´ etection affichera uniquement
# comme rendu. Ce dernier en-tˆ ete prot` ege d’autres
anomalies, telles que des valeurs de input tr` es longue
et des liens tr` es long anormalement form´ e.
E. Les cookies
De nombreux cookies sont utilis´ es ` a travers le site et
pour des utilisations bien diff´ erentes. Ils servent prin-
cipalement ` a identifier l’utilisateur. Les cookies sont
utilis´ es par diff´ erents services :
a) Services propres au site:
L’historique des dix derni` eres pages visit´ es sur le site
(acteurs, films) sont visibles sur la page d’accueil du
site. Cette fonctionnalit´ e utilise les cookies. Lorsqu’une
page est visit´ ee par l’utilisateur, le site va enregistrer
la r´ ef´ erence de la page donc de l’acteur ou du film en
m´ emoire et la lier ` a l’identifiant attribu´ e au cookie. Il faut
ajouter que ces enregistrements de donn´ ees sont r´ ealis´ es
via le domaine i.imdb.com
Il est ´ egalement possible de g´ erer cet historique via
l’option ”Manage your history” du site. L’information
souhait´ ee est supprim´ ee via une requˆ ete qui prend
en param` etre l’identifiant du film ou de l’acteur
mais ´ egalement le cookie afin de pouvoir identifier
l’utilisateur. Nous pouvons voir que la ”suppression” des
donn´ ees est r´ ealis´ ee par le domaine www.imdb.com
b) Services li´ es au commerce:
Les cookies peuvent ˆ etre ´ egalement utilis´ es pour collecter
des informations sur l’utilisateur. Lorsqu’il se connecte
au site, un cookie est cr´ e´ e et va permettre d’enregistrer
des informations sur lui. Lorsque l’utilisateur acc` edera
`
a un autre site, ce cookie pourrait ˆ etre r´ eutilis´ e afin de
pouvoir mettre en ´ evidence certaines informations.
III. DOMAINE NAME SYSTEM
DANS cette partie de l’analyse, nous allons ´
etudier
le DNS des noms de domaine les plus impor-
tant utilis´ es sur le site. L’analyse est r´ ealis´ ee suite aux
r´ esultats obtenus grˆ ace ` a la commande dig.
A. www.imdb.com
Le serveur du site se trouve ` a Seattle. Il utilise un
CNAME, en r´ ealit´ e www.imdb.com est un alias vers
us.dd.imdb.com. Il utilise seulement des A records qui
correspondent donc ` a des adresses IPV4. Le Time to Live
du DNS qui indique le temps que l’information peut ˆ etre
conserv´ e en cache, est de 10800 secondes. Ce temps est
relativement court car, en g´ en´ eral, le TTL est de l’ordre
d’un jour (TTL = 86400 secondes).
Nous pouvons ´ egalement observer que le site utilise
le load balancing, c’est ` a dire que la charge de travail
est r´ epartie entre les diff´ erents serveurs d’imdb. Par
exemple, lors de l’appel du web service http://www.
imdb.com/profile/recently-viewed/ ajax/deleteItem il va
utiliser l’adresse distante 72.21.203.211 et pour un sec-
ond appel, il utilisera l’adresse 207.171.162.180.
B. ia.media-imdb.com
C’est ` a partir de ce domaine que sont t´ el´ echarg´ ees
les images du site. Le domaine est un alias (CNAME)
pour ia.imdb.com.edgesuite.net qui est lui-mˆ eme un alias
pour a1886.g.akamai.net. Nous pouvons conclure donc
qu’imdb utilise des serveurs de la soci´ et´ e Akamai qui
est une soci´ et´ e am´ ericaine sp´ ecialis´ ee dans la mise ` a
disposition de serveurs de cache pour les entreprises.
L’utilisation de ce type de serveur pour des images a
tout son sens.
Akamai est un service de content delivery net-
work(CDN) commercial. Un CDN est un r´ eseau
d’ordinateurs reli´ es ` a travers internet qui permet un gain
de rapidit´ e grˆ ace ` a une optimisation du m´ ecanisme de
transmission / livraison des requˆ etes.
Le TTL du DNS est de 900 secondes ce qui est
encore plus court que le premier domaine. Le domaine
ne semble poss´ eder que des adresses de type A records
(IPv4).
C. g-ecx.images-amazon.com
Le domaine est en r´ ealit´ e un alias(CNAME) pour
d1ge0kk1l5kmd0.cloudfront.ne. Amazon CloudFront est
un CDN tout comme Akamai. Nous pouvons ´ egalement
le remarquer grˆ ace ` a l’attribut x-cache de l’entˆ ete de la
r´ eponse HTTP :
X-Cache:Hit from cloudfront
On peut observer que le domaine i.imdb.com utilise
le CDN CloudFront.
Le TTL du DNS, d’autre part, est de 60 secondes ce
qui est encore plus court que le premier domaine. Le
domaine ne semble poss´ eder que des adresses de type A
records (IPv4).

4
D. www.facebook.com
Le domaine www.facebook.com est en r´ ealit´ e un
alias pour star.facebook.com qui est lui le CNAME de
star.c10r.facebook.com.
Il est accessible via IPv4 et IPv6. Lorsque nous le
contactons en IPv4, le serveur joint est situ´ e aux ´ Etats-
Unis et en IPv6, celui-ci se trouve en Irlande.
Le TTL est de 60 secondes, ce qui est relativement
court.
IV. TRANSMISSION CONTROL PROTOCOL
DURANT cette partie, nous allons utiliser
l’application Wireshark pour nos diff´ erentes
analyses.
A. Nombre de connexions TCP
Le nombre de connexions TPC ´ etablies est diff´ erent
pour les navigateurs test´ es.
Navigateur Nb. connexion
Chrome 6
Firefox 2
I.E. 8
Pour trouver ces donn´ ees, il faut regarder le nombre
de SYN envoy´ es lors du chargement de la page.
B. Three way handshake
Durant le three-way handshake, les options n´ egoci´ ees
sont la window scale et le MSS (Maximum Segment
Size).
Le client pr´ ecise dans les options du paquet [SYN]
qu’il souhaite une MSS de 1460 octets et un window
scale de 8.
Le serveur pr´ ecise dans les options du paquet [ACK,
SYN] qu’il souhaite une MSS de 1440 octets et un
window scale de 6.
C. La fenˆ etre de congestion
Le Round-trip delay time(RTT) est de 155ms. Le
premier paquet de donn´ ees (indiqu´ e par [TCP segment
of a reassembled PDU]) arrive ` a 751ms. Donc entre
751ms et 906ms, 17 paquets de donn´ ees sont rec¸us; ce
qui montre que la taille de la fenˆ etre de congestion est
initialis´ ee ` a 17.
D. Terminaison d’une connexion
Lors de la terminaison de la connexion TCP avec le
WEB-Serveur du site, nous observons un ´ echange d’une
paire de segments FIN et ACK. La terminaison a lieu
quand plus aucune donn´ ee n’est envoy´ ee.
V. C ONCLUSIONS
POUR conclure cette analyse, le site www.imdb.com
est h´ eberg´ e sur plusieurs serveurs : un serveur
principal ` a Seattle o` u se trouve les web services (les
fonctionnalit´ es du site), les diff´ erentes images du site
sont sur le CDN Akamai et la collecte d’informations
est r´ ealis´ ee par i.imdb.com qui est h´ eberg´ e sur un CDN
Amazon CloudFront.
De nombreuses fonctionnalit´ es Amazon sont pr´ esentes
sur le site, ce qui confirme notre intuition expos´ ee dans
l’introduction, via des services comme Amazon De-
vice Messaging, Amazon CloudFront... Amazon utilise
´
egalement les cookies d’IMDB.
D’un point de vue personnel, la r´ ealisation de cette
analyse m’a fait d´ ecouvrir la face cach´ ee des pages d’un
site web. Elle m’a permis de ne plus ˆ etre un surfeur passif
mais actif et attentif aux donn´ ees ´ echang´ ees via les sites
visit´ es.
REFERENCES
[1] Olivier Bonaventure, Computer Networking : Principles, Proto-
cols and Practice, 2nd edition, 2013.
[2] Amazon CloudFront, http://aws.amazon.com/fr/cloudfront/
[3] HTTP cookie, http://en.wikipedia.org/wiki/HTTP cookie
[4] How to test initcwnd? http://www.cdnplanet.com/blog/
tune-tcp-initcwnd-for-optimum-performance/#howtotest
[5] Internet Movie Database, http://en.wikipedia.org/wiki/Internet
Movie Database
[6] Livre blanc sur la confidentialit´ e dans Google Chrome, https:
//www.google.fr/chrome/browser/privacy/whitepaper.html
[7] Varnish (software), http://en.wikipedia.org/wiki/Varnish
(software)