Passer au contenu

Optimiser les temps de réponse

Les solutions de priorité des flux et les serveurs de cache optimisent l’utilisation de la bande passante. Mais les architectures sont complexes à mettre en ?”uvre.

Surdimensionner ses besoins en bande passante n’est pas toujours la meilleure solution pour optimiser la qualité de service. Cette option peut en effet se révéler onéreuse sans pour autant apporter l’amélioration attendue. Plus sûre, la solution qui consiste à mieux maîtriser son trafic peut même favoriser des économies. Deux approches sont possibles : l’utilisation de serveurs de cache et la gestion de priorité des flux des applications.

Economiser la bande passante

Placés aux endroits stratégiques du réseau d’entreprise, les serveurs de cache rapprochent le contenu de l’utilisateur. En évitant le parcours du réseau aux données, ils contribuent à la libération de la bande passante tout en optimisant les temps de réponse : moins de chemin à faire équivaut à moins d’attente. En outre, les serveurs de cache stockent les copies de documents déjà calculés, là où un serveur HTTP, une base de données ou toute autre application doivent les générer, opération qui ralentit les temps de réponse. Leroy Merlin a ainsi réalisé entre 15 et 20 % d’économie de bande passante et optimisé la qualité de service en utilisant les serveurs de cache de Network Appliance. Mais comme le souligne Pierre Mathieu, son directeur délégué au web, “toutes les applications ne bénéficient pas automatiquement du cache. Nous avons dû revoir certains développements et mettre en place une charte afin qu’elles tirent désormais parti de ses fonctions”. En effet, les contenus générés à la volée bénéficient peu des fonctions du cache car ils n’existent pas en tant que tels, mais sous la forme de requêtes à exécuter. Il est donc indispensable, lors du développement, de séparer les éléments statiques d’une page des composants dynamiques. Et ce, afin de stocker les premiers dans le cache, généralement des images et autres fichiers volumineux, et ne faire transiter sur le réseau que les données dynamiques moins gourmandes en bande passante.

De Intserv à Diffserv

La première approche s’appuie sur le modèle d’architecture IntServ (Integrated Services), qui utilise le protocole RSVP (ReSerVation Protocol). Ratifié par l’IETF, il permet d’affecter des ressources à une application. L’administrateur peut par exemple attribuer 512 kbit parmi ses 2 Mo de bande passante au flux d’un PGI. Le fonctionnement d’IntServ soulève toutefois quelques problèmes. Tout d’abord, les 512 kbit restent réservés même si personne ne les utilise à un instant donné, alors que d’autres flux réclament de la bande passante. En second lieu, chaque routeur sur le parcours des paquets doit gérer ces normes, ce qui n’est pas forcément le cas à l’échelle d’Internet, sans compter les incompatibilités techniques dues aux implémentations particulières de chaque fabricant. Enfin, le maintien d’un canal de réservation de bande passante avec RSVP monopolise des ressources CPU de la part des routeurs. Résultat, le modèle IntServ est applicable à petite échelle dans un réseau local où le nombre d’utilisateurs est limité et où tous les segments de réseau sont maîtrisés et gérés de façon centralisée. Il l’est aussi sur des RPV où la route prise par les paquets est connue.La classification des paquets, n’est guère plus simple à gérer. Schématiquement, le principe de ce modèle appelé DiffServ (Differentiated Services) repose sur le marquage des paquets émis par une application en fonction des contraintes qu’elle impose au réseau : transfert en temps réel, taux de perte de paquets accepté, temps de latence autorisé, etc. Une fois la classification des applications effectuée, tous les paquets sont marqués et gérés par les routeurs en fonction du degré d’importance attribué aux flux. En d’autres termes, le premier paquet arrivé n’a plus forcément la préséance, le routeur étant alors capable de sélectionner dans la file d’attente ceux qu’il doit faire passer en priorité. Mais comme pour le modèle IntServ, ce fonctionnement n’est valable que si tous les routeurs partagent la même classification. Facile à obtenir à l’échelle d’une entreprise, cette uniformisation de la classification devient plus complexe dès que le trafic sort sur Internet, l’opérateur ne partageant pas forcément le même modèle que son client. C’est la raison pour laquelle les FAI qui disposent d’une offre de gestion de priorité des flux imposent une classification à leurs clients ou effectuent un traitement supplémentaire pour ” re-marquer ” les paquets en fonction de leur modèle de classification.DiffServ ou IntServ sont aujourd’hui implémentés dans la plupart des équipements pour réseaux. Le choix entre les deux modèles tient donc plus aux impératifs de chaque entreprise, imposés en grande partie par le FAI dès que le flux sort sur Internet.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Marie Varandat