air - User contributions [en]

PROJET-INFO5 Kiné Connecté

2019-02-01T14:33:20Z

Amina.Boucherima:

=Le projet en quelques mots=
[[File:CNX_fonctionnement.png|390px|thumb|right|Fonctionnement des canaux semi-circulaire lors d'un mouvement]]
Le système vestibulaire sous-tend le sens de l'équilibre. Il s'agit d'un sens bien particulier car on n'en prend conscience que lorsqu'il dysfonctionne, au cours d'un vertige par exemple.

L'oreille peut être découpée en 3 parties :
* L'oreille externe
* L'oreille moyenne
* L'oreille interne

C'est au niveau de l'oreille interne que se situent les capteurs du système vestibulaire, plus précisément au niveau du labyrinthe. Ce système étant fortement connecté au système moteur participe au maintient de la posture et à la coordination des mouvements réflexes des yeux et de la tête. En réalité, l'équilibration est plus complexe et ne se résume pas qu'au système vestibulaire. Le cerveau fusionne les signaux en provenance de plusieurs sens pour nous permettre la perception de soi dans l'espace.
Le labyrinthe est composé des canaux semi-circulaires, l'utricule et le saccule.
Les canaux semi-circulaires servent à percevoir les accélérations angulaires. Ils sont disposés selon trois plans perpendiculaires de telle sorte que l'excitation de l'un provoque l'inhibition des autres.

On peut être amené à suivre une rééducation en cas de dysfonctionnement du système. Les exercices de rééducation vont consister à jouer sur ce réflexe vestibulo-visuel. Par exemple, un exercice pourrait consister à viser une cible à une vitesse suffisamment élevée et faire lire un mot.

Le but de ce projet est de créer un dispositif et une application permettant de réaliser ces exercices depuis chez soi et d'offrir la possibilité au kinésithérapeute de suivre son patient à distance.

=L'équipe et leurs rôles=

* BELGUENDOUZ Sekina : Chef de projet + Scrum Master
* AUBERT Vincent : Developpeur
* BOUCHERIMA Amina : Developpeur
* EZ-ZINE Najwa : Respo communication + Developpeur

=Gestion de projet=
Choix des outils :

* [https://trello.com/b/fG3qFfuw/ Trello] : pour la répartition et la gestion des tâches hors code
* ''Gitlab'' : pour l'implémentation, le versionning et deploiement
* [https://drive.google.com/drive/folders/15_7hIqF6kbZqdsFaEFD-vzJTNJeuDADi?usp=sharing Drive] : pour le travail en collaboration et le partage de documents (arbre des tâches, IHM ...)

=SCRUM=
==Sprint 1 - Du 28/01/18 au 03/02/18 ==
==Sprint 2 - Du 04/02/18 au 10/02/18 ==
==Sprint 3 - Du 11/02/18 au 17/02/18 ==
==Sprint 4 - Du 18/02/18 au 24/02/18 ==
==Sprint 5 - Du 25/02/18 au 03/03/18 ==

=Journal=
[[Media:.pdf | Nombre d'heures de travail]]

==Sprint 1==
{|class="wikitable alternance"
|+
|-
|
!scope="col"| Date
!scope="col"| AUBERT Vincent
!scope="col"| BELGUENDOUZ Sekina
!scope="col"| BOUCHERIMA Amina
!scope="col"| EZ-ZINE Najwa
|-

| colspan="8" style="text-align: center; background-color:rgb(146, 229, 201);"| SPRINT 1
|-

|-
| rowspan="2" | Mardi 29/01
| rowspan="1" | Tâches
| style="width: 225px;" |
* Attribution des rôles
* Mise en place des outils d’organisation
* Préparation des questions
* Phase d’étude du projet (MindMap)
* Rencontre avec Vestib+
* Récapitulatif de la rencontre
* Report du MindMap sous format numérique
| style="width: 225px;" |
* Attribution des rôles
* Mise en place des outils d’organisation
* Préparation des questions
* Phase d’étude du projet (MindMap)
* Rencontre avec Vestib+
* Récapitulatif de la rencontre
* Determination de l'organisation Scrum
| style="width: 225px;" |
* Attribution des rôles
* Mise en place des outils d’organisation
* Préparation des questions
* Phase d’étude du projet (MindMap)
* Rencontre avec Vestib+
* Recherche des technologies
* Début du déploiement des technos
| style="width: 225px;" |
* Attribution des rôles
* Mise en place des outils d’organisation
* Préparation des questions (MindMap)
* Phase d’étude du projet
* Rencontre avec Vestib+
* Récapitulatif de la rencontre
* Report sur Trello des tâches
|-

|-
| rowspan="1" | Remarques
| style="width: 225px;" style="color:purple" |
* Remarques Vincent
| style="width: 225px;" style="color:purple" |
* Remarques Sekina
| style="width: 225px;" style="color:purple" |
* Remarques Amina
| style="width: 225px;" style="color:purple"|
* Remarques Najwa
|-

|-
| rowspan="2" | Mercredi 30/01
| rowspan="1" | Tâches
| style="width: 225px;" |
* Realisation du schéma base de données
* Recherche sur l'utilisation du Git ....
| style="width: 225px;" |
* Realisation du schéma base de données
* Réalisation du diagramme context et report sur draw.io
* Réalisation de la vue logique et report sur draw.io
* Réalisation de la vue physique et report sur draw.io
| style="width: 225px;" |
* Realisation du schéma base de données
* Continuation du Tutoriel sur les technologies:
** Mise en place d'un frontend angular basique.
** Mise en place de l'API avec Node.js et Express.js.
** Mise en place d'un exemple de base de données.
** Mise en place de la connexion entre la base de donnée et l'API avec Mangoose.

| style="width: 225px;" |
* Realisation du schéma base de données
* Report sur draw.io de la base de données
* Début de rédaction de la partie théorique
|-

|-
| rowspan="1" | Remarques
| style="width: 225px;" style="color:purple" |
* Remarques Vincent
| style="width: 225px;" style="color:purple" |
* Remarques Sekina
| style="width: 225px;" style="color:purple" |
* Remarques Amina: Problème pour retrouver la base en local
| style="width: 225px;" style="color:purple"|
* Remarques Najwa
|-

|}

=Maquettes=

<gallery>
File:PROJET-INFO5_Maquette.png
</gallery>

=SRS=
[[ECOM-1FO_1819_mycamping_L5_SRS|SRS]]

=Diagrammes UML=
<gallery>
File:PROJET-INFO5_DDC.png| Diagramme de contexte.
File:PROJET-INFO5_VL.png| Vue logique.
File:PROJET-INFO5_VP.png| Vue physique.
File:PROJET-INFO5_BDD.png| Base de données.
</gallery>

=Modèles des tâches=
<gallery>
File:Modèle_de_Taches_Scénario_KC.jpg| Modèle de Taches
</gallery>

=Evaluation IHM réalisée=

<gallery>
File:IHM-Abstraite_KC.png| IHM Abstraite
</gallery>

=Evaluation économique du projet=

=Slides des Audits=
* [[Media:PROJET-INFO5_KC_Audit1.pdf]]

* [[Media:PROJET-INFO5_KC_Audit2.pdf]]

File:VT2018 CDN presentation.pdf

2019-01-14T00:00:34Z

Amina.Boucherima:

VT2018 CDN Demo

2019-01-13T23:05:22Z

Amina.Boucherima:

Démonstration avec Amazon CloudFront, un service Web qui accélère la distribution des contenus Web statiques et dynamiques. CloudFront diffuse votre contenu à travers un réseau mondial d'emplacements périphériques.

Suivre le tutoriel suivant pour configurer CloudFront et distribuer du contenu:
https://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html

VT2018 CDN Demo

2019-01-13T23:04:19Z

Amina.Boucherima: Created page with "Démonstration avec Amazon CloudFront, un service Web qui accélère la distribution des contenus Web statiques et dynamiques. CloudFront diffuse les contenus à travers un r..."

Démonstration avec Amazon CloudFront, un service Web qui accélère la distribution des contenus Web statiques et dynamiques. CloudFront diffuse les contenus à travers un réseau mondial d'emplacements périphériques.

Suivre le tutoriel suivant pour configurer CloudFront et distribuer du contenu:
https://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html

VT2018

2019-01-13T22:58:01Z

Amina.Boucherima:

[[VT2017|<< Etudes 2017]] [[VT|Sommaire]] [[VT2019|Etudes 2019 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en RICM5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.
Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?

La présentation peut être réalisée avec [[reveal.js]]

[[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]

=Affectation des sujets=
[[File:AffectationSujetsVT2018.pdf]]

=Planning=
* Vendredi 7/9: présentation et choix des sujets
[[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* Lundi 12/11: (GPB,DD en visio)
** 1: Julien COURTIAL - Apollo 2.0, [[VT2018_Apollo|Fiche de synthèse]], [[Media:Apollo_Auto_Platform.pdf|Transparents]], [https://github.com/ApolloAuto/apollo/tree/master/docs/demo_guide Démo]
** 2: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]] (Reporté)
** 3: Servan CHARLOT - [[OpenWhisk]] : [[VT2018_OpenWhisk|Fiche de synthèse]], [[Media:VT2018_OpenWhisk_presentation.pdf|Transparents]], [[VT2018_OpenWhisk_Demo|Démo]]
** 4: Théo ECHEVET - Fabric8, [[VT2018_fabric8|Fiche de synthèse]], [[Media:Fabric8_Pres_Theo_Echevet.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 5: Bastien TERRIER - [[Performance_Monitoring|Performance Monitoring]], [[VT2018_Performance_Monitoring|Fiche de synthèse]], [[Media:VT2018_Performance_Monitoring_presentation.pdf|Transparents]], [[VT2018_Performance_Monitoring_Demo|Démo]]
* Lundi 19/11: (GPB,DD en visio)
** 6: Samuel BAMBA - DevSecOps, [[VT2018_DevSecOps|Fiche de synthèse]], [[Media:VT2018_DevSecOps.pdf|Transparents]], [https://github.com/CoolerVoid/codewarrior Démo]
** 7: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]] (reporté)
** 8: Thibaud VEGREVILLE, Techniques et technologies de "Lag Compensation" dans les jeux en ligne, [[VT2018_Lag_Compensation|Fiche de synthèse]], [[Media:Lag_Compensation_in_Games.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 9: Hugo GROS-DAILLON - [[ActionHero.js]], [[VT2018_ActionHero|Fiche de synthèse]], [[Media:VT2018ActionHero.pdf|Transparents]], [https://github.com/HugoSecteur4/DemoVT2018ActionHero/tree/master/ActionHero Démo]
** 10: Vincent AUBERT - Apache MXNet : Demo avec Intel Movidius, [[VT2018_Apache_Mxnet|Fiche de synthèse]], [[Media:VT2018_Mxnet_presentation.pdf|Transparents]], [[VT2018_Mxnet_Demo|Démo]]
* Lundi 10/12: (GPB+DD)
** 11: Joffrey FERREIRA - Keycloak, [[VT2018_Keycloak|Fiche de synthèse]], [[Media:VT2018_Keycloak_presentation.pdf|Transparents]], [[VT2018_Keycloak_Demo|Démo]]
** 12: Loris GENTILLON - Gceasy, [[VT2018_GCeasy-synthese|Fiche de synthèse]], [[Media:GCeasy_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 13: Thomas OZENDA - Zipkin et Daper, [[VT2018_Zipkin|Fiche de synthèse]], [[Media:VT2018_Zipkin_presentation.pdf|Transparents]], [[VT2018_Zipkin_Demo|Démo]]
** 14: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]] (reporté)
** 15: Enzo MOLION - Web3j, [[VT2018_Web3j|Fiche de synthèse]], [[Media:Presentation_Web3j.pdf|Transparents]], [https://air.imag.fr/index.php/VT2018_Web3j#D.C3.A9monstration Démo]
* Lundi 17/12: (GPB)
** 16: Quentin FOMBRAON - Web Assembly, [[VT2018_WebAssembly|Fiche de synthèse]], [[Media:VT2018_WebAssembly_presentation.pdf|Transparents]], [[VT2018_WebAssembly#D.C3.A9monstration|Démo]]
** 17: Timothée DEPRIESTER - Kafka Stream, [[VT2018_Kafka|Fiche de synthèse]], [[Media:VT2018_kafka_presentation.pdf|Transparents]], [[VT2018_kafka_Demo|Démo]]
** 18: Benjamin BESNIER - Apache Beam, [[VT2018_ApacheBeam|Fiche de synthèse]], [[Media:VT2018_ApacheBeam_presentation.pdf|Transparents]], [[VT2018_ApacheBeam#Demonstration|Démo]]
** 19: Théo LEVESQUE - OpenShift, [[VT2018_OpenShift|Fiche de synthèse]], [[Media:VT2018_OpenShift.pdf|Transparents]], [[VT2018_OpenShift#D.C3.A9monstration|Démo]]
** 20: William WEILL - CMS, [[VT2018_CrafterCMS|Fiche de synthèse]], [[Media:VT2018_CrafterCMS.pdf|Transparents]], [[VT2018_CrafterCMS#D.C3.A9monstration|Démo]]
* Lundi 07/01/2019: (GPB+DD)
** 21: Tim LEPAGE - Moby, [[VT2018_Moby|Fiche de synthèse]], [[Media:VT2018_Moby_presentation.pdf|Transparents]], [[VT2018_Moby_Demo|Démo]]
** 22: Cédric LAFRASSE - SIG, [[VT2018_SIG|Fiche de synthèse]], [[Media:VT2018_SIG_presentation.pdf|Transparents]], [[VT2018_SIG#Demonstration|Démo]]
** 23: Léo VALETTE - Architectures de processeurs pour le Deep Learning (NPU): Démo de l'Intel Movidius, , [[VT2018_NPU|Fiche de synthèse]], [[Media:VT2018_NPU_presentation.pdf|Transparents]], [[VT2018_NPU_Demo|Démo]]
** 24: Florian CUZIN - Hazelcast IMDG, [[VT2018_Hazelcast_IMDG|Fiche de synthèse]], [[Media:Hazelcast_IMDG_Presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 25: Raphael MANGER - Apache Solr, [[VT2018_Apache_Solr|Fiche de synthèse]], [[Media:Apache_Solr.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
* Lundi 14/01/2019: (GPD+DD)
** 26: Amina BOUCHERIMA - Content delivery networks, [[VT2018_CDN|Fiche de synthèse]], [[Media:VT2018_CDN_presentation.pdf|Transparents]], [[VT2018_CDN_Demo|Démo]]
** 27: Najwa EZ-ZINE - FIDO, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 28: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]]
** 29: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]]
** 30: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]

VT2018

2019-01-13T22:57:24Z

Amina.Boucherima:

[[VT2017|<< Etudes 2017]] [[VT|Sommaire]] [[VT2019|Etudes 2019 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en RICM5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.
Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?

La présentation peut être réalisée avec [[reveal.js]]

[[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]

=Affectation des sujets=
[[File:AffectationSujetsVT2018.pdf]]

=Planning=
* Vendredi 7/9: présentation et choix des sujets
[[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* Lundi 12/11: (GPB,DD en visio)
** 1: Julien COURTIAL - Apollo 2.0, [[VT2018_Apollo|Fiche de synthèse]], [[Media:Apollo_Auto_Platform.pdf|Transparents]], [https://github.com/ApolloAuto/apollo/tree/master/docs/demo_guide Démo]
** 2: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]] (Reporté)
** 3: Servan CHARLOT - [[OpenWhisk]] : [[VT2018_OpenWhisk|Fiche de synthèse]], [[Media:VT2018_OpenWhisk_presentation.pdf|Transparents]], [[VT2018_OpenWhisk_Demo|Démo]]
** 4: Théo ECHEVET - Fabric8, [[VT2018_fabric8|Fiche de synthèse]], [[Media:Fabric8_Pres_Theo_Echevet.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 5: Bastien TERRIER - [[Performance_Monitoring|Performance Monitoring]], [[VT2018_Performance_Monitoring|Fiche de synthèse]], [[Media:VT2018_Performance_Monitoring_presentation.pdf|Transparents]], [[VT2018_Performance_Monitoring_Demo|Démo]]
* Lundi 19/11: (GPB,DD en visio)
** 6: Samuel BAMBA - DevSecOps, [[VT2018_DevSecOps|Fiche de synthèse]], [[Media:VT2018_DevSecOps.pdf|Transparents]], [https://github.com/CoolerVoid/codewarrior Démo]
** 7: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]] (reporté)
** 8: Thibaud VEGREVILLE, Techniques et technologies de "Lag Compensation" dans les jeux en ligne, [[VT2018_Lag_Compensation|Fiche de synthèse]], [[Media:Lag_Compensation_in_Games.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 9: Hugo GROS-DAILLON - [[ActionHero.js]], [[VT2018_ActionHero|Fiche de synthèse]], [[Media:VT2018ActionHero.pdf|Transparents]], [https://github.com/HugoSecteur4/DemoVT2018ActionHero/tree/master/ActionHero Démo]
** 10: Vincent AUBERT - Apache MXNet : Demo avec Intel Movidius, [[VT2018_Apache_Mxnet|Fiche de synthèse]], [[Media:VT2018_Mxnet_presentation.pdf|Transparents]], [[VT2018_Mxnet_Demo|Démo]]
* Lundi 10/12: (GPB+DD)
** 11: Joffrey FERREIRA - Keycloak, [[VT2018_Keycloak|Fiche de synthèse]], [[Media:VT2018_Keycloak_presentation.pdf|Transparents]], [[VT2018_Keycloak_Demo|Démo]]
** 12: Loris GENTILLON - Gceasy, [[VT2018_GCeasy-synthese|Fiche de synthèse]], [[Media:GCeasy_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 13: Thomas OZENDA - Zipkin et Daper, [[VT2018_Zipkin|Fiche de synthèse]], [[Media:VT2018_Zipkin_presentation.pdf|Transparents]], [[VT2018_Zipkin_Demo|Démo]]
** 14: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]] (reporté)
** 15: Enzo MOLION - Web3j, [[VT2018_Web3j|Fiche de synthèse]], [[Media:Presentation_Web3j.pdf|Transparents]], [https://air.imag.fr/index.php/VT2018_Web3j#D.C3.A9monstration Démo]
* Lundi 17/12: (GPB)
** 16: Quentin FOMBRAON - Web Assembly, [[VT2018_WebAssembly|Fiche de synthèse]], [[Media:VT2018_WebAssembly_presentation.pdf|Transparents]], [[VT2018_WebAssembly#D.C3.A9monstration|Démo]]
** 17: Timothée DEPRIESTER - Kafka Stream, [[VT2018_Kafka|Fiche de synthèse]], [[Media:VT2018_kafka_presentation.pdf|Transparents]], [[VT2018_kafka_Demo|Démo]]
** 18: Benjamin BESNIER - Apache Beam, [[VT2018_ApacheBeam|Fiche de synthèse]], [[Media:VT2018_ApacheBeam_presentation.pdf|Transparents]], [[VT2018_ApacheBeam#Demonstration|Démo]]
** 19: Théo LEVESQUE - OpenShift, [[VT2018_OpenShift|Fiche de synthèse]], [[Media:VT2018_OpenShift.pdf|Transparents]], [[VT2018_OpenShift#D.C3.A9monstration|Démo]]
** 20: William WEILL - CMS, [[VT2018_CrafterCMS|Fiche de synthèse]], [[Media:VT2018_CrafterCMS.pdf|Transparents]], [[VT2018_CrafterCMS#D.C3.A9monstration|Démo]]
* Lundi 07/01/2019: (GPB+DD)
** 21: Tim LEPAGE - Moby, [[VT2018_Moby|Fiche de synthèse]], [[Media:VT2018_Moby_presentation.pdf|Transparents]], [[VT2018_Moby_Demo|Démo]]
** 22: Cédric LAFRASSE - SIG, [[VT2018_SIG|Fiche de synthèse]], [[Media:VT2018_SIG_presentation.pdf|Transparents]], [[VT2018_SIG#Demonstration|Démo]]
** 23: Léo VALETTE - Architectures de processeurs pour le Deep Learning (NPU): Démo de l'Intel Movidius, , [[VT2018_NPU|Fiche de synthèse]], [[Media:VT2018_NPU_presentation.pdf|Transparents]], [[VT2018_NPU_Demo|Démo]]
** 24: Florian CUZIN - Hazelcast IMDG, [[VT2018_Hazelcast_IMDG|Fiche de synthèse]], [[Media:Hazelcast_IMDG_Presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 25: Raphael MANGER - Apache Solr, [[VT2018_Apache_Solr|Fiche de synthèse]], [[Media:Apache_Solr.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
* Lundi 14/01/2019: (GPD+DD)
** 26: Amina BOUCHERIMA - Content delivery networks, [[VT2018_CDN|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_CDN_Demo|Démo]]
** 27: Najwa EZ-ZINE - FIDO, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 28: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]]
** 29: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]]
** 30: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]

VT2018 CDN

2019-01-13T22:52:03Z

Amina.Boucherima: /* Abstract */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=
A content delivery network (CDN) refers to a group of geographically distributed servers whose purpose is to quickly transfer content. CDNs are widely used to solve a major problem: latency. When a user requests to load a web page, the time to access content can be very long. This latency is influenced by several factors that can be specific to the content such as the loading of images and videos, but one of the main reasons is the physical distance between the user and the web site hosting server. The objective of the CDNs is therefore to reduce this physical distance and improve the speed and performance of the site.

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.
[[File:consolidated-cdn-map.png|center]]

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.
[[File:scattered-cdn-map.png|center]]

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]

[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

*https://www.webopedia.com/TERM/C/CDN.html
*https://www.cloudflare.com/learning/cdn/what-is-a-cdn/
*https://searchnetworking.techtarget.com/definition/CDN-content-delivery-network
*https://blog.cdnsun.com/understanding-cdn-dns-routing-unicast-versus-anycast/
*https://www.incapsula.com/cdn-guide/what-is-cdn-how-it-works.html
*https://www.akamai.com/uk/en/resources/content-distribution-network.jsp
*https://www.globaldots.com/content-delivery-network-explained/
*https://en.optimicdn.com/technology/

VT2018 CDN

2019-01-13T22:42:00Z

Amina.Boucherima: /* Références */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.
[[File:consolidated-cdn-map.png|center]]

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.
[[File:scattered-cdn-map.png|center]]

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]

[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

*https://www.webopedia.com/TERM/C/CDN.html
*https://www.cloudflare.com/learning/cdn/what-is-a-cdn/
*https://searchnetworking.techtarget.com/definition/CDN-content-delivery-network
*https://blog.cdnsun.com/understanding-cdn-dns-routing-unicast-versus-anycast/
*https://www.incapsula.com/cdn-guide/what-is-cdn-how-it-works.html
*https://www.akamai.com/uk/en/resources/content-distribution-network.jsp
*https://www.globaldots.com/content-delivery-network-explained/
*https://en.optimicdn.com/technology/

VT2018 CDN

2019-01-13T22:39:49Z

Amina.Boucherima: /* Entreprises */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.
[[File:consolidated-cdn-map.png|center]]

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.
[[File:scattered-cdn-map.png|center]]

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]

[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

VT2018 CDN

2019-01-13T22:39:00Z

Amina.Boucherima: /* Entreprises */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.
[[File:consolidated-cdn-map.png|center]]

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.
[[File:scattered-cdn-map.png|center]]

==Entreprises==

[[File:Akamai.jpg|center]] [[File:MaxCDN.jpg|center]] [[File:Incapsula.jpg|center]] [[File:Rackspace.jpg|center]][[File:Cloudflare.jpg|center]]

[[File:Amazon_AWS.jpg|center]] [[File:Verizon.jpg|center]] [[File:Fastly.jpg|center]] [[File:Hibernia.jpg|center]] [[File:Limelight.jpg|center]]

==Références==

VT2018 CDN

2019-01-13T22:38:12Z

Amina.Boucherima: /* Topologies */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.
[[File:consolidated-cdn-map.png|center]]

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.
[[File:scattered-cdn-map.png|center]]

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]

[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

VT2018 CDN

2019-01-13T22:36:57Z

Amina.Boucherima: /* Topologies */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.
[[File:consolidated-cdn-map.png|center]]

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.
[[File:optimicdn-multi-cdn-map-3.png]]

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]

[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

VT2018 CDN

2019-01-13T22:36:28Z

Amina.Boucherima: /* Topologies */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.
[[File:consolidated-cdn-map.png]]

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.
[[File:optimicdn-multi-cdn-map-3.png]]

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]

[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

File:Scattered-cdn-map.png

2019-01-13T22:34:28Z

Amina.Boucherima:

File:Consolidated-cdn-map.png

2019-01-13T22:34:02Z

Amina.Boucherima:

VT2018 CDN

2019-01-13T22:31:42Z

Amina.Boucherima: /* Entreprises */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]

[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

VT2018 CDN

2019-01-13T22:31:34Z

Amina.Boucherima: /* Entreprises */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]

[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

VT2018 CDN

2019-01-13T22:31:09Z

Amina.Boucherima: /* Entreprises */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.

==Entreprises==

[[File:Akamai.jpg]] [[File:MaxCDN.jpg]] [[File:Incapsula.jpg]] [[File:Rackspace.jpg]][[File:Cloudflare.jpg]]
[[File:Amazon_AWS.jpg]] [[File:Verizon.jpg]] [[File:Fastly.jpg]] [[File:Hibernia.jpg]] [[File:Limelight.jpg]]

==Références==

VT2018 CDN

2019-01-13T22:27:36Z

Amina.Boucherima: /* Architecture */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.

==Entreprises==

==Références==

VT2018 XXX

2019-01-13T22:26:12Z

Amina.Boucherima: Replaced content with "=Auteur= *Nom : *Sujet : =Résumé= =Abstract= =Synthèse= ==Références=="

=Auteur=
*Nom :
*Sujet :

=Résumé=

=Abstract=

=Synthèse=

==Références==

VT2018 CDN

2019-01-13T22:25:42Z

Amina.Boucherima: Created page with "=Auteur= *Nom : Amina BOUCHERIMA *Mail : amina.boucherima@hotmail.com *Sujet : Content Delivery Network =Résumé= Un réseau de diffusion de contenu (CDN) désigne un groupe..."

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.

==Références==

VT2018 XXX

2019-01-13T22:25:24Z

Amina.Boucherima:

=Auteur=
*Nom :
*Sujet :

=Résumé=

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.

==Références==

VT2018

2019-01-13T22:24:32Z

Amina.Boucherima:

[[VT2017|<< Etudes 2017]] [[VT|Sommaire]] [[VT2019|Etudes 2019 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en RICM5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.
Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?

La présentation peut être réalisée avec [[reveal.js]]

[[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]

=Affectation des sujets=
[[File:AffectationSujetsVT2018.pdf]]

=Planning=
* Vendredi 7/9: présentation et choix des sujets
[[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* Lundi 12/11: (GPB,DD en visio)
** 1: Julien COURTIAL - Apollo 2.0, [[VT2018_Apollo|Fiche de synthèse]], [[Media:Apollo_Auto_Platform.pdf|Transparents]], [https://github.com/ApolloAuto/apollo/tree/master/docs/demo_guide Démo]
** 2: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]] (Reporté)
** 3: Servan CHARLOT - [[OpenWhisk]] : [[VT2018_OpenWhisk|Fiche de synthèse]], [[Media:VT2018_OpenWhisk_presentation.pdf|Transparents]], [[VT2018_OpenWhisk_Demo|Démo]]
** 4: Théo ECHEVET - Fabric8, [[VT2018_fabric8|Fiche de synthèse]], [[Media:Fabric8_Pres_Theo_Echevet.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 5: Bastien TERRIER - [[Performance_Monitoring|Performance Monitoring]], [[VT2018_Performance_Monitoring|Fiche de synthèse]], [[Media:VT2018_Performance_Monitoring_presentation.pdf|Transparents]], [[VT2018_Performance_Monitoring_Demo|Démo]]
* Lundi 19/11: (GPB,DD en visio)
** 6: Samuel BAMBA - DevSecOps, [[VT2018_DevSecOps|Fiche de synthèse]], [[Media:VT2018_DevSecOps.pdf|Transparents]], [https://github.com/CoolerVoid/codewarrior Démo]
** 7: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]] (reporté)
** 8: Thibaud VEGREVILLE, Techniques et technologies de "Lag Compensation" dans les jeux en ligne, [[VT2018_Lag_Compensation|Fiche de synthèse]], [[Media:Lag_Compensation_in_Games.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 9: Hugo GROS-DAILLON - [[ActionHero.js]], [[VT2018_ActionHero|Fiche de synthèse]], [[Media:VT2018ActionHero.pdf|Transparents]], [https://github.com/HugoSecteur4/DemoVT2018ActionHero/tree/master/ActionHero Démo]
** 10: Vincent AUBERT - Apache MXNet : Demo avec Intel Movidius, [[VT2018_Apache_Mxnet|Fiche de synthèse]], [[Media:VT2018_Mxnet_presentation.pdf|Transparents]], [[VT2018_Mxnet_Demo|Démo]]
* Lundi 10/12: (GPB+DD)
** 11: Joffrey FERREIRA - Keycloak, [[VT2018_Keycloak|Fiche de synthèse]], [[Media:VT2018_Keycloak_presentation.pdf|Transparents]], [[VT2018_Keycloak_Demo|Démo]]
** 12: Loris GENTILLON - Gceasy, [[VT2018_GCeasy-synthese|Fiche de synthèse]], [[Media:GCeasy_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 13: Thomas OZENDA - Zipkin et Daper, [[VT2018_Zipkin|Fiche de synthèse]], [[Media:VT2018_Zipkin_presentation.pdf|Transparents]], [[VT2018_Zipkin_Demo|Démo]]
** 14: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]] (reporté)
** 15: Enzo MOLION - Web3j, [[VT2018_Web3j|Fiche de synthèse]], [[Media:Presentation_Web3j.pdf|Transparents]], [https://air.imag.fr/index.php/VT2018_Web3j#D.C3.A9monstration Démo]
* Lundi 17/12: (GPB)
** 16: Quentin FOMBRAON - Web Assembly, [[VT2018_WebAssembly|Fiche de synthèse]], [[Media:VT2018_WebAssembly_presentation.pdf|Transparents]], [[VT2018_WebAssembly#D.C3.A9monstration|Démo]]
** 17: Timothée DEPRIESTER - Kafka Stream, [[VT2018_Kafka|Fiche de synthèse]], [[Media:VT2018_kafka_presentation.pdf|Transparents]], [[VT2018_kafka_Demo|Démo]]
** 18: Benjamin BESNIER - Apache Beam, [[VT2018_ApacheBeam|Fiche de synthèse]], [[Media:VT2018_ApacheBeam_presentation.pdf|Transparents]], [[VT2018_ApacheBeam#Demonstration|Démo]]
** 19: Théo LEVESQUE - OpenShift, [[VT2018_OpenShift|Fiche de synthèse]], [[Media:VT2018_OpenShift.pdf|Transparents]], [[VT2018_OpenShift#D.C3.A9monstration|Démo]]
** 20: William WEILL - CMS, [[VT2018_CrafterCMS|Fiche de synthèse]], [[Media:VT2018_CrafterCMS.pdf|Transparents]], [[VT2018_CrafterCMS#D.C3.A9monstration|Démo]]
* Lundi 07/01/2019: (GPB+DD)
** 21: Tim LEPAGE - Moby, [[VT2018_Moby|Fiche de synthèse]], [[Media:VT2018_Moby_presentation.pdf|Transparents]], [[VT2018_Moby_Demo|Démo]]
** 22: Cédric LAFRASSE - SIG, [[VT2018_SIG|Fiche de synthèse]], [[Media:VT2018_SIG_presentation.pdf|Transparents]], [[VT2018_SIG#Demonstration|Démo]]
** 23: Léo VALETTE - Architectures de processeurs pour le Deep Learning (NPU): Démo de l'Intel Movidius, , [[VT2018_NPU|Fiche de synthèse]], [[Media:VT2018_NPU_presentation.pdf|Transparents]], [[VT2018_NPU_Demo|Démo]]
** 24: Florian CUZIN - Hazelcast IMDG, [[VT2018_Hazelcast_IMDG|Fiche de synthèse]], [[Media:Hazelcast_IMDG_Presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 25: Raphael MANGER - Apache Solr, [[VT2018_Apache_Solr|Fiche de synthèse]], [[Media:Apache_Solr.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
* Lundi 14/01/2019: (GPD+DD)
** 26: Amina BOUCHERIMA - Content delivery networks, [[VT2018_CDN|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 27: Najwa EZ-ZINE - FIDO, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 28: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]]
** 29: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]]
** 30: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]

File:Limelight.jpg

2019-01-13T22:22:40Z

Amina.Boucherima:

File:Hibernia.jpg

2019-01-13T22:22:03Z

Amina.Boucherima:

File:Fastly.jpg

2019-01-13T22:21:51Z

Amina.Boucherima:

File:Verizon.jpg

2019-01-13T22:21:32Z

Amina.Boucherima:

File:Amazon AWS.jpg

2019-01-13T22:21:10Z

Amina.Boucherima:

File:Cloudflare.jpg

2019-01-13T22:20:58Z

Amina.Boucherima:

File:Rackspace.jpg

2019-01-13T22:20:37Z

Amina.Boucherima:

File:Incapsula.jpg

2019-01-13T22:20:10Z

Amina.Boucherima:

File:MaxCDN.jpg

2019-01-13T22:19:52Z

Amina.Boucherima:

File:Akamai.jpg

2019-01-13T22:18:53Z

Amina.Boucherima:

VT2018 XXX

2019-01-13T22:12:04Z

Amina.Boucherima: /* Architecture */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
=== Les piliers d'un CDN===
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

===Topologies===
L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.

==Références==

VT2018 XXX

2019-01-13T22:11:16Z

Amina.Boucherima: /* Architecture */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

L’architecture d’un CDN est aussi influencée par la topologie du réseau utilisée. Il existe deux modèles de topologies, les CDN dispersés et les CDN consolidés.

*Les CDN dispersés
Les CDN dispersés sont composés d’un grand nombre de PoPs de capacité moyenne. Les PoPs sont généralement positionnés très près les uns des autres favorisant ainsi une amélioration de la vitesse d’accès aux données. Ces CDN sont très efficaces en particulier dans les régions à faible connectivité et sont plus faciles à déployer. Le seul inconvénient est que le RTT peut se prolonger par les multiples points de connexions.

*Les CDN consolidés
Contrairement aux CDN dispersés, les CDN consolidés ont moins de PoPs et sont positionné dans les grands centre de données. Ils sont utilisés pour servir une population plus large et sont plus moderne. Les PoPs de haute capacité sont plus résistant, en particulier lors des attaques DDoS et leurs coûts d’entretien est réduits. Cependant, ils sont moins efficaces dans les régions à faible connectivité et sont plus difficiles à déployer.

==Références==

VT2018 XXX

2019-01-13T22:10:30Z

Amina.Boucherima: /* Architecture */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

*Performance
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

*Fiabilité
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

*Scalabilité
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

==Références==

VT2018 XXX

2019-01-13T22:09:53Z

Amina.Boucherima: /* Routage */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=
Un réseau de diffusion de contenu (CDN) désigne un groupe de serveurs géographiquement distribués dont le but est de transférer rapidement du contenu.
Les CDN sont très largement utilisés afin de résoudre un problème majeur qui est la latence. Lorsqu’un utilisateur demande de charger une page Web, le temps d’accès au contenu peut être très long.
Cette latence est influencée par plusieurs facteurs qui peuvent être propre au contenu comme par exemple le chargement d’images et de vidéos, mais l’une des raisons principale est la distance physique entre l’utilisateur est le serveur d’hébergement du site web.
L’objectif des CDN est donc de diminuer cette distance physique et améliorer la vitesse et la performance du site.

=Abstract=

=Synthèse=

==Histoire==
Les réseaux de diffusion de contenu ont été conçus à partir du moment où l’utilisation du World Wide Web a explosé en popularité au cours des années 1990. Les leaders techniques se sont rendu compte qu’Internet ne pouvait pas faire face à l’augmentation rapide du trafic réseau et devaient trouver une méthode pour gérer la diffusion de données dans le monde.

Fondée en 1998, Akamai Technologies a été la première société à developper les CDN et à les commercialiser. Elle reste jusqu’a nos jours le leader dans le Marché des CDN.

==Fonctionnement==
Afin de minimiser la distance physique entre un utilisateur et le serveur d’hébergement, le CDN stocke le contenu du site dans plusieurs emplacements géographiques, aussi connu sous le nom de Points de Présence (PoPs).
Un PoP est un centre de donnée contenant un certain nombre de serveurs cache. Sa fonction principale est donc de réduire le temps d’aller-retour (RTT) puisque le contenu devient plus proche de l’utilisateur.
Les serveurs cache stockent le contenu mis en cache et sont responsable de la livraison du contenu. Ils ont pour fonction d’accélérer le chargement du site web et réduire la consommation de la bande passante.

==Routage==
Afin d’accélérer le temps de chargement du site et donc améliorer l’expérience des visiteurs, les CDN utilisent un routage particulier appelé routage DNS CDN. Ce routage permet de rediriger les demandes vers les noeuds du CDN dans le monde entier.
Il existe deux types de routage: le DNS Unicast et le DNS Anycast.

===Routage Unicast===

Unicast consiste à attribuer à chaque Point de Présence (PoP) une adresse IP propre à lui. Les sites qui mettent en place des CDN utilisant un routage DNS Unicast permettent de rediriger les visiteurs directement vers un noeud spécifique qui est le noeud le plus proche de la requête.

Lorsqu’un utilisateur demande le chargement d’un site web en tapant l’URL ou en cliquant sur le lien du serveur web principal, le DNS de l’utilisateur le redirige vers le service CDN qui héberge le contenu du site. Puis, il est acheminé vers le PoP le plus proche déterminé grâce à son emplacement en fonction de son adresse IP.

L’utilisation du routage DNS Unicast est à la fois rentable et efficace et sa configuration est très simple à mettre en place puisqu’il faut juste l’intégrer dans le processus DNS standard.

Cependant, puisque la requête est toujours acheminée directement vers le même noeud spécifique et passe toujours par le même chemin de routage, le centre de donnée associé peut subir un trafic important, par exemple lors d’une attaque DDoS, entrainant ainsi un déni de service.
De plus, puisque le CDN utilise l’adresse IP d’origine du visiteur afin de trouver le PoP le plus proche, la détermination de cette adresse IP peut être erronée à cause du mécanisme récursif utilisé dans les DNS moderne. Le CDN pourrait donc répondre à l’adresse IP du résolveur DNS et non à celle du client et donc l’envoyer vers un noeud incorrect.

===Routage Anycast===
Les CDN configurés avec Anycast définissent une adresse IP unique pour chaque noeud du réseau. Contrairement à Unicast, au lieu d’utiliser le DNS récursif qui dirige les requête vers le noeud le plus proche, Anycast utilise le Border Gateway Protocol (BGP), un protocole permettant d’échanger des informations de routage et d’accessibilité pour que chaque PoP du réseau CDN connaisse l’état de ses plus proches voisins. Grâce à ce protocole, Anycast garantit la distance la plus courte entre le visiteur et le PoP final en fonction d’une métrique qui n’est pas forcément la distance physique.
Anycast utilise aussi le DNS et à la différence de Unicast, le CDN utilise l’adresse IP du client d’origine et non pas celle du résolveur DNS.
Les avantages de Anycast sont multiples. Il permet une connectivité plus rapide, offre une protection aux attaques DDoS ainsi qu’une grande disponibilité. De plus, la configuration des serveurs est très simplifiée puisqu’une seule configuration DNS est faite sur tous les noeuds du réseau.

==Architecture==
L’architecture choisie d’un CDN doit satisfaire les 3 piliers suivants:

'''*Performance'''
La mission principale d’un CDN est de minimiser la latence afin d’améliorer l’expérience de l’utilisateur. Cela signifie que les Pops doivent être situé à des carrefours importants du réseau afin d’assurer une connectivité idéale.

'''*Fiabilité'''
Selon le type de site web utilisé, assurer un système sans problème peut différer d’un CDN à un autre. En effet, les CDN de sites commerciaux adoptent une approche "zéro point de défaillance" afin d’assurer une haute disponibilité. Le type de routage utilisé joue un très grand rôle dans ce pilier. Utiliser un routage Anycast augmente fortement la disponibilité alors qu’un routage Unicast peut être une source de très graves pannes et défaillances dans le réseau.

'''*Scalabilité'''
Les CDN doivent traiter n’importe quel volume de trafic. Le type de routing influe sur cette capacité. En effet, si le nombre de visiteurs est moyen, un routing Unicast suffit largement pour satisfaire la scalabilité du CDN. Dans le cas contraire, Unicast ne suffit pas puisqu’il n’offre pas de protection contre les attaques DDoS.

==Références==

VT2018 XXX

2019-01-13T22:07:15Z

Amina.Boucherima: /* Routage */

VT2018 XXX

2019-01-13T22:06:47Z

Amina.Boucherima: /* Routage */

VT2018 XXX

2019-01-13T22:04:28Z

Amina.Boucherima: /* Synthèse */

VT2018 XXX

2019-01-13T22:03:12Z

Amina.Boucherima: /* Synthèse */

VT2018 XXX

2019-01-13T22:01:41Z

Amina.Boucherima: /* Résumé */

VT2018 XXX

2019-01-13T21:58:52Z

Amina.Boucherima: /* Auteur */

=Auteur=
*Nom : Amina BOUCHERIMA
*Mail : amina.boucherima@hotmail.com
*Sujet : Content Delivery Network

=Résumé=

=Abstract=

=Synthèse=

==Références==

VT2018 XXX

2019-01-13T21:49:26Z

Amina.Boucherima: /* Auteur */

=Auteur=
*Nom : Amina BOUCHERIMA
*Sujet : Content Delivery Network

=Résumé=

=Abstract=

=Synthèse=

==Références==

ECOM 1F0 2018-19 BTB Amina BOUCHERIMA

2018-12-17T20:22:06Z

Amina.Boucherima: /* Semaine du 4 au 11 décembre */

= Présentation =
Membre de l’équipe du projet Brûle Ta Bûche !
Développement Front-end.

= Journal de bord =

= Semaine du 25 septembre au 2 octobre =

*Attribution des rôles au sein de l’équipe.
*Choix des outils de communications pour la gestion du projet (Trello, Slack, GitLab, Google Drive).
*Réalisation du modèle de tâches et de l’IHM abstraite.

= Semaine du 2 au 9 octobre =

*Choix des technologies utilisées pour le développement du front-end (Bootstrap, Angular, Material design).
*Auto-formation en HTML et CSS.
*Création des maquettes du scénario 1 de notre application.

= Semaine du 9 au 16 octobre =

*Préparation et participation à la soutenance.
*Installation des technologies nécessaires: Java, nodejs, npm, JHipster et Angular.
*Formation Angular (en cours).

= Semaine du 16 au 23 octobre =
*Formation Angular

= Semaine du 23 octobre au 6 novembre =
*Construction de la liste des composants Angular.
*Lecture sur l'architecture Angular + Routing + style guide.
*Manipulation du code client généré parJHipster.
*Conception de l'architecture complète (diagramme de contexte, liste des fonctionnalités, vue logique de haut niveau, vues logiques détaillées, vues dynamiques et vue physique).
*Préparation de l'Audit 2.

= Semaine du 6 au 13 novembre =
* Manipulation du routing utilisé dans le code généré par JHipster.

= Semaine du 13 au 20 novembre =
* Intégration de Angular Material dans le projet.
* Création des composants et mise en place du routing.
= Semaine du 20 au 27 novembre =
* Codage du composant producer-details (page du producteur).
= Semaine du 27 novembre au 4 décembre =
* Mise en place des communications entre composants (passage d'informations entre composants et entre pages).
* Affichage de la page producteur.
= Semaine du 4 au 11 décembre =
* Mise au propre du code généré par JHipster (suppression du code inutile dans notre projet).
* Fusion du code de la page recherche avec le code de la page producteur.

= Semaine du 11 au 18 décembre =
* Intégration de Material Design sur les entités.
* Préparation de la soutenance finale.

ECOM 1F0 2018-19 BTB Amina BOUCHERIMA

2018-12-17T20:09:05Z

Amina.Boucherima: /* Semaine du 11 au 18 décembre */

= Présentation =
Membre de l’équipe du projet Brûle Ta Bûche !
Développement Front-end.

= Journal de bord =

= Semaine du 25 septembre au 2 octobre =

*Attribution des rôles au sein de l’équipe.
*Choix des outils de communications pour la gestion du projet (Trello, Slack, GitLab, Google Drive).
*Réalisation du modèle de tâches et de l’IHM abstraite.

= Semaine du 2 au 9 octobre =

*Choix des technologies utilisées pour le développement du front-end (Bootstrap, Angular, Material design).
*Auto-formation en HTML et CSS.
*Création des maquettes du scénario 1 de notre application.

= Semaine du 9 au 16 octobre =

*Préparation et participation à la soutenance.
*Installation des technologies nécessaires: Java, nodejs, npm, JHipster et Angular.
*Formation Angular (en cours).

= Semaine du 16 au 23 octobre =
*Formation Angular

= Semaine du 23 octobre au 6 novembre =
*Construction de la liste des composants Angular.
*Lecture sur l'architecture Angular + Routing + style guide.
*Manipulation du code client généré parJHipster.
*Conception de l'architecture complète (diagramme de contexte, liste des fonctionnalités, vue logique de haut niveau, vues logiques détaillées, vues dynamiques et vue physique).
*Préparation de l'Audit 2.

= Semaine du 6 au 13 novembre =
* Manipulation du routing utilisé dans le code généré par JHipster.

= Semaine du 13 au 20 novembre =
* Intégration de Angular Material dans le projet.
* Création des composants et mise en place du routing.
= Semaine du 20 au 27 novembre =
* Codage du composant producer-details (page du producteur).
= Semaine du 27 novembre au 4 décembre =
* Mise en place des communications entre composants (passage d'informations entre composants et entre pages).
* Affichage de la page producteur.
= Semaine du 4 au 11 décembre =
* Mise au propre du code généré par JHipster.

= Semaine du 11 au 18 décembre =
* Intégration de Material Design sur les entités.
* Préparation de la soutenance finale.

ECOM 1F0 2018-19 BTB Amina BOUCHERIMA

2018-12-17T20:08:51Z

Amina.Boucherima: /* Semaine du 11 au 18 décembre */

= Présentation =
Membre de l’équipe du projet Brûle Ta Bûche !
Développement Front-end.

= Journal de bord =

= Semaine du 25 septembre au 2 octobre =

*Attribution des rôles au sein de l’équipe.
*Choix des outils de communications pour la gestion du projet (Trello, Slack, GitLab, Google Drive).
*Réalisation du modèle de tâches et de l’IHM abstraite.

= Semaine du 2 au 9 octobre =

*Choix des technologies utilisées pour le développement du front-end (Bootstrap, Angular, Material design).
*Auto-formation en HTML et CSS.
*Création des maquettes du scénario 1 de notre application.

= Semaine du 9 au 16 octobre =

*Préparation et participation à la soutenance.
*Installation des technologies nécessaires: Java, nodejs, npm, JHipster et Angular.
*Formation Angular (en cours).

= Semaine du 16 au 23 octobre =
*Formation Angular

= Semaine du 23 octobre au 6 novembre =
*Construction de la liste des composants Angular.
*Lecture sur l'architecture Angular + Routing + style guide.
*Manipulation du code client généré parJHipster.
*Conception de l'architecture complète (diagramme de contexte, liste des fonctionnalités, vue logique de haut niveau, vues logiques détaillées, vues dynamiques et vue physique).
*Préparation de l'Audit 2.

= Semaine du 6 au 13 novembre =
* Manipulation du routing utilisé dans le code généré par JHipster.

= Semaine du 13 au 20 novembre =
* Intégration de Angular Material dans le projet.
* Création des composants et mise en place du routing.
= Semaine du 20 au 27 novembre =
* Codage du composant producer-details (page du producteur).
= Semaine du 27 novembre au 4 décembre =
* Mise en place des communications entre composants (passage d'informations entre composants et entre pages).
* Affichage de la page producteur.
= Semaine du 4 au 11 décembre =
* Mise au propre du code généré par JHipster.

= Semaine du 11 au 18 décembre =
* Intégration de Material Design sur les entités.

ECOM 1F0 2018-19 BTB Amina BOUCHERIMA

2018-12-17T20:08:27Z

Amina.Boucherima: /* Semaine du 4 au 11 décembre */

ECOM 1F0 2018-19 BTB Amina BOUCHERIMA

2018-12-17T20:05:35Z

Amina.Boucherima: /* Semaine du 27 novembre au 4 décembre */

ECOM 1F0 2018-19 BTB Amina BOUCHERIMA

2018-12-04T07:59:47Z

Amina.Boucherima: /* Semaine du 13 au 20 novembre */