Utilisateur:Marine.bal/Brouillon
Introduction[modifier | modifier le code]
L'HyperText Transfer Protocol, plus connu sous l'abréviation HTTP (littéralement « protocole de transfert hypertexte ») est un protocole de communication client-serveur développé pour le World Wide Web. HTTPS (avec S pour secured, soit « sécurisé ») est la variante du HTTP sécurisée par l'usage des protocoles SSL ou TLS.
HTTP est un protocole de la couche application. Il peut fonctionner sur n'importe quelle connexion fiable, dans les faits on utilise le protocole TCP comme couche de transport. Un serveur HTTP utilise alors par défaut le port 80 (443 pour HTTPS). Une requête HTTP possède plusieurs verbes de base (GET, POST, PUT, PATCH, DELETE) pour effectuer des actions différentes. Ces requêtes ont un certain coût, autant sur l'énergie consommée que sur le temps. De nos jour, ces requêtes ont pris une énorme place dans le monde informatique, cela devient dont intéressant de pouvoir calculer leur coût et les optimiser.
Coût d'une requête HTTP[modifier | modifier le code]
Côté client[modifier | modifier le code]
Intervenants / Acteurs[modifier | modifier le code]
Le protocole HTTP faisant partie de la pile TCP/IP, il faut prendre en compte la négociation des connexions dans la pile TCP/IP. De ce fait, le coût d’une requête HTTP avec beaucoup de données est moindre comparé au coût de plusieurs requêtes HTTP avec peu de données. Cela s’explique en grande partie au fait de devoir ré établir la connexion TCP/IP à chaque nouvelle requête HTTP, d'ajouter les en-têtes HTTP à chaque requête et de formatter la requête complète au niveau du client.[2]
Dans le graphique ci-contre l’axe y est la consommation d'énergie pour une requête HTTP en mAh et l’axe x est la taille du fichier téléchargé par cette requête en byte. La consommation est fixe en dessous de 1024 byte soit environ 0.5-0.6 mAh et elle augmente significativement quand les données dépassent 1024 à cause du protocol HTTP et au protocol de réseau bas niveau TCP et IP qui ajoute des données dans chaque paquet avec un header et un contrôle d’information et d’erreur
Architecture[modifier | modifier le code]
Pour les applications effectuant des requêtes HTTP, il existe différentes architectures logicielles. Certaines vont induire un coût énergétique et temporel important. Deux grandes catégories d'architecture d'applications clientes ressortent :
- Les applications privilégiant l'affichage des informations au fur et à mesure de leur réception. Concrètement, dès qu'elles ont un minimum de données elles affichent les données à l'utilisateur au fil de l'eau. Pour ce faire, l'application cliente en question émet plusieurs requêtes avec des demandes de données différentes afin de ne pas attendre la réception de toutes les données avant affichage. L'expérience utilisateur peut sembler bien meilleure mais le coût d'une telle pratique peut s'avérer important.
- Les applications n'affichant les informations que lorsqu'elles sont toutes reçues. Grâce à cette méthode, l'application ne fait qu'un nombre limité d'appels HTTP avec beaucoup plus de données en retour. De cette façon, moins de connexions TCP sont nécessaires, c'est donc moins couteux.
Environnement[modifier | modifier le code]
Les requêtes HTTP peuvent être réalisées sur différents terminaux. Ce qui signifie que l'environnement va être différent par exemple si c'est un terminal mobile ou non, la puissance du processeur et le réseau entre en compte dans le calcul du coût d'une requête HTTP. Sur un réseau filaire ethernet de bonne qualité nous aurons un coût temporel moindre comparé à un réseau sans fil en wifi par exemple. Concernant le coût énergétique, les requêtes réalisées avec une mauvaise connexion 3G ou EDGE sont très énergivores et beaucoup plus lente. On peut se rendre compte que l'environnement joue un rôle énorme dans ce coût mais on ne peut malheureusement pas souvent influer dessus.
Optimisation[modifier | modifier le code]
Comme expliqué ci-dessus, plus il y a de requêtes HTTP plus ce sera coûteux. C'est bien moins coûteux de réaliser moins de requêtes mais avec des requêtes plus grosse, avec plus de données. Une solution testée et mise en oeuvre pour palier ce soucis[3] a été de rassembler les petites requêtes HTTP en une seule grande requête. Pour ce faire, un proxy a été mis en place récupérant les requêtes et les rassemblant afin d'effectuer une seule et même requête. Cela diminue significativement le coût énergétique puisqu'une amélioration de l'ordre de 15% a été observée. Cette méthode reste faillible car ce proxy rassemble parfois des requêtes qui sont dépendantes, qui doivent être effectuées les unes après les autres et donc n'avait plus le comportement voulu.
Une autre optimisation pour réduire le nombre de requêtes HTTP peut être mise en oeuvre très facilement directement par le développeur. En effet dans certaines applications lorsque l'on modifie une ressource ou qu'on en créé une il faut effectuer une nouvelle requête HTTP pour récupérer cette ressource créée ou mise à jour. L'optimisation serait de retourner la ressource créer ou modifiée directement en réponse de cette requête de création/modification. Ca diminuerait de moitié le nombre de requêtes HTTP.
Bilan[modifier | modifier le code]
Actuellement le coût des requêtes HTTP n'est pas réellement pris en compte et ne constitue pas vraiment un enjeu technique pour les grandes sociétés. L'optimisation de celles-ci reste à la responsabilité du développeur de l'application et est donc assez haut niveau. L'idéal serait d'implémenter toutes ces optimisations et solutions à un niveau plus bas, directement dans les systèmes d'exploitation afin que le développeur ne s'en soucie pas car peu de développeurs sont sensibilisé à cette pratique.
Côté serveur (centre de données)[modifier | modifier le code]
Les centres de données modernes, déployés par les sociétés comme Google, Microsoft et Facebook hébergent souvent des centaines de milliers de serveurs pour fournir un service à des millions d’utilisateurs à l’échelle mondiale. La consommation des centres de données est énorme. Celui de Google, par exemple, utilise 260 millions de watt par an, ce qui coûte des millions de dollars en factures d’électricité.[4]
Architecture[modifier | modifier le code]
Les topologies des centres de données sont sous forme d'arbre.
Communément les arbres ont deux ou trois niveaux de routeurs.
Dans le cas d'une topologie à deux niveaux, la capacité est situé entre 5,000 et 8,000 hôtes.
Pour une topologie à trois niveaux la capacité est de 25,000 hôtes.
Le design à trois niveaux comprend à la racine le noyau, suivi du niveau d’agrégation et enfin le dernier niveau concernant les routeurs et terminaux clients.
Le coût de création d'un nouveau centre de données interconnecté est très important.
En envisageant un coût de 7,000 dollars pour chaque commutateurs 48-ports GigE, 700,000 dollars pour les commutateurs 128-port 10 GigE et sans compter les frais de câblage. Pour une interconnexion supportant 20,000 hôtes avec une bande passante complète pour chaque hôtes on voit que l'on atteint les 37 millions de dollars[5].
Environnement[modifier | modifier le code]
Lorsque le centre de données est dit centralisé, la requête HTTP est envoyée directement vers celui-ci sans calcul de répartition préalable.
Cependant, en pratique, les centres de données sont multiples et géographiquement distribués pour améliorer la latence de service ainsi que la fiabilité. Les centres peuvent se trouver dans différents pays et même sur différents continents. Dans ce cas, le fournisseur de services déploie des nœuds de cartographie, par exemple, avec des serveurs DNS ou des proxy HTTP permettant de diriger les requêtes de l’utilisateur vers le centre de données approprié selon les critères définis. De nouveaux algorithmes de routage ont été proposés dans des travaux récents afin d’économiser l’énergie. Ils peuvent également permettre de répartir la charge entre les centres dans le cas d’un pic de demandes.
Optimisation[modifier | modifier le code]
Beaucoup de services interactifs exécutent des tâches de façon distribuée et itérative, sur l’exemple de 200 mille requêtes de Microsoft Bing [6], on prend en compte qu’une requête ne doit pas nécessairement être exécutée entièrement, aux heures de pointe une exécution partielle peut être suffisante, ceci permet d’économiser entre 3%-10.5% selon le pic de charge et 15.5% dans un centre de données distribué[6].
Bilan[modifier | modifier le code]
Les centres de données sont construit dans le but d'avoir l'infrastructure la plus solide possible permettant de supporter de grandes charges. Les coûts par requêtes ne sont pas vraiment pris en compte, les centres de données ont tendances à s'améliorer de plus en plus pour consommer moins. Les anciens centre de données s'améliorent et permettent d'ajouter les améliorations lors de la construction des nouveaux bâtiments et des nouveaux réseaux.
Bibliographie et références[modifier | modifier le code]
- (en) William G. J. Halfond, An Investigation into Energy-Saving Programming Practices for Android Smartphone App Development, , p. 8
- (en) Ding Li, Automated Energy Optimization of HTTP Requests for Mobile Applications,
- (en) Ding Li, Automated Energy Optimization of HTTP Requests for Mobile Applications (lire en ligne), p. 12
- (en) Hong Xu, Reducing Electricity Demand Charge for Data Centers with Partial Execution, Hong Kong, , 11 p. (lire en ligne), p. 1
- (en) Mohammad Al-Fares, A Scalable, Commodity Data Center Network Architecture, (lire en ligne)
- (en) Junyan Jiang, Web Technologies and Applications, Springer (lire en ligne), chap. 14 (« Sharing-Aware Scheduling of Web Services »), p. 153-164