Embed Size (px)
Citation preview
Université de la RéunionUFR Sciences et Technologies
Rapport de stage de Master M2INFORMATIQUE
Laboratoire d’Informatique et deMathématiques
Métrologie réseaux
Auteur :
Arnaud Ravoavahy
no étudiant : 36006861
Encadrants :
Xavier Nicolay
Rehan Noordally
Responsable de stage :
Pascal Anelli
Janvier - Juillet
Remerciements
Je tiens à remercier à toutes les personnes qui ont contribué, de près ou
de loin, à l’élaboration de ce stage. Je remercie particulièrement :
• Xavier Nicolay, Ingénieur de recherche au du laboratoire LIM, pour
les bons conseils inestimables et le temps qu’il m’a accordé durant la
préparation de ce travail
• Rehan Noordally, doctorant au LIM, pour l’encadrement qu’il m’a
donné avec rigueur
• Le responsable de stage, Pascal Anelli, les enseignants et le personnel
administratif du Master 2 Informatique de l’Université de la Réunion
Résumé
La connectivité internet de l’île de la Réunion présente une propriété par-
ticulière. Face à cette particularité, le projet régional "Métrologie et analyse
du trafic Internet de La Réunion" a pour objet de connaître les caractéris-
tiques des trafics et la connectivité de l’île. Dans ce cadre, une approche
métrologique a été suivie en deux phases. La première concerne la mesure
active, relative aux délais et routes empruntées depuis l’île de la Réunion.
La seconde phase effectue la mesure passive permettant de déterminer l’im-
pact des délais dans la performance du protocole TCP. De ce fait, des outils
étaient déjà développés mais certaines fonctionnalités étaient absentes. La
principale contribution dans la mesure passive réside dans l’identification
des différentes métriques liées à la performance de TCP. Par contre, l’ap-
port relative à la mesure active se base sur la proposition des solutions pour
résoudre les problématiques liées à la localisation des adresses IP.
Mots-clés
Métrologie Active, Métrologie Passive, Métriques, Performance, TCP
Abstract
Internet connectivity for Reunion Island presents a particular feature.
In this case, the regional project "Metrology and analysis of Internet traffic
of Reunion Island" wants to analyze the characteristics of traffic and the
connectivity. In this context, a metrological approach was followed. The first
relates to the active measure, relating to the delays and routes taken from
the island of Reunion. The second phase performs the passive measurement
to determine the impact of delays in the performance of the TCP protocol.
As a result, tools were already developed but some features were missing.
The main contribution in passive measurement is the identification of the
different metrics related to the performance of TCP. On the other hand, the
contribution relative to the active measurement is based on the proposition
of the solutions to solve the problems related to the location of the IP
addresses.
Keywords
Active Measurement, Passive Measurement, Metrics, Performance, TCP
Table des matières
1 Introduction 1
2 Contexte du stage 2
2.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 2
2.2 Contexte technique du stage . . . . . . . . . . . . . . . . . . . 3
3 État de l’art 4
3.1 Identification des métriques . . . . . . . . . . . . . . . . . . . 4
3.2 Algorithmes de recherche des métriques . . . . . . . . . . . . 5
3.3 L’anonymisation des résultats . . . . . . . . . . . . . . . . . . 5
3.4 Corrélation entre le délai et la distance . . . . . . . . . . . . . 6
4 Reverse engineering sur le fonctionnement du protocole
TCP 7
4.1 Analyse des flux . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Analyse des métriques . . . . . . . . . . . . . . . . . . . . . . 9
5 Contribution au développement de l’outil xanalyse 11
5.1 Choix de l’outil . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Principe de fonctionnement de l’outil . . . . . . . . . . . . . . 12
5.3 Traitement multithread . . . . . . . . . . . . . . . . . . . . . . 14
5.4 Mesure des métriques . . . . . . . . . . . . . . . . . . . . . . 15
5.5 Analyses statistiques du trafic réseau . . . . . . . . . . . . . . 24
5.6 Portabilité de l’outil . . . . . . . . . . . . . . . . . . . . . . . 24
5.7 Cryptage des adresses IP dans les résultats . . . . . . . . . . 27
6 Contribution au développement de l’outil rTraceroute 28
6.1 Le contexte de développement de l’outil . . . . . . . . . . . . 28
6.2 Principe de fonctionnement de rTraceroute . . . . . . . . . 30
vii
6.3 Implémentation du calcul de la distance en fonction des co-
ordonnées GPS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4 Identification des aberrations de localisation des adresses IP . 33
6.5 Mise à jour et correction de la base de données pour la géo-
localisation des adresses IP à travers un site web . . . . . . . 34
6.6 Portabilité de l’outil . . . . . . . . . . . . . . . . . . . . . . . 34
7 Résultats et Méthodes 34
7.1 Supervision et analyse de performance de TCP par l’outil
xanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Analyse de la connectivité internet de la Réunion . . . . . . . 38
8 Conclusion 42
A Annexe 44
Références 52
viii
Table des figures
1 Organigramme du LIM. . . . . . . . . . . . . . . . . . . . . . 2
2 Distribution du délai de la réponse RTT. . . . . . . . . . . . . 3
3 Estimation de la distribution du débit écoulé. . . . . . . . . . 3
4 Analyse de tous les flux par Wireshark. . . . . . . . . . . . . . 8
5 Analyse des flux TCP par Wireshark. . . . . . . . . . . . . . 9
6 DUP ACK Wireshark. . . . . . . . . . . . . . . . . . . . . . . 10
7 Extraction d’un flux TCP. . . . . . . . . . . . . . . . . . . . . 11
8 Fonctionnement de xanalyse. . . . . . . . . . . . . . . . . . . 13
9 Processus interne de xanalyse. . . . . . . . . . . . . . . . . . 14
10 Identification des paquets DUP ACK. . . . . . . . . . . . . . 16
11 Identification des paquets perdus. . . . . . . . . . . . . . . . . 18
12 Identification des paquets Fast-retransmit. . . . . . . . . . . . 19
13 Identification des paquets Out-of-order. . . . . . . . . . . . . 20
14 Identification des paquets spurious retransmission. . . . . . . 21
15 Identification des paquets windows update. . . . . . . . . . . . 21
16 Identification des paquets Keep Alive et Keep Alive ACK. . . 22
17 Identification des paquets retransmis. . . . . . . . . . . . . . . 23
18 Moyenne et Écart-type Upload/Download. . . . . . . . . . . . 24
19 Génération d’un exécutable par autotools. . . . . . . . . . . . 25
20 Arborescence du répertoire xanalyse. . . . . . . . . . . . . . 26
21 Principe d’anonymisation d’adresse IPv4. . . . . . . . . . . . 27
22 Résultat d’anonymisation. . . . . . . . . . . . . . . . . . . . . 28
23 Structure de la trace JSON. . . . . . . . . . . . . . . . . . . . 29
24 Principe de fonctionnement de rTraceroute. . . . . . . . . . 31
25 Les liens sortants de la Réunion. . . . . . . . . . . . . . . . . 40
26 Les liens entrants de la Réunion. . . . . . . . . . . . . . . . . 41
27 Technique de "Fast-Recovery" . . . . . . . . . . . . . . . . . . 45
28 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
x
29 Résultats de l’ensemble du fichier à analyser . . . . . . . . . . 49
30 Séparation de traitement des sessions . . . . . . . . . . . . . . 49
31 Résultats au niveau de chaque session . . . . . . . . . . . . . 50
xi
Liste des tableaux
1 Distribution des trafics du LIM. . . . . . . . . . . . . . . . . . 35
2 Répartition Géographiques du réseau WAN (Source localisa-
tion : RIPE NCC). . . . . . . . . . . . . . . . . . . . . . . . . 36
3 Distribution du protocole de transport. . . . . . . . . . . . . . 36
4 Distribution des services utilisant le protocole TCP. . . . . . 37
5 Répartition des métriques TCP. . . . . . . . . . . . . . . . . . 38
6 Distribution géographique des adresses IPv4. . . . . . . . . . 39
7 Traces collectées. . . . . . . . . . . . . . . . . . . . . . . . . . 40
xii
1 Introduction
L’internet connaît une mutation au niveau de ses usages partout dans
le monde. Un réseau mono-service pour transporter des fichiers binaires ou
textuels il y a vingt ans, aujourd’hui il doit être un réseau multi-services
pour le transport de données massives qui sont diverses et variées. Il faut
prendre en compte le type de service pour assurer la fiabilité du transport.
Les communications interactives, par exemple, sont sensibles au délai et
doivent être priorisées. Cependant, On est confronté à un problème de sa-
turation des liens à cause du transport des données massives qui augmente
la latence et dégrade la performance.
Dans le contexte des îles de la zone Océan Indien, des problèmes d’infra-
structure peuvent apparaître. Contrairement à la France métropolitaine, où
le maillage du réseau est la règle, ces îles possèdent une connectivité faible-
ment maillée reposant sur deux câbles sous-marins SAFE (South Africa-Far
East) et LION (Lower Indian Ocean Network). De ce fait, le problème de
saturation sera plus aigu. Le risque est de voir les besoins en trafic augmen-
ter jusqu’à dépasser les ressources disponibles. Dans ce cadre, le stage va
contribuer à l’étude des caractéristiques du trafic montant et descendant.
Des études métrologiques vont être effectuées afin de trouver les particula-
rités du réseau notamment à l’île de la Réunion.
Ce rapport se divise en 8 grandes parties. Une présentation du contexte sera
élaborée dans la section 2 après cette introduction. Un état de l’art autour
des travaux attendus sera abordé dans la section 3. Ensuite, un reverse en-
gineering sur le fonctionnement du protocole TCP (Transmission Control
Protocol) sera élaboré dans la section 4. Puis, les différentes contributions
au projet seront discutées dans la section 5 et 6. Quelques résultats et mé-
thodes seront discutés par la suite dans la section 7 et une conclusion sera
donnée dans la section 8 pour terminer.
1
2 Contexte du stage
2.1 Présentation de l’organisme d’accueil
Le stage se déroule au sein du LIM (Laboratoire Informatique et Mathé-
matique), sous la responsabilité de Xavier Nicolay, ingénieur de recherche,
et Rehan Noordally, doctorant au sein du laboratoire. Le LIM, dirigé par
le professeur Jean Diatta, est un laboratoire de recherche de l’Université de
la Réunion. La figure 1 représente l’organigramme du laboratoire, "Équipe
d’Accueil EA2525 ", structuré de trois axes :
— Épistémologie et Didactique de l’informatique et des Mathématiques
(EDIM)
— InformaTique et Applications (ITA)
— Mathématiques (MATHS)
Figure 1: Organigramme du LIM.
2
2.2 Contexte technique du stage
Le projet régional sous le thème : "Métrologie et Étude du trafic internet
de l’île de la Réunion" vise à répondre aux problématiques liées à la parti-
cularité de la connectivité de l’île au reste du monde. Avec l’évolution des
services internet, on est confronté à une croissance importante du volume
de données échangé. Un risque de saturation des liens va être rencontré.
L’augmentation du débit ne va pas suivre la croissance de la volumétrie des
données. En effet, un débit élevé ne changerait pas la latence liée à la dis-
tance. Inversement, une diminution du débit va augmenter la latence. La
courbe dans la figure 2 représente la distribution de la mesure du délai de
la réponse RTT (Round-trip Time). On voit un écart de 200 ms entre la
Réunion et Paris. La courbe dans la figure 3 montre l’estimation de la dis-
tribution du débit écoulé obtenu pour les transferts initiés respectivement
depuis la Réunion et Paris. Les débits écoulés sont majoritairement plus
faibles que ceux obtenus à Paris [1].
0
0.001
0.002
0.003
0.004
0.005
0.006
0.007
0.008
0.009
0.01
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Pro
b.
RTT (en sec.)
De Paris
De la Reunion
Figure 2: Distribution du délai dela réponse RTT.
0
0.001
0.002
0.003
0.004
0.005
0.006
0.007
0.008
0.009
0.01
10 100 1000 10000 100000
Pro
b.
Debit (kbits/s)
De Paris
De la Reunion
Figure 3: Estimation de la distri-bution du débit écoulé.
L’objectif du projet est d’identifier les caractéristiques du trafic internet
de la Réunion afin de répondre aux problématiques liées à la mesure des
paramètres suivants :
— la proportion de trafic de consultation de contenu et de données inter-
actives ;
— les taux de congestion ;
3
— la taille des flots de données ;
— les débits écoulés au niveau des flots utilisateurs ;
La mesure de ces différents paramètres est parmi les travaux que j’ai effectué
durant le stage. Pour ce faire, j’ai fait un travail bibliographique et une
analyse des publications concernant les techniques de mesures. La partie
suivante va parler des différentes thématiques de recherche sur lesquelles je
me suis basé.
3 État de l’art
J’ai effectué des recherches approfondies sur les techniques de mesure
notamment la mesure passive et la mesure active. Dans le cadre de la mé-
trologie passive, j’ai participé à la définition des métriques impactant la
performance du protocole TCP.
3.1 Identification des métriques
L’objectif des métriques est d’établir une base commune de connaissance
au niveau des performances et de la fiabilité du réseau afin d’obtenir une
connaissance précise pour les utilisateurs et pour les fournisseurs d’accès
internet[2]. Le groupe IPPM (IP Performance Metrics) de l’IETF (Internet
Engineering Task Force) a défini dans les RFC (Request For Comments) les
métriques de base suivantes :
— la mesure de la connectivité entre deux équipements (RFC 2678 [3]) ;
— le délai unidirectionnel (RFC 2679 [4]) ;
— le taux de pertes unidirectionnelles de paquet (RFC 2680 [5]) ;
— le délai et le taux de pertes de paquets aller-retour (RFC 2681 [6])
A partir de ces métriques sont élaborées plusieurs autres métriques plus
complexes :
4
— la gigue ou variation de délai ;
— les modèles de pertes de paquets (RFC 3357 [7]) ;
— le ré-ordonnancement des paquets ;
— la bande passante et le débit de transfert d’information ;
En parallèle, je me suis intéressé aux algorithmes permettant de trouver ces
métriques.
3.2 Algorithmes de recherche des métriques
L’identification de ces métriques est complexe et dépend de plusieurs
paramètres. Je me suis focalisé sur les RFC qui proposent des algorithmes
pour les identifiés. Pour le calcul du RTO (Retransmission Time-out) par
exemple, j’ai mis en place un algorithme de temporisateur défini par le RFC
2988 [8]. Pour la validation de la conformité des résultats, Je les ai comparé
avec ceux de l’outil Wireshark. Un problème de sécurisation de données a
été soulevé au niveau des résultats. Ainsi, j’ai fait une recherche sur les
techniques de cryptage des adresses IPv4 (Internet Protocol Version 4 ).
3.3 L’anonymisation des résultats
Comme l’outil va être disponible au grand public, il doit respecter les
règlements relatifs à la loi informatique et la liberté en France [9]. Le RFC
6235 [10] propose 4 méthodes pour anonymiser une adresse IP, à savoir :
— La troncation : supprime les N derniers bits
— La troncation inverse : supprime les N premiers bits
— La permutation : remplace chaque IP par un autre
— La pseudonymisation : préserve le préfixe, garde les N premiers bits et
fait une permutation sur les M derniers.
Le choix s’est orienté vers cette dernière technique car elle permet de garder
une certaine information permettant de faire l’analyse pertinente des résul-
5
tats. Les recherches effectuées relatives à la métrologie passive ont pris une
grande partie du stage. Après l’implémentation des métriques et de la sécu-
risation des données, j’ai entamé dans la partie métrologie active en faisant
des recherches sur les problématiques rencontrés notamment la corrélation
entre le délai et la distance.
3.4 Corrélation entre le délai et la distance
La littérature montre différente méthode pour trouver une fonction de
corrélation entre le délai et la distance géographique. Dans l’article [11],
l’auteur propose un modèle de calcul de la latence en fonction de la distance.
Il indique que la latence minimum entre deux nœuds avec une distance d
est donnée par la formule suivante :
tmin(d) = d/cfibre (1)
où cfibre est le débit maximum dans une fibre optique qui est proportionnel
à la vitesse de la lumière avec cfibre = 2/3 c. Ainsi la latence observée est
donnée par l’équation :
t = tmin(d) + e(d) (2)
où e(d) représente le délai du réseau. Cette latence minimum est décrite dans
l’article [12] avec un coefficient de proportionnalité qui est égal à 0.0128.
D’où, l’équation (1) devient :
tmin(d) = 0.0128d (3)
L’expérimentation a été faite dans des zones fortement maillées. Plusieurs
valeurs ont été collectées et projetées dans un plan formé de deux axes. L’axe
des ordonnées représente le délai tandis que l’axe des abscisses constitue la
distance géographique. Tous les points appartenant à la droite optimale de
6
l’équation (3) sont supérieurs à tous les points d’expérimentation. En faisant
la comparaison entre (1) et (3), le RTT minimum mesuré est plus proche du
résultat donné par l’équation (3).
Dans l’article [13], l’auteur calcul la distance géographique à l’aide de l’équa-
tion suivante :
β =
√(sin( lati − latτ
2 ))2 + cos(lati) × cos(latτ ) + (sin( lonτ − loni2 ))2 (4)
distiτ = 6371 × 2 × arcsin(β) (5)
où lati et loni (respectivement latτ et lonτ ) représentent la latitude et la
longitude exprimées en radian de l’hôte i (respectivement de l’hôte τ). La
distance géographique, exprimée en km, entre l’hôte i et l’hôte τ est obtenue
à partir de l’équation (5). Le coefficient 6371 représente le rayon de la terre.
Les différentes recherches élaborées dans l’état de l’art m’ont permis d’avoir
des approches théoriques pour mes contributions. Pour la suite du projet, il
est important de connaître le principe du protocole TCP.
4 Reverse engineering sur le fonctionnement du protocole
TCP
Faire du Reverse engineering sur le protocole TCP consiste à comprendre
dans un premier temps le fonctionnement de TCP. Pour cela, j’ai utilisé
l’analyseur de paquet Wireshark. Cet outil est apparu en 2006, le premier
fondateur s’appelle Gerald Combs. Il a mené un projet universitaire dans le
but est de développé un logiciel, nommé Ethereal, permettant d’analyser le
protocole d’un réseau informatique [14].
7
4.1 Analyse des flux
L’analyse de fonctionnement de TCP devient trivial lorsqu’on arrive a
isolé les flux. Pour cela, on peut spécifier les paramètres comme les ports
d’échanges.Wireshark possède cette fonctionnalité et affiche de manière gra-
phique le résultat.
Figure 4: Analyse de tous les flux par Wireshark.
La figure 4 schématise tous les flux entre les adresses 10.230.30.151 et
130.89.149.21 sur les ports 34706 et 80. On peut obtenir uniquement les flux
TCP qui sont illustrés dans la figure 5.
8
Figure 5: Analyse des flux TCP par Wireshark.
Cette dernière nous donne une visibilité sur les flags échangés dans l’en-
semble des flux TCP. Dans cet exemple, il y a 8 segments. La phase d’éta-
blissement de connexion se caractérise par l’échange des 3 paquets ayant
les flags [SYN], [SYN, ACK], [ACK] qui sont représentés par les 3 premiers
paquets. Tandis que la clôture de connexion se caractérise par l’échange des
3 derniers paquets ayant le flag [FIN, ACK].
4.2 Analyse des métriques
Wireshark identifie les différentes métriques de performances TCP. Pour
cela, il nous donne la fonction "tcp.analys.*" pour sortir les paquets corres-
pondants. Cette fonction est basée sur l’analyse des numéros de séquence.
* représente la métrique recherchée qui peut être parmi les métriques sui-
vantes :
— Lost segment ou paquet non capturé ;
— Retransmission ou paquet retransmis ;
— Fast-Restransmit ou paquet retransmis très rapidement ;
— Spurious retransmission ou paquet de retransmission inutile ;
— Out-of-order ou paquet déséquencé ;
9
— Keep Alive ou paquet de maintien d’une session ;
— DUP ACK ou paquet dupliqué ;
— Windows Update ou paquet de mise à jour de la fenêtre de réception
Un exemple de paquet dupliqué est montré sur la figure 6. Pour l’identifier,
il faut utiliser le filtre "tcp.analysis.duplicate_ack". La capture indique
que le paquet est une duplication du segment numéro 128.
Paquet dupliqué
Figure 6: DUP ACK Wireshark.
Wireshark ne possède pas une option d’extraction à partir des filtres.
Cette fonctionnalité est nécessaire pour pouvoir isoler un flux dans un vo-
lume de capture considérable. Face à cela, nous avons développé un outil
qui s’appelle "pcap_extract_flux". Par la suite, on va parler du principe
de fonctionnement de cet outil.
Extraction d’un flux TCP
L’outil "pcap_extract_flux" a été développé en C et basé sur la li-
brairie PCAP. Il permet d’extraire un flux entre deux adresses IP et de
construire un nouvel enregistrement de fichier.
10
pcap_extract_flux
FILE_IN.pcap
extract_pcap_from_file
@IP1 @IP2
@IP1 @IP2
@IP1 @IP2
@IP3 @IP4
@IP3 @IP4
FILE_OUT.pcap
@IP1 @IP2
@IP1 @IP2
Figure 7: Extraction d’un flux TCP.
La figure 7 explique le principe de fonctionnement du programme. L’outil
a besoin de deux paramètres à l’entrée :
— un fichier PCAP qui constitue le fichier initial,
— deux adresses IP qui sont susceptibles d’échanger des données dans le
fichier PCAP
A la sortie du programme, un nouveau fichier PCAP sera généré et il va
contenir les flux d’échanges de données entre les deux adresses IP à l’entrée.
Cet outil a été vraiment nécessaire dans la compréhension du fonctionnement
de TCP. En outre, il a permis de vérifier la pertinence de l’outil xanalyse
dans la répartition des flux. Par la suite, je vais élaborer les contributions
que j’ai apporté au développement de l’outil.
5 Contribution au développement de l’outil xanalyse
5.1 Choix de l’outil
Un des outils pour faire la métrologie passive s’appelle TCPDump. Ce
dernier est développé par Jacobson en 1989 décrit dans l’article [15]. L’ou-
til utilise la librairie PCAP pour capturer et analyser les trafics réseaux
TCP/IP. Wireshark et TCPDump sont tous des excellents outils mais ne
11
répondent pas complètement aux besoins et aux contraintes du projet. Nous
pouvons citer par exemple le traitement de gros volume de capture mais
aussi la confidentialité de l’information. En effet, ces outils ne sont pas opti-
misés à traiter un fichier de taille supérieure. En outre, des données privées
sont visibles dans le résultat. Pour répondre aux contraintes précédentes,
l’ingénieur de recherche, Xavier Nicolay, avait commencé à développer un
programme nommé xanalyse dans le courant de l’année 2015. J’ai continué
par la suite durant le stage. Les particularités du programme reposent sur
plusieurs aspects, à savoir :
— le traitement des captures volumineuses,
— l’optimisation du temps de traitement et d’occupation de ressource
(utilisation de threads),
— la disponibilité des fonctionnalités comme l’anonymisation, la localisa-
tion des adresses IP et la mesure des métriques évaluant la performance
du protocole TCP.
Il est donc important de comprendre le mécanisme de l’outil.
5.2 Principe de fonctionnement de l’outil
xanalyse est un programme développé en C. Il utilise la librairie PCAP
et threading qui permet de tirer profit des architectures multiprocesseurs.
Le choix du langage réside sur la compatibilité de l’outil avec les systèmes
d’exploitation basées sur UNIX.
12
xanalyseIP observées
Données capturées
(.pcap)
Mysql
Résultats
Résultats anonymisés
Débits
Délais
Traitement
Anonymisation
Géolocalisation
Figure 8: Fonctionnement de xanalyse.
La figure 8 schématise le concept de l’outil. Il nécessite 3 paramètres à
l’entrée :
• Le premier paramètre est la liste des couples d’adresses IP à observer.
Chaque couple est formé de 2 adresses IP, séparées par une espace, qui
font potentiellement des échanges dans le réseau. L’ensemble se trouve
dans un fichier de format texte.
• Le second paramètre est le fichier de capture. Il est dans un format
pcap obtenu par une sonde placée dans le réseau.
• Le troisième paramètre est un fichier de configuration qui est fourni
avec le répertoire du programme. Il définit les paramètres d’accès à
une base de donnée MySQL qui va permettre à l’outil de localiser les
adresses IP afin de les afficher dans le résultat.
A la sortie du traitement, 4 fichiers peuvent être générés :
— les résultats non cryptés,
— les résultats anonymisés,
— le débit,
— le délai
La performance de l’outil repose sur le traitement parallèle de plusieurs
instructions. Par la suite, je vais expliquer brièvement l’implémentation de
13
ce mécanisme dans l’outil.
5.3 Traitement multithread
Le traitementmultithread consiste à exécuter plusieurs séquences d’ins-
tructions en parallèle. xanalyse utilise cette méthode afin d’optimiser le
temps de traitement et l’occupation de la mémoire. la figure 9 schématise
une partie du processus interne de l’outil.
open_pcap()read_table()
FILE.pcap
check_xtupleadd_xtuple
xtuple
sniff_ip
metadatapaquet
Liste_flux
lookInAllIpFlux()
Liste_tab_session
lookInSession()
sniff_ip
metadatapaquet
Liste_flux
Liste_tab_session
Liste_session Liste_session
@IP1 @IP2
. . . .
. . . .
. . . .
. . . .
Résultats
Figure 9: Processus interne de xanalyse.
La fonction read_table utilse une methode add_tuple pour ajouter le
couple d’adresses IP (@IP1,@IP2 ) dans le tableau xtuple d’une manière
unique. Une fois le tableau rempli, xanalyse utilise la méthode open_pcap
de la librairie PCAP pour lire le fichier FILE.pcap. L’en-tête de chaque
datagramme IP va être sauvegardée dans une liste chaînée de structure
sniff_ip. Cette liste va aussi mettre à jour la table xtuple à l’aide de
14
la méthode check_xtuple d’une manière unique. Une liste chaînée appelée
list_flux va contenir l’ensemble des flux TCP appartenant à une même ses-
sion. Une session est constituée de paquets ayant les mêmes ports source et
destination. L’en-tête TCP d’un paquet contenu dans la liste des flux vont
être stockés dans une liste chaînée de structure metadatapaquet.
Ensuite, xanalyse traite plusieurs structures list_flux en parallèle par la
méthode lookInAllIpF lux. A la sortie de cette méthode, toutes les ses-
sions dans les flux sont sauvegardés dans une liste chaînée de structure
Liste_tab_session. Les paquets appartenant à une même session sont sau-
vegardés dans une liste chaînée de structure liste_session.
Après l’identification des différentes sessions, le programme analyse chaque
session par la méthode lookInSession. Cette dernière parallélise le traite-
ment de plusieurs liste_session. A la sortie de cette fonction, les résultats
au niveau de chaque session et un récapitulatif de l’ensemble du fichier se-
ront affichés.
La mesure des métriques est établie dans la méthode lookInAllIpF lux. Par
la suite, je vais décrire les méthodes que j’ai utilisé pour les identifier et les
implémenter dans l’outil.
5.4 Mesure des métriques
Pour identifier les métriques, j’ai intégré des algorithmes dans l’outil pour
marquer le type de segment ayant un lien avec les métriques recherchées.
Pour ce faire, j’ai utilisé le programme pac_extract_flux pour extraire les
flux dans le fichier de capture. Puis j’ai validé mes résultats avec ceux de
Wireshark.
Les paquets d’acquittements dupliqués (DUP ACK) :
Pour l’identification de ce type de paquet, j’ai appliqué la définition
donnée par le RFC 5681 [16] sur la duplication des paquets. En effet, tous
15
les datagrammes IP ayant comme protocole de transport TCP seront filtrés.
L’en-tête est sauvegardé en mémoire. Les champs suivants seront vérifiés :
— le numéro de séquence,
— le numéro d’ACK,
— la taille de la fenêtre
La condition pour qu’un paquet est considéré comme un DUP ACK est la
suivante :
"Si le paquet observé est un ACK et qu’il n’est pas unique par rapport aux
autres ACK déjà vus dans ce cas il est un ACK DUP".
Wireshark xanalyse
Figure 10: Identification des paquets DUP ACK.
La figure 10 illustre le résultat de recherche des paquets dupliqués. Pour
le cas de l’outil xanalyse, ce type de paquet est marqué par _DUP_.
Les paquets perdus ("Packet Loss") :
Lorsqu’un paquet n’arrive pas à sa destination, il est considéré comme
perdu. Le protocole TCP possède une technique pour détecter une perte
dans le réseau. Cette technique rend le protocole fiable et performant. Il as-
sure la retransmission des paquets qui sont considérés comme perdus. Pour
un analyseur réseau, il est difficile d’identifier ce type de segment car il
n’existe pas un flag qui spécifie ce phénomène. Le principe de TCP face à
cet événement se reflète à travers les caractéristiques et les comportements
16
des segments.
Les analyseurs réseaux utilisent leurs propres algorithmes en fonction des
propriétés de TCP dans le contexte d’identification d’un paquet perdu.
Comme le cas de Wireshark par exemple, il possède un analyseur dédié
pour TCP. En effet pour détecter les paquets perdus, un filtre est dispo-
nible : "tcp.analysis.lost_segment". L’algorithme lié à ce filtre est donné
avec le code source du programme mais n’est pas compatible avec l’outil
xanalyse. Il a fallu réaliser un reverse engineering à travers les différentes
captures et dresser un algorithme propre à l’outil.
On a conclu qu’un paquet est considéré comme disparu si le segment attendu
par le récepteur est perdu. D’une manière générale, lorsque que le récepteur
attend un numéro de séquence alors qu’il reçoit un autre qui est supérieur au
numéro attendu ; il va indiquer qu’un segment n’était pas capturé. L’algo-
rithme de détection de paquet perdu se base sur le même principe. D’abord
en parcourant les précédents paquets jusqu’à une condition d’arrêt telle que :
"si le paquet observé est déjà un paquet attendu d’un précédent paquet le pro-
gramme arrête de parcourir".
Cette condition d’arrêt est nécessaire pour l’optimisation du traitement. La
bonne condition pour qu’il y ait paquet perdu est la suivante :
"Si le numéro de séquence du paquet observé est supérieur au numéro de
séquence attendu par le précédent paquet alors on a marqué sur le paquet
observé qu’il y avait une perte dans le réseau".
17
Wireshark xanalyse
Figure 11: Identification des paquets perdus.
La figure 11 illustre le résultat de recherche des paquets perdus. Pour le
cas de l’outil xanalyse, ce type de paquet est marqué par _LP_.
Les paquets "Fast-Retransmit"
L’identification des Fast-Retransmit est basée sur les DUP ACK. Le RFC
2581 [17] explique le phénomène qui peut provoquer une retransmission ra-
pide. Parmi les techniques de contrôle d’erreur de TCP, le "Fast-Retransmit"
permet de reprendre les précédentes caractéristiques de la transmission (le
numéro de séquence, la fenêtre de congestion etc.) après détermination d’une
perte de paquet. Cette méthode est utilisée par la technique "Fast-Recovery"
décrit dans l’annexe. En effet, l’expéditeur effectue une retransmission rapide
lorsque qu’il reçoit trois acquittements dupliqués. Il suffit alors de parcourir
les paquets précédents et compter le nombre de DUP ACK. Cette définition
n’est pas suffisante car il y a la notion de temps qui est liée au terme "Fast"
sinon on risquera de confondre avec d’autre type de paquet. De ce fait, l’al-
gorithme d’analyse du protocole TCP de Wireshark propose un paramètre
qui est la différence temporelle entre le paquet de données observé et le pré-
cédent paquet d’acquittement. Ainsi cette valeur doit être inférieure à 20 ms
pour valider qu’il s’agit d’un paquet "Fast-Retransmit".
18
Wireshark xanalyse
Figure 12: Identification des paquets Fast-retransmit.
La figure 12 illustre le résultat de recherche des paquets "fast-retransmit".
Pour le cas de l’outil xanalyse, ce type de paquet est marqué par_FAST_.
Les paquets "Out-of-order"
Lorsqu’un paquet n’arrive pas dans l’ordre attendu par le destinataire, le
phénomène de déséquencement apparaît. Lors d’une retransmission rapide
par exemple, le numéro de séquence du paquet qui va être retransmis ne
va pas suivre l’ordonnancement des séquences attendus au niveau du récep-
teur. On peut considérer donc que ce segment est un "out-of-order" or ce
n’est pas le cas dans la réalité. Le challenge était de trouver une spécificité
qui caractérise ce type de paquet. En consultant l’algorithme proposé par
Wireshark dans son analyse TCP, il introduit encore la notion de différence
temporelle qui est contrairement au précédent métrique doit avoir une valeur
plus élevée de l’ordre de 300 ms.
19
Wireshark xanalyse
Figure 13: Identification des paquets Out-of-order.
La figure 13 illustre le résultat de recherche des paquets "out-of-order".
Pour le cas de l’outil xanalyse, ce type de paquet est marqué par _OoO_.
Les paquets "spurious retransmission"
Le paquet marqué "spurious retransmission" est un paquet qui a subi une
fausse retransmission. L’expéditeur renvoie un paquet qui a été déjà acquitté
par le récepteur. A l’arrivée d’un segment, si le numéro de séquence du pa-
quet attendu est inférieur ou égal au numéro d’acquittement du précédent
paquet d’ACK alors le paquet observé est un "spurious retransmission".
Cette condition est évidente dans le sens où le paquet arrivé est déjà un
doublon et peut être considéré comme une fausse retransmission. J’ai ren-
contré une difficulté dans la détection de ce type de paquet car le programme
considère les paquets SYN et FIN comme des "spurious retransmission". Ce
phénomène peut entraîner une confusion car la session TCP n’est pas encore
ouverte or il prétend observer une retransmission. Pour résoudre à ce pro-
blème, on a ajouté des nouvelles conditions qui ne considère pas les paquets
ayant comme flag SYN ou FIN.
20
Wireshark xanalyse
Figure 14: Identification des paquets spurious retransmission.
La figure 14 illustre le résultat de recherche des paquets "spurious retrans-
mission". Pour le cas de l’outil xanalyse, ce type de paquet est marqué par
_SR_.
Les paquets "Windows update"
La présence d’un paquet de mise à jour de la fenêtre est très importante.
L’expéditeur va réduire ou augmenter la taille de donnée qu’il va envoyer
en fonction de la valeur de la taille de la fenêtre. Suite à une observation de
Windows update, on arrive à implémenter l’algorithme en suivant la logique
du protocole. Il suffit de comparer la taille de la fenêtre du paquetACK
observé avec celle du précédent ACK. Si on constate un changement de
valeur alors il y a une mise à jour de la fenêtre.
Wireshark xanalyse
Figure 15: Identification des paquets windows update.
La figure 15 illustre le résultat de recherche des paquets "windows up-
21
date". Pour le cas de l’outil xanalyse, ce type de paquet est marqué par
_WD_.
Les paquets "Keep Alive" et "Keep Alive ACK"
Un paquet "Keep Alive" joue un rôle important aussi dans le mécanisme
de connexion. Sa présence indique que la connexion essaie de garder une
session ouverte même si le service reste silencieux ou inactif dans le réseau.
La détection d’un Keep Alive repose sur les caractéristiques des en-têtes. En
effet, le champ de donnée défini à 1 octet contrairement à l’ACK qui est à 0.
En outre, lorsque le numéro de séquence attendu du paquet observé est égal
au numéro d’ACK du précédent paquet, alors on peut dire que le paquet
observé est un "Keep Alive".
La réponse d’unKeep Alive sera le "Keep Alive ACK ". Pour un ACK observé,
il suffit de regardé si le paquet précédent était un "Keep Alive". Si c’était le
cas alors on le classifie parmi les "Keep Alive ACK ".
Wireshark xanalyse
Figure 16: Identification des paquets Keep Alive et Keep Alive ACK.
La figure 16 illustre le résultat de recherche des paquets "Keep Alive et
Keep Alive ACK ". Pour le cas de l’outil xanalyse, ces paquets sont marqués
respectivement par _KA_ et _KACK_ .
22
Les paquets retransmis
Le RFC 793 [18] explique le principe de la retransmission. Ce segment
apparaît quand le paquet n’est pas acquitté à l’intérieur d’un intervalle de
temps imposé par l’expéditeur. La difficulté était le calcul du RTO. Dans l’ar-
ticle [19], l’auteur décrit le fonctionnement de l’algorithme de calcul du timer
d’ACK. Dans le programme, on s’est basée sur le principe qu’un RTO re-
présente la différence temporelle entre l’émission d’un paquet et la réception
de son acquittement. Il faut filtrer l’ensemble des paquets qui se trouvent
à l’intérieur de cet intervalle pour ne pas tous les considérés comme des
retransmissions. Pour ce faire, une condition récupère les paquets ayant un
numéro de séquence désordonné par rapport au précédent. On peut conclure
que ces derniers constituent les paquets retransmis.
Wireshark xanalyse
Figure 17: Identification des paquets retransmis.
La figure 17 illustre le résultat de recherche des paquets retransmis. Pour
le cas de l’outil xanalyse, ce type de paquet est marqué par _RTRS_.
Après avoir identifier les différentes métriques, il est nécessaire de faire leurs
analyses . Dans la partie suivante, j’ai effectué des analyses statistiques des
résultats.
23
5.5 Analyses statistiques du trafic réseau
Pour faciliter la compréhension des résultats, j’ai implémenté dans l’outil
le calcul de la moyenne, la variance et l’écart-type des caractéristiques du ré-
seau. La gigue, par exemple, représente la variation de délai de transmission
entre l’émission de deux paquets consécutifs. Dans la logique du principe de
la figure 9, le traitement de chaque session doit se faire en amont. Autrement
dit, c’est dans la fonction lookInSession que les analyses statistiques doivent
être faites. A la sortie, on obtient la moyenne, la variance et l’écart-type de
la gigue des flux montants et descendants dans chaque session.
Analyse statistique au niveau de chaque session
Moyenne du trafic UP/DOWN}} Ecart-type du trafic UP/DOWN
} Moyenne/Ecart-type Gigue UP/DOWN
Figure 18: Moyenne et Écart-type Upload/Download.
La figure 18 montre le résultat de l’outil sur le calcul de la moyenne et
de l’écart-type dans une session TCP.
Nous avons décidé de rendre l’outil facile à installer. Par la suite, je vais
expliquer le principe de la portabilité du programme.
5.6 Portabilité de l’outil
xanalyse est un nouvel outil de métrologie. Il sera libre et fourni au
grand public. Pour cela, nous avons facilité son installation. Les outils fournis
par "autotools" permettent de construire un projet GNU. Pour ce faire, les
fichiers nécessaires à l’installation de xanalyse sont placés dans deux sous
24
répertoires. Les librairies utilisées sont répertoriées dans "common" et le
main se situe dans "src". La figure 19 illustre le principe de fonctionnement
de l’autotools qui utilise 5 outils pour générer un fichier exécutable.
autoscanAutotools
configure.ac
aclocal autoheader
aclocal.m4 config.h.in
autoconf
Makefile.am
automake
Makefile.in
s
config.h Makefile
make
exécutable
Figure 19: Génération d’un exécutable par autotools.
L’outil autoscan doit être lancé dans le répertoire "src" afin qu’il cherche
25
les problèmes de portabilité. Un fichier configure.ac sera généré et copié
dans la racine du projet. Ensuite, on génère respectivement les fichiers aclo-
cal.m4 et config.h.in à partir des outils aclocal et autoheader. Ces derniers
permettent de définir les macros externes du programme.
Pour adapter l’installation de nos codes sources en fonction du système et la
machine d’installation, on a utilisé l’outil autoconf. Après son lancement, un
fichier configure sera créé à partir de configure.h.in. Le script configure va
convertir le fichier Makefile.in en véritable Makefile. Chaque répertoire pos-
sède sa propre Makefile.in. La figure 20 donne un aperçu de l’arborescence
du répertoire xanalyse.
src
common
Makefile.am
configure.ac
aclocal.m4
config.h.in
main.c
Makefile.am
configure.ac
aclocal.m4
main.h
xparse.h
xparse.c
...
...
xanalyse
...
xanalyse
Figure 20: Arborescence du répertoire xanalyse.
Les résultats obtenus contiennent des adresses IP qui permettent d’iden-
tifier les activités de ses propriétaires. Pour respecter la loi informatique et
26
la liberté en France, j’ai implémenté un système d’anonymisation. Par la
suite, je vais expliquer brièvement la mise en œuvre de cette technique dans
l’outil.
5.7 Cryptage des adresses IP dans les résultats
Une approche simple pour crypter une adresse IPv4 est de la faire cor-
respondre avec une adresse aléatoire. Une telle méthode rend la trace inuti-
lisable dans des situations utilisant la logique des adressages IP. L’anonymi-
sation d’adresse est performante si elle préserve le même préfixe. Autrement
dit, si deux adresses IP d’origines partagent k-bit préfixe, leurs équivalences
anonymes partageront également k-bit préfixe. J’ai adoptée la même ap-
proche dans le programme xanalyse en se basant sur l’outil Crypto-pan
décrit dans l’article [20]. Pour valider la fiabilité de cette approche, j’ai testé
tous les schémas d’anonymisation d’adresses IP.
PAnonymizer_new()raw_addr
x.x.x.x/prefixe
Anonymisation anonyme_ip()
Key
PAnonymizer_anonymize()
y.y.y.y/prefixe
xanalyse
CPAnonymizer
Figure 21: Principe d’anonymisation d’adresse IPv4.
La figure 21 schématise l’implémentation d’anonymisation dans l’outil
27
xanalyse. Une fonction anonyme_ip() a été définie pour recevoir l’adresse
IP à crypter. Derrière cette fonction, il y a deux autres appartenant à la bi-
bliothèque de Crypto-pan. La fonction PAnonymizer_new utilise le chiffre-
ment "Rijndael" basé sur l’algorithme AES et retourne un objet C++ appelé
CPAnonymizer. Les arguments de la fonction CPAnonymizer_anonymize
sont le précédent objet et le raw_addr. Les 4 octets formant l’adresse IP
vont être récupérés dans la fonction raw_addr. A la sortie, une adresse IP
cryptée sera obtenue avec le même préfixe.
Adresses non anonymisées
Adresses anonymisées
Figure 22: Résultat d’anonymisation.
La figure 22 illustre le résultat d’anonymisation par l’outil. Le sous-réseau
10.230.30.0/24 est crypté en un nouveau sous-réseau 117.248.231.0/24.
Le chapitre suivant va nous parler de mes contribution dans le développe-
ment de l’outil rTraceroute.
6 Contribution au développement de l’outil rTraceroute
6.1 Le contexte de développement de l’outil
rTraceroute s’inscrit dans un programme de métrologie active. Il ne
génère pas de trafic dans le réseau mais plutôt il analyse les résultats obtenus
à partir des outils de mesure active. Dans notre cas, les données à traiter
sont les traces provenant de l’outil "Paris-traceroute". Pour ce faire, la
28
collecte des traces est divisée en deux catégories :
• La première consiste à collecter les différentes routes empruntées par
les trafics pour arriver à la Réunion (trafics entrants). Les sondes ont
été hébergées dans la plateforme RIPE ATLAS [21]. Les données cap-
turées sont disponibles sous un format JSON. La structure du fichier
JSON est schématisée sur la figure 23.
[] JSON
Trace JSON
-{}0
af: 4addr_dest
end_time
prb_idaddr_src
proto
[] result
{}0hop: 1
[] result
{}0
from:addrrtt
sizettl
{}1from:addrrtt
sizettl
{}2from:addrrtt
sizettl
-
--
- -
-
-
Figure 23: Structure de la trace JSON.
Les informations importantes spécifiées dans la trace sont :
— le numéro d’identification du probe "prd_id" et l’adresse IP de
destination,
— les résultats de mesures et l’adresse IP source.
L’arborescence du premier résultat indique tous les sauts traver-
sés par la source jusqu’à sa destination. Au niveau de chaque
saut, un deuxième résultat est donné en indiquant les valeurs
mesurées pour chaque paquet ICMP (Internet Control Message
29
Protocol) envoyé par la source. La commande traceroute envoie 3
requêtes ICMP vers une destination. De ce fait, on obtient 3 ré-
sultats pour chaque requête dont chacun donne les informations
suivantes : l’adresse IP du routeur, le RTT, la taille du paquet et
le TTL (Time To Live).
• La deuxième catégorie regroupe les routes empruntées par les tra-
fics réseaux sortant de la Réunion vers internet (trafics sortants). Des
Raspberry Pi [22] sont programmés pour joindre en ICMP certaines
destinations à partir de l’outil Paris-Traceroute [23]. Les résultats des
traces seront sauvegardés dans un fichier texte.
La partie suivante va expliquer brièvement le principe de fonctionnement de
rTraceroute.
6.2 Principe de fonctionnement de rTraceroute
Les données récoltées sont répertoriées dans un serveur centralisé. L’outil
va identifier l’ensemble des fichiers de traces dans le répertoire. La figure 24
schématise le principe de fonctionnement de l’outil.
30
isValideJsonParsing
xmem_pool xstat_poolxtab_pool
isGoodFile
File
TypeJSON TXT
analyseFile
add_in_occ_lien
isMPLS
occ_lien
createAllLinks
trace
draw_map
Figure 24: Principe de fonctionnement de rTraceroute.
Le traitement des traces s’effectue en deux phases :
• Une méthode "analyseFile" est exécutée en parallèle sur l’ensemble des
fichiers capturés. Elle comporte une fonction de nettoyage des traces
en considérant le type de fichier à l’entrée. Pour le cas d’un JSON
(respectivement d’un texte), la fonction "isValideJsonPasing" (respec-
tivement "isGoodFile") valide les traces qui n’ont pas les critères d’ex-
clusions suivants :
— Le fichier est corrompu ;
— La trace n’est pas arrivée à sa destination : contenant des !H, !N,
WARN ou contenant 3 * consécutifs.
31
Les traces définitives seront stockées dans une liste chaînée de structure
"xtab_pool". Une analyse statistique des délais va être effectuée au
niveau de chaque trace et le résultat va être sauvegardé dans une liste
chaînée de structure "xstat_pool". Le programme mémorise un résultat
temporaire dans une autre liste chaînée de structure "xmem_pool".
• Ensuite, une méthode "createAllLinks" est exécutée en parallèle en
utilisant la fonction "add_in_occ_lien". Tous les trajets identifiés à
partir de la liste chaînée "xtab_pool" seront mémorisés dans une nou-
velle liste chaînée de structure "occ_lien". L’identification d’un lien
MPLS caractérise cette structure.
Un fichier trace comporte le nombre d’occurrence, le délai moyen, la locali-
sation et la détection d’un lien utilisant le protocole MPLS dans les trajets.
Une problématique rencontrée dans l’outil est la localisation des adresses
IP. Dans une première phase, j’ai mis en place dans le programme un algo-
rithme permettant de calculer la distance géographique. La section suivante
va élaborer la méthode que j’ai utilisé.
6.3 Implémentation du calcul de la distance en fonction des coordonnées
GPS
Les trajets stockées dans la liste chaînée "occ_lien" sont caractérisés par
plusieurs paramètres, à savoir :
— la localisation des adresses IP (pays source/destination),
— Les coordonnées des pays sur la carte,
— le RTT moyen et minimum entre deux pays,
— le nombre d’occurrence du lien dans l’ensemble des captures,
— le type du lien (normal/MPLS)
Il est difficile d’avoir la distance géographique entre deux pays à partir des co-
ordonnées sur une carte. Pour cela, la base de donnée MySQL permettant la
32
localisation des adresses IP offre une table donnant la correspondance entre
une adresse IP et les coordonnées GPS (Global Positioning System). De ce
fait, les coordonnées GPS doivent être insérées dans la structure "xtab_pool"
afin d’ajouter la distance géographique comme un nouveau paramètre pour
la structure "occ_lien". Une fonction "calculDistance" a été testée et vérifiée
en utilisant la formule 5 dans la partie état de l’art.
Après avoir calculé la distance géographique, j’ai proposé une méthode pour
résoudre le problème de localisation des adresses IP. Dans la partie suivante,
je vais élaborer mes propositions.
6.4 Identification des aberrations de localisation des adresses IP
Les adresses IP sont localisées à partir d’une base de données MySQL
locale qui s’appelle IP_GEOLOC. La base est constituée de deux tables,
à savoir la table IP et la table MAPS. La première comporte l’adresse IP,
les coordonnées GPS, le pays, le numéro d’AS (Autonomous System) et le
"holder". La seconde est formée par les champs IP, les coordonnées relatives
à chaque pays sur la carte et le pays. A partir de la structure "occ_lien", on
a constaté quelques mauvaises localisations des adresses IP. En effet, le RTT
doit être proportionnel à la distance géographique des deux pays pour chaque
trajet. L’objectif dans un premier temps est d’identifier toutes les aberrations
de localisations. Pour ce faire, on a utilisé la méthode décrite dans l’article
[12] qui permet d’estimer le RTT minimum entre deux points de la planète.
Par hypothèse, tous les trajets dont le RTT moyen est inférieur au RTT
minimum sont considérés comme des aberrations de localisation. L’objectif
dans un second temps est de trouver une fonction permettant de trouver
un RTT maximum afin de borner la valeur du RTT moyen par une borne
supérieure RTT maximum et une borne inférieure RTT minimum. Dans ce
cas, on est arrivé à une fonction de détection d’aberration de localisation à
priori. L’idéal était de trouver une fonction de correction.
33
Pour que les résultats soient pertinents, il faut travailler sur une base de
donnée pertinente. La partie suivante va parler de mes contributions à la
mise à jour et à la pertinence de la base de données.
6.5 Mise à jour et correction de la base de données pour la géolocalisation
des adresses IP à travers un site web
Dans ce cadre, j’ai dévéloppé un site web permettant aux utilisateurs de
comprendre le contexte et le fonctionnement de l’outil rTraceroute. Suite
au problème de localisation d’adresse IP, une option de mise à jour de la
base de données a été créé dans le site afin que les résultats des analyses
soient pertinents en termes de localisation. Pour ce faire, j’ai implémenté
une architecture de type MVC (Modèle-Vue-Contrôleur) dans le site qui est
développé en PHP. Ce modèle offre un avantage au niveau de la clarté de
l’architecture. Cela va simplifier la maintenance et l’extension du projet.
Nous avons également décidé de rendre l’outil facile à installer.
6.6 Portabilité de l’outil
rTraceroute s’inscrit également dans le cadre d’un nouvel outil pour le
monde du réseau. Il sera libre et une documentation sera fournie au grand
public dans le site web du laboratoire. Toutes les démarches suivies dans
xanalyse sont appliquées pour la portabilité de cet outil.
7 Résultats et Méthodes
Les deux outils ont contribué aux résultats de deux articles scientifiques.
Le premier [24] consiste à étudier la performance de la connectivité de la
réunion au reste du monde. L’objectif de cet article est de déterminer les
différentes métriques afin d’étudier l’impact de la latence sur la performance
de TCP. Tandis que le deuxième [25] consiste à investiguer la performance
34
de la connexion internet en analysant les délais et les propriétés des liens
entrants et sortants de la réunion.
7.1 Supervision et analyse de performance de TCP par l’outil xanalyse
Pour tester la performance de l’outil, les trafics réseaux au sein du la-
boratoire vont être analysés. La collecte se fait à partir d’une sonde. Le
résultat d’analyse est divisé en deux parties. Une partie sur la supervision
et une autre sur l’analyse des caractéristiques des flux et de la performance
du protocole TCP.
Supervision des flux
Le LIM utilise le réseau RENATER pour se connecter à internet. Ce
dernier est un réseau dédié pour les universités et les centres de recherches
en France métropolitaine et dans les départements d’outre-mer. Une bande
passante de 500 Mbits/s est alors attribuée à l’ensemble de l’université.
La sonde a permis de collecter 72 Go de données pendant une durée d’un
mois. Seules les données utilisant le protocole IPv4 vont être observées car
le protocole IPv6 n’est pas encore déployé à l’université. On peut diviser les
trafics capturés en trois catégories :
— Le trafic réseau local du laboratoire ou le LAN (Local Area Network)
— Le trafic réseau à l’intérieur de l’île ou le MAN (Metropolitan Area
Network)
— Le trafic sortant et entrant de l’île ou le WAN (Wide Area Network)
Table 1: Distribution des trafics du LIM.
Trafic LAN MAN WANPourcentage % 21.65 0 78.35
Le tableau 1 représente les résultats obtenus par rapport aux trois catégories
de trafics et on constate la forte présence du réseau WAN dans l’ensemble
35
des trafics observés.
A partir de la localisation des adresses IP fournie par l’outil, on peut re-
grouper les trafics WAN appartenant à un même continent. Le tableau 2
représente la distribution géographique des adresses IP dans les 4 conti-
nents. Océanie et Amérique du sud ne sont pas présents dans les sondes.
Table 2: Répartition Géographiques du réseau WAN (Source localisation :RIPE NCC).
Continent Afrique Asie Europe Amérique duNord
Pourcentage % 1.31 5.26 28.95 64.47
Les trafics à destination ou en provenance de l’Europe et d’Amérique du
Nord sont très considérables. Cela explique que les publications scientifiques
les plus sollicitées par les chercheurs sont hébergées dans des serveurs situés
dans ces deux continents. Le tableau 3 représente la distribution des proto-
coles de transport dans le réseau du laboratoire. La présence considérable
du protocole ICMP est due à la présence des sondes effectuant la mesure
des délais pour le projet décrit dans [25]. Le pourcentage du protocole UDP
( User Datagram Protocol) est faible si on considère le fait que la plupart
des internautes à la réunion utilisent Google Chrome d’après le site [26].
Ce navigateur offre une option QUIC qui augmente la performance de la
navigation en utilisant le protocole HTTP (HyperText Transfer Protocol)
over UDP. La majorité des trafics est transportée par TCP en raison de sa
Table 3: Distribution du protocole de transport.
Protocole ICMP IGMP TCP UDPPourcentage % 5.72 0.01 92.49 1.78
fiabilité en termes de contrôle de flux. La distribution des services utilisant
TCP est donnée par le tableau 4. La colonne non identifiée représente les
segments dont le type de service n’est pas spécifié. La présence de SSH signi-
fie l’accès à des serveurs distants. Le mail utilise les protocoles POP (Post
36
Office Protocol ) et IMAP (Internet Message Access Protocol) ou POP3s et
IMAPs pour l’envoie et la réception des messages. Le pourcentage des ser-
vices HTTP et HTTPS est important car la majorité des utilisateurs utilise
des navigateurs web pour se connecter à internet. Des ressentis de lenteur
sont constatés par les utilisateurs. De ce fait, la suite de l’analyse va se
concentrer sur la performance de TCP.
Table 4: Distribution des services utilisant le protocole TCP.
Service SSH DNS Mail Nonidenti-fié
Autres HTTPS HTTP
Pourcentage 0.02 1.63 4.91 7.21 9.45 32.97 43.79
Performance du protocole TCP
L’outil xanalyse offre une analyse des débits et des délais sur les trafics
capturés. On constate dans notre analyse que 60% des trafics ont un débit
significatif inférieur ou égal à 10 bits/s, et la majorité représente 10−3%
de l’ensemble des volumes échangés. La Réunion présente un comportement
spécifique sur le délai décrit dans l’article [25]. On suppose que les trafics sont
exposés à des événements de congestion. Ce phénomène peut être identifié
de deux manières :
— Soit à partir des flags de notifications de congestions dans les segments
TCP comme ECN (Explicit Congestion Notification) [27] et CWR
(Congestion Window Reduce)
— Soit à partir de la présence de réduction de la taille de la fenêtre du
protocole pendant le transfert des données.
Dans l’ensemble des paquets capturés, le premier cas n’apparaissait pas.
On suppose que les équipements réseaux ont supprimés les flags liés à la
notification de congestion. Dans le deuxième cas, on a besoin d’identifier
les paquets susceptibles d’être une réduction de taille de la fenêtre. L’outil
37
xanalyse a identifié 152.230 paquets ayant ce type de flag. Cela représente
3∗10−3% des paquets échangés. Le tableau 5 donne des exemples de métrique
avec leurs pourcentages. Les paquets retransmis et perdus ne sont pas très
significatifs. Le pourcentage de ces erreurs est inférieur à celui que TCP
pourrait produire en condition normale.
Table 5: Répartition des métriques TCP.
Paquets Fast Retrans-mit
Retransmissionsabusives
Paquetsperdus
Non retrans-mit et nonperdu
Pourcentage 5.2 × 10−3 7.8 × 10−3 14 ×10−3
99.97
7.2 Analyse de la connectivité internet de la Réunion
Pour faire l’analyse de la latence de l’accès internet de la Réunion l’article
[25] propose l’étude approfondie des délais et des caractéristiques des liens
dans le réseau. Pour ce faire, on a collecté plusieurs traces entre l’île et
quelques pays dans le monde. Comme les liens dans le réseau internet sont
asymétriques, l’article propose d’étudier séparément les routes montantes et
descendantes.
Sortant de la Réunion
Pour identifier les différentes routes empruntées par le réseau depuis la
Réunion, 27 Raspberry Pi ont été programmés pour envoyer des traceroute
vers 10 000 adresses IPv4 réparties géographiquement dans le monde. Pour
avoir une visibilité des liens de tous les fournisseurs d’accès, les réseaux
utilisés par les Raspberry Pi sont répartis sur les 5 opérateurs existants
dans l’île.
Le nombre de traceroute lancé simultanément est limité à 4. Cela évite la
congestion du réseau par notre mesure active. La totalité des traces obtenue
38
avec les Raspberry Pi est de 7 560 000.
Table 6: Distribution géographique des adresses IPv4.
Continent Pourcentagede l’expéri-mentation
Pourcentageselon Coun-tryIpBlocks
Afrique(AF) 0.95% 2.59%Asie(AS) 32.96% 23.34%Amérique duNord (NA)
8.89% 47.55%
Océanie 0.7% 1.55%Amérique duSud(SA)
6.30% 4.27%
Autres 21.19% 0.0%
Le tableau 6 montre la comparaison de la distribution géographique de
notre projet avec celle de la distribution réelle fournie par le site web :
https ://www.countryipblocks.net
Entrant de la Réunion
Les données collectées sont formées par les routes empruntées pour entrer
à la Réunion. L’importance de cette collecte repose sur l’identification de la
présence des routes asymétriques dans l’internet. Ce phénomène est causé
par les différents paramétrages du réseau. On peut citer par exemple les
règles de routage et le trafic engineering [28]. Pour ce faire, on a utilisé la
plateforme RIPE NCC qui délimite le nombre de probes autorisé à 1000.
Les probes Atlas sont paramétrés à rejoindre les Raspberry Pi localisés à
la Réunion dont leurs réseaux sont distribués sur les opérateurs locaux. Le
nombre maximal de routes collectée est de 300 000.
Le tableau 7 résume l’ensemble des méthodes et des plateformes utilisées
pour la collecte des traces.
39
Table 7: Traces collectées.
Entrant SortantProbes Raspberry Pi Atlas RIPE NCCDestination 10,000 IP 10 Raspberry PiSources 27 Rasberry Pi 1,000 Atlas probesOutils Paris-tracerouteNombre detraces
7,560,000 300,000
Traces utiles 1,015,180 38,714
Analyse des liens
L’existence de connexion physique directe entre deux continents ne vé-
rifie pas la corrélation entre le délai et la distance. Pour cela, on a identifié
les premiers routeurs que les trafics vont suivre à la sortie du border de la
Réunion. La figure 25 schématise les résultats obtenus. La largeur d’un lien
est proportionnelle à son nombre d’occurrence dans l’ensemble des traces.
On constate qu’aucun trafic a pour destination vers le continent Asiatique or
qu’il existe un lien physique entre le continent et la Réunion. On observe le
même cas avec les parties Est et Ouest de l’Afrique. La majorité des trafics
de la Réunion passe en France avant d’aller vers leurs propres destinations.
Figure 25: Les liens sortants de la Réunion.
40
La figure 26 montre les derniers routeurs dont les prochains sauts de des-
tination sont à la Réunion. Cette figure met en évidence l’existence d’un lien
entre le continent Asiatique et l’île mais les trafics ne sont pas significatifs.
Figure 26: Les liens entrants de la Réunion.
La présence d’un lien direct entre la Réunion et les pays distants comme
les USA et Paraguay indique qu’il y a des informations manquantes.
41
8 Conclusion
Le stage au sein du LIM a été initié dans le cadre du projet régional sous
le thème : "Métrologie et analyse du trafic internet de la Réunion", dont
deux phases de mesure ont été faites. La première concerne une phase de
mesure active relative aux délais, la seconde porte sur une mesure passive.
J’ai participé à ces deux phases qu’on peut catégoriser en deux parties.
La première partie consiste à finaliser l’outil xanalyse. L’objectif était
de pouvoir donner des résultats pour l’article [25] qui sera présenté à la
conférence internationale NextCOMP (Next Generation Computing Appli-
cations) du 19 au 21 Juillet 2017 à l’île Maurice. Mes principales contri-
butions étaient l’implémentation des algorithmes permettant d’identifier les
métriques de performance TCP et l’analyse des résultats. D’autres apports
bénéfiques dans le cadre du développement de l’outil sont aussi l’anony-
misation des résultats au niveau des adressages IP et de la portabilité de
l’outil. Durant cette partie de stage, j’ai pu acquérir des connaissances ap-
profondies sur le protocole TCP/IP et la métrologie passive. En termes de
programmation, j’ai appris plusieurs techniques sur le langage C notam-
ment la programmation parallèle, la connaissance approfondie de la librairie
PCAP appliquée à l’analyse du réseau et la gestion de mémoire.
La deuxième partie s’inscrit dans la métrologie active en participant à
l’amélioration des résultats de l’outil rTraceroute. Mes apports dans le
projet étaient de proposer des solutions pour répondre aux problématiques
liées à la localisation des adresses IP. Je me concentre sur l’ identification
des aberrations de localisation qui reste encore en cours. Cette partie m’a
permis de connaître plus clairement la connectivité des îles de l’Océan In-
dien à l’internet en particulier celle de la Réunion.
42
En parallèle, j’ai assuré la vulgarisation de ces outils métrologiques en
développant un site web en PHP. Cette partie du stage m’a permis de maîtri-
ser l’architecture MVC et d’élargir mes compétences en développement web.
Des améliorations peuvent être envisageables pour les deux outils. Il
serait intéressant d’implémenter l’analyse en temps réel du réseau à travers
xanalyse. Un élargissement des sondes sur d’autres continents est aussi
une autre perspective très intéressante pour avoir plus de visibilité dans
les traces et les informations manquantes du réseau afin que rTraceroute
puisse analyser les liens d’échange de peering entre la Réunion et le reste du
monde.
43
A Annexe
Présentation du MOOC : Programmer en C
J’ai suivi un MOOC sous le thème : "Programmer en C" sur la plate-
forme FUN-MOOC Mines Telecom. La durée du MOOC était de trois se-
maines. Des objectifs ont été donnés à la fin de chaque semaine.
— La première semaine a pour objectif de maîtriser le système d’exploi-
tation LINUX. Un historique a été donné en particulier sur UNIX et
LINUX. Puis, un rappel sur les bases des commandes linux a été pré-
senté. Et à la fin de cette première semaine, la méthode de compilation
à partir d’un code écrit en langage C a été élaborée.
— La deuxième semaine a abordé l’utilisation de la mémoire d’un ordi-
nateur avec le langage de programmation C. Dans un premier temps,
l’architecture d’un ordinateur et la structuration de sa mémoire a été
expliqué brièvement. Puis, une notion sur le pointeur a été donnée.
Cette notion est très utilisée par la suite.
— La troisième semaine a pour but de savoir allouer dynamiquement la
mémoire de l’ordinateur dans un programme écrit en C. Ensuite, l’ob-
jectif donné pendant cette dernière semaine est d’apprendre à compiler
avec plusieurs fichiers sources.
Suivre le MOOC m’a permis d’avoir une connaissance pointue sur la pro-
grammation C. En outre, il m’a aidé à contribuer au développement des
programmes xanalyse et rTraceroute. En effet, j’ai appliqué la technique
d’allocation dynamique de la mémoire pour optimiser ces deux programmes.
44
Dup ACK, Fast-retransmission, Fast-Recovery
Segment-2
Host A Host B
Segment-1
Segment-3
Segment-4
Segment-5
Segment-6
Segment-2
Segment-7 Segment-8 Segment-9
----------------->
<-----------------
---->----------------->
<-----------------
----------------->
<-----------------
----------------->
<-----------------
----------------->
<-----------------
----------------->
----------------->
----------------->----------------->
<-----------------
----------------->
<-----------------
LOST
ssthresh = 2 MSS
CWD = ssthresh + 3 MSS
Segment-10
1024
ACK 1025
20483072
ACK 2049 où est le Segment-2 ?
ACK 2049 où est le Segment-2 ?
ACK 2049 où est le Segment-2 ?
ACK 2049 où est le Segment-2
4096
5120
6144
2048 Retransmission Rapide
716881929216
ACK 9217 (acquittement cumulatif)
10240
ACK 1041
CWD = 1 MSS
?
Figure 27: Technique de "Fast-Recovery"
Planification
Figure 28: Planification
Installation de xanalyse et rTraceroute
L’installation de xanalyse (respectivement rTraceroute) nécessite la
présence des deux paquets build-essential (compilateur C) et libpcap-
45
dev (librairie PCAP). Si ces derniers ne sont pas encore installer, on lance
la commande ci-dessous pour leurs installations :
$ apt−get i n s t a l l bui ld−e s s e n t i a l l ibpcap−dev
On décompresse le fichier xanalyse.tar.gz (respectivement rtraceroute.tar.gz),
qui est disponible dans le site du LIM, puis on lance la commande :
$ c on f i gu r e
Cette commande va générer un fichier makefile.in. On peut ensuite lancer la
commande suivante :
$ make & make i n s t a l l
Une fois l’installation terminée, un fichier exécutable appelé xanalyse (res-
pectivement rTraceroute) est généré. Pour démarrer le programme, il faut
entrer la commande suivante :
xanalyse
$ xanalyse − i p f ip . data −dfn pcapFi l e −o f ou tF i l eRe su l t
[−delay outFi l eDe lay ] [−deb i t outF i l eDeb i t ]
[−dbgf debugFilename ] [−m]
L’outil fournit plusieurs options, à savoir :
— -ipf : suivie par le fichier ip.data regroupant l’ensemble des couples
d’adresses IP à observer,
— -dfn : définit le fichier pcap pcapFile à analyser,
— -of : indique le fichier outFileResult de sortie pour les résultats
d’analyse,
— -delay : définit le fichier outFileDelay dans lequel se trouve l’extrac-
tion des délais de l’ensemble des trafics unidirectionnels dans chaque
session,
46
— -debit : définit le fichier outFileDebit dans lequel on sauvegarde les
débits des trafics TCP et les autres trafics,
— -dbg : définit le fichier debugFilename permettant de debugger le
programme,
— -m : permet l’utilisation de la base de donnée pour la géolocalisation
des adresses IP.
rTraceroute
$ r t r a c e r ou t e [− s ] [− j ] −p r epDa t a f i l e s [−d ou t pu t f i l e ] [− g in map . png ] [−gout new_map . png ] [−c colorname ] [−dec ] [− redraw ] [− s tx valx ] [− s ty valy ] $ r t r a c e r ou t e [− s ] [− j ]
[−d ou t pu t f i l e ] [− g in map . png ] [−gout new_map . png ] [−c colorname ] [−dec ] [− redraw ] [− s tx valx ] [− s ty valy ]
L’outil fournit plusieurs options, à savoir :
— -s : mode très silencieux,
— -j : fichiers au format JSON (optionnel),
— -p repDatafiles : répertoire contenant les fichiers à analyser,
— -d outputfile : fichier résultat (hop, @IP, country, rtt) issu de l’ana-
lyse,
— -gin map.png : (entrée) carte mondiale (vierge) pour le tracé des flux
(png ou jpg),
— -gout world_new.png : (sortie) carte mondiale pour le tracé des
flux (world_new.png par défaut),
— -glast world_last.png : (sortie) carte mondiale pour le tracé des
derniers flux (world_last.png par défaut).
— -c colorname : couleur (html) du tracé beige, black, blue, red, green,
white, yellow, ...
— -mpls colorname : couleur (html) du tracé pour les liens MPLS
beige, black, blue, red, green, white, yellow, ...
— -dec : décale les traces d’un point
47
— -redraw : retrace les liens avec l’épaisseur des occurrences d’usages
— -stx valx : analyse tous les tracés convergents vers ces coordonnées
(valx ET valy)
— -sty valy : analyse tous les tracés convergents vers ces coordonnées
(valx ET valy)
— -v : affiche la version
— -core : (debug) autorise la generation d’un fichier core
— -rej : ajouter l’extention ’.rej’ aux fichiers incorrects
— -t trajectfile : sauvegarde tous les trajets, et les occurrences des che-
mins empruntés
— -savebigdata save.txt : sauvegarde dans un seul fichier, au format
traceroute les données utiles
— -m mysql.ini :definit le fichier mysql.ini à utiliser (valeur par défaut
dans le répertoire courant = mysql.ini)
— -readbigfiles :lit des fichiers trace ’consolidés’
— -matrice f.xml lPays :enregistre dans un fichier XML (Excel/Calc
compatible) contenant les matrices d’interconnexion de la liste des
pays (ex RE,MG,SC)
— -ff filefonte : définit le chemin de la police (ttf) à utiliser lors de
l’écriture sur les cartes
— -fs fontesize :définit la taille de la police à utiliser lors de l’écriture
sur les cartes
48
Récapitulatif de l’analyse de l’outil xanalyse de l’ensemble des captures
ques T P
ment
Nombre de paquets
aque
ole
Figure 29: Résultats de l’ensemble du fichier à analyser
Séparation des résultats pour chaque session par l’outil xanalyse
Filtre les paquets appartenant à une session
Initialisation de connexion
clôture de connexion
Figure 30: Séparation de traitement des sessions
49
Récapitulatif de traitement pour chaque session par l’outil xanalyse
Métriques TCP
dans une session
Volumetrie TCP/IP:-volume de donnéesen upload/download
-analyse statistique(Ecart-type, Moyenne)
Gigue en upload/download
Figure 31: Résultats au niveau de chaque session
Financement du stage
Ce stage a été financé par la région de la Réunion dans le cadre d’un
appel à un projet de recherche de l’année 2013.
50
Liste des abréviations
AS Autonomous System
GPS Global Positioning System
ICMP Internet Control Message Protocol
IETF Internet Engineering Task Force
IPPM IP Performance Metrics
IPv4 Internet Protocol Version 4
LION Lower Indian Ocean Network
MVC Modèle-Vue-Contrôleur
RFC Request For Comments
RTO Retransmission Time-out
RTT Round-trip Time
SAFE South Africa-Far East
TCP Transmission ControlProtocol
TTL Time To Live
51
Références
[1] P.Anelli. Des aléas de la communication : de la transmission au tra-
sport. Habilitation à diriger des recherches en informatique, Université
de la Réunion, 2012.
[2] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis. Framework for IP
Performance Metrics. RFC 2330, May 1998.
[3] J. Mahdavi and V. Paxson. IPPM Metrics for Measuring Connectivity.
RFC 2678, 1999.
[4] G. Almes, S. Kalidindi, and M. Zekauskas. A One-way Delay Metric
for IPPM. RFC 2679, 1999.
[5] G. Almes, S. Kalidindi, and M. Zekauskas. A One-way Packet Loss
Metric for IPPM. RFC 2680, 1999.
[6] G. Almes, S. Kalidindi, and M. Zekauskas. A Round-trip Delay Metric
for IPPM. RFC 2681, 1999.
[7] R. Koodli and R. Ravikanth. One-way Loss Pattern Sample Metrics.
RFC 3357, 1999.
[8] V. Paxson and M. Allman. Computing TCP’s Retransmission Timer.
RFC 2988, 2000.
[9] Guide "Informatique et Libertés" pour l’enseignement du second degré.
2010.
[10] E. Boschi and B. Trammell. IP Flow Anonymization Support. RFC
6235, May 2011.
[11] B. Gueye, A. Ziviani, M. Crovella, and S. Fdida. Constraint-based
geolocation of internet hosts. IEEE/ACM Transaction 14, 6 (2006).
[12] O. Krajsa and L. Fojtova. Rtt measurment and its dependence on
the real geographical distance. In Proceedings of 34th International
Conference on Telecommunications and Signal Processing. IEEE/ACM
Transaction 14, 2011.
52
[13] B. Gueye. Vers un compromis entre mesures actives et mesures passives
pour la localisation géographique des hôtes dans l’internet.
[14] https://fr.wikipedia.org/wiki/Wireshark.
[15] V. Jacobson and S. McCanne. Tcpdump. ftp://ftp.ee.lbl.gov/
tcpdump-*.tar.Z, 1990.
[16] M. Allman, V. Paxson, and E. Blanton. TCP Congestion Control.
RFC 5681, 2009.
[17] M. Allman, V. Paxson, and W. Stevens. TCP Congestion Control.
RFC 2581, 1999.
[18] J. B. Postel. Transmission Control Protocol. RFC 793, 1981.
[19] M. Mellia, M. Meo, and L. Muscariello. Tcp anomalies : identification
and analysis.
[20] J. Fan, J. Xu, H. Mostafa, and B. Sue. Prefix-preserving ip address
anonymization. Elsevier, pages 253–272, 7 October 2004.
[21] R. NCC. Ripe atlas, 2010.
[22] official website. Raspberry pi.
[23] B.Augustin, X. Cuvellier, B. Orgogozo, F. Viger, T. Friedman, M. La-
tapy, C. Magnien, and R. Teixeira. Avoiding traceroute anomalies with
paris traceroute. In Proceedings of the 6th ACM SIGCOMM conference
on Internet measurement, pages 153–158. ACM, 2006.
[24] Réhan Noordally, Xavier Nicolay, Pascal Anelli, Richard Lorion, and
Pierre Ugo Tournoux. Analysis of internet latency : the reunion island
case. In Asian Internet Engineering Conference, pages 49–56. ACM,
2016.
[25] R. Noordally, X. Nicolay, Y. Gangat, and P. Anelli. How long delays
impact tcp performance for a connectivity from reunion island ? ArXiv
e-prints, 2017.
53
[26] http://gs.statcounter.com/#browser-RE-monthly-201511-201612.
[27] S. Floyd, D. K. K. Ramakrishnan, and D. L. Black. The Addition of
Explicit Congestion Notification(ECN) to IP. RFC 3168, 2001.
[28] A. ravoavahy. Analyse de performance de la voip sur un backbone mpls
avec trafic engineering.
[29] R. T. Braden. Requirements for Internet hosts— communication layers.
RFC 1122, 1989.
[30] Himanshuz.chd. Wireshark - the best open source network packet ana-
lyzer (part i).
[31] J. Luby. Règlement européen sur la protection des données.
[32] Enterprise networking with windows vista. https://technet.
microsoft.com/en-us/library/cc507851.aspx. Accessed : 2017-03-
15.
54
