Web QoS : l’acronyme manquant qui a de l’avenir

Il y a quelques semaines, lors d’une session de travail pour la réalisation d’un schéma directeur télécom, j’ai pu faire le constat que même si les acronymes sont nombreux dans notre domaine, il en manque encore parfois.

Nous faisions le constat partagé de problèmes de « qualité » au niveau des réseaux : lorsqu’au sein des flux http, les vidéos YouTube sont dans la même catégorie que les sessions d’e-learning via WebEx, fort logiquement, aux heures de pointe sur les sites contraints en bande passante, la qualité des visio avec cet outil de webconférences se dégrade rapidement au point d’être inutilisable.

Je me suis donc laissé aller à dire que le réseau nécessitait de la Web QoS, pour me faire interpeller par un DSI un peu surpris : il avait l’impression que cela faisait 3 ans que ses équipes mettaient en œuvre la QoS sur le WAN (l’organisation finissait un cycle d’équipements en ToIP) !

L’incompréhension (temporaire car c’était à moi de mieux m’expliquer) est que l’acronyme QoS (tout court) est généralement associé à la priorisation au niveau IP (aussi appelé niveau 3 dans le modèle en couche des réseaux). A ma connaissance, il n’y a pas de vocabulaire établi pour la priorisation au niveau applicatif (niveau 7), ou encore l’association de priorités entre couches (comment un trafic prioritaire au niveau http (niveau 7) est rendu prioritaire au niveau IP, puis Ethernet (niveau 2). Par exemple, l’excellente base documentaire de JANET (l’équivalent anglais de RENATER) aborde au plus la question du mapping entre niveaux 3 et 2 (on parle d’autoqos dans un environnement Cisco), met en garde sur la non transparence des firewalls / proxies mais guère plus

Il n’y a pas besoin d’avoir une boule de cristal pour voir que le centre de gravité des systèmes d’information se déplacent vers Internet et le Web. Google et consorts y travaillent ardemment au point d’avancer vers http 2.0. Dans ce nouveau standard basé sur SPDY déjà embarqué dans Chrome et Firefox, la principale innovation pour améliorer l’efficacité du protocole, et améliorer la latence perçue par l’utilisateur consiste à multiplexer au sein d’une même connexion TCP plusieurs requêtes et réponses (streams pipelining). Evidemment, cela impliquera d’être capable de prioriser les flux à l’intérieur d’une session http.

Ce qui me permet de prédire que l’acronyme Web QoS (ou un autre qui s’imposera pour désigner la même chose) a l’avenir pour lui.

Et aussi

  • 23 mai 2014 La QoS visible Régulièrement, dans notre métier, nous sommes amenés à expliquer le fonctionnement de la QoS. Avec la nécessité de recadrer toutes les imprécisions laissées par des discours marketing trop approximatifs. Maintenant il faut bien dire que le concept est abstrait, tout comme ses manifestations. On a aussi connu des exemples d'entreprises qui pensaient que leur réseau supportait la QoS, […]
  • 13 novembre 2013 Une première dans les salles de marchés Cela fait maintenant une bonne dizaine d’année que les entreprises migrent petit à petit vers la téléphonie sur IP. Les salles de marché s’y sont mis mais bien plus tard. En effet, les obligations techniques, fonctionnelles et réglementaires spécifiques au métier du trading ont ralenti la donne. On observe depuis quelques années la volonté de ces dernières de passer au tout IP pour […]
  • 20 mai 2014 Performance d’une application dans un environnement mutualisé Les précédents articles de la catégorie ont permis de visualiser un certain nombre de cas figures liés aux réseaux (WAN + LAN). Mais les serveurs eux-mêmes sont la cause de différences de performances notables. D'où la nécessité de superviser ces performances, en particulier sur les environnements mutualisés comme les clusters de machines virtuelles. Voici quelques […]