La scène est devenue courante. Et vous y avez sûrement assisté que vous soyez à Paris, Marseille, ou n’ importe où en France et dans le monde. Un individu sur le trottoir qui scrute son smartphone. Pendant 10 secondes. Une minute. Voire plus. Il regarde peut-être une vidéo. Mais il doit surement attendre le chargement de sa page. L’individu est quelque peu frustré, ce qui se comprend, d’autant que vous avez sans doute déjà été à sa place. Sur un réseau Wi-Fi ou résidentiel à haut débit, une page se charge en 2 secondes ou moins. Sur d’autres réseaux sans fil supposés rapides, cette même page se chargera en 8 à 10 secondes. Dans les lieux particulièrement denses, en milieu urbain notamment, le chargement de la page peut prendre jusqu’à 20 secondes, si ce n’est davantage. Et le coupable n’est pas forcément la bande passante, le lien backhaul, ou encore la surcharge des antennes relais.
À vrai dire, une des principales causes de ces délais interminables est le RTT. Pas celui qui vous laisse le loisir de vous distraire sur votre smartphone à l’occasion d’une journée de repos bien méritée, mais le Round-Trip-Time tel que vécu par l’utilisateur nomade, un RTT bien plus important que celui qui pèse sur un utilisateur connecté en filaire. Pour faire simple, le RTT est le délai nécessaire pour parcourir la distance aller-retour entre un équipement mobile et la passerelle mobile, et cette distance est toujours supérieure à celle d’un utilisateur connecté via câble, fibre ou ADSL, de chez lui ou du travail. Ce délai reste important, en dépit des efforts des réseaux de diffusion de contenus (Content Delivery Networks ou CDN) pour accélérer la livraison des services et maîtriser la latence, et donc améliorer l’expérience utilisateur. Il est important de noter qu’une variation mineure du volume des données des sites Web mobiles résulte parfois en une réduction importante de la latence. Considérons cette problématique du RTT sous trois angles différents pour comprendre pourquoi la diffusion de contenus est fastidieuse en environnement mobile, et ainsi identifier des solutions pertinentes.
Au niveau du réseau, les requêtes et réponses sur protocole HTTP constituent la principale cause du rallongement du délai RTT. HTTP est en vigueur depuis plusieurs décennies en tant que principal protocole utilisé pour le trafic Web. Mais ce protocole est également source de latence. Par exemple, HTTP ne traite que d’une seule requête par connexion et le délai de réponse correspond justement au RTT. Pendant ce délai, le navigateur ne peut utiliser cette même connexion pour envoyer des requêtes supplémentaires, tant que la réponse à la requête en cours n’a pas été entièrement reçue. Sur les liens à forte latence, à l’image des liens mobiles, le taux d’utilisation est donc bas, ce qui rallonge les délais d’attente entre les deux points de terminaison de la connexion. Les navigateurs contournent cette problématique en lançant jusqu’à 6 connexions distinctes par hôte. Mais cette solution n’est pas la panacée puisque source de complexité sur l’équipement utilisateur et sur le serveur d’origine.
Sur les réseaux filaires à haut-débit qui présentent un RTT rapide (10ms - 50ms), des connexions performantes et des conditions réseau fiables, cette surcharge liée à la livraison de chaque objet est à peine perceptible. En revanche, sur les réseaux mobiles 3G et autres, le RTT entre l’équipement mobile et la passerelle est généralement de 120 à 200 ms. Dès lors, les dizaines de requêtes sur les objets d’une seule page Web génèrent de la latence et un délai d’affichage de plusieurs secondes. Naturellement, cette attente incite l’utilisateur à abandonner le service mobile demandé.
Le protocole TCP ne règle pas la problématique, d’autant que son efficacité et son débit sont lourdement impactés par la versatilité des RTT sur le lien. Les liens et les requêtes de données sont encore davantage ralentis et c’est la raison pour laquelle le chargement d’une page prend jusqu’à 15 secondes. Mais lorsque l’utilisateur recharge cette page via le bouton précédent, cette page se charge bien plus rapidement : la connexion TCP lente a été remplacée par une connexion plus rapide. Autant le dire, cette méthode fastidieuse n’est pas la plus efficace pour accélérer les délais de chargement. Conclusion : la bande passante réseau est bien moins importante sur le protocole sous-jacent à la livraison des données. Donc même lorsque le réseau n’est pas fortement utilisé et que l’équipement mobile se connecte à un lien haut-débit de 8 Mbps, Le chargement de la même page sur l’équipement mobile sera bien plus long que ce même chargement sur un lien filaire à haut débit.
L’une des approches pour répondre à la problématique HTTP est le “pipelining”, d’ailleurs intégré à HTTP/1.1. Le client peut envoyer de nouvelles requêtes sur une connexion avant d’avoir entièrement reçu une réponse de la part du serveur. Si le ‘pipelining’ améliore le taux d’utilisation du lien en éliminant les allers-retours superflus, il ne résout pour autant pas toutes les problématiques. Les navigateurs sont, en effet, nombreux à ne pas prendre en charge le pipelining, tout comme certains serveurs et proxies réseau. De plus, le pipelining sur HTTP ne gère pas le séquencement des requêtes et des réponses. Pour qu’une page se charge rapidement, les réponses doivent être envoyées selon le même séquencement que celui des requêtes. Dans ce cas, un objet lent ralentira la connexion dans sa globalité, et notamment les requêtes suivantes.
Google est à l’origine d’un nouveau protocole multiplex appelé SPDY et qui permet aux serveurs d’initier une requête (”push”), de compresser les headers et d’utiliser des techniques de réduction de latence qui font actuellement défaut à HTTP. Google a fait de SPDY une norme ouverte et open-source. SPDY est d’ailleurs intégré au navigateur Chrome et sans doute dans une prochaine version du système d’exploitation Android utilisé par des dizaines de millions d’équipements mobiles à ce jour. Mais, pour autant, l’adoption généralisée de SPDY côté client (par les fabricants et les éditeurs de logiciels mobiles) prendra du temps.
Concernant la problématique de latence induite par TCP, les opérateurs de CDN créent des algorithmes spécifiques pour optimiser la livraison des TCP compte tenu des conditions spécifiques du réseau. Cette approche rend les requêtes TCP plus intelligentes et moins à même de générer une latence qui résulte d’une requête lente en file d’attente TCP. Les CDN cherchent également de nouvelles méthodes pour accélérer le délai de traitement de chaque requête, pour ainsi minimiser l’impact de la latence.
À l’échelle du contenu, la livraison de pages Web et de données mobiles est bien plus complexe qu’en environnement filaire. Par exemple, les images qui sont transférées rapidement via des connexions filaires risquent d’être bien plus lentes sur des réseaux mobiles lorsque la connectivité réseau est restreinte. Le lien vers l’équipement pouvant être instable, la réduction de la charge totale permet de maîtriser les risques d’erreur et d’accélérer la diffusion de contenu, en raccourcissant les RTT. « Adaptive Image Compression », une technologie qui compresse en temps-réel les images sur l’équipement mobile et évalue le débit et les conditions réseau à l’échelle de l’utilisateur, constitue une réponse pertinente à cette problématique. Avec cette technologie, un CDN génère à la volée différentes versions de la même image, avec des formats et poids différents. Lorsque le type d’équipement et des performances réseau sont identifiés suite à la requête d’image, le nœud du CDN fournira des images compressées et optimisées pour une page Web ou une application sur ce dispositif mobile cible. Un autre moyen d’accélérer la fourniture des contenus mobiles consiste simplement à accélérer un site Web dans sa globalité. Cette accélération générale optimise tout le contenu statique et dynamique qui sort d’un serveur Web. Les technologies d’accélération assurent la compression des fichiers JavaScript, CSS and autres composants d’un site Web qui sont mis à disposition dans un format non-compressé par le serveur Web d’origine. L’accélération générale d’un site n’entraîne pas de latence supplémentaire et est particulièrement importante en environnement mobile.
Au niveau de la couche logique, il s’agit de prendre en compte le comportement des utilisateurs mobiles. Les interactions mobiles s’inscrivent dans le cadre d’activités personnelles de communication ou d’utilisation de réseaux sociaux et de services de géolocalisation. L’utilisateur peut ainsi consulter un service de météo ou de trafic routier, mais également le programme des cinémas à proximité. La mise en cache de ce type d’informations par un CDN est particulièrement complexe car ces informations doivent être personnalisées à chaque utilisateur et sont fragmentées selon différents lieux géographiques restreints (imaginez le nombre de cinéma dans une ville comme Paris et vous saisirez l’idée). Les utilisateurs qui demandent ces données subissent souvent un chargement lent dû à des allers retours jusqu’au serveur d’origine.
De nouvelles technologies CDN améliorent la couche logique grâce à des méthodes novatrices. En premier lieu, elles mettent en cache l’information à proximité des utilisateurs finaux. Par exemple, un service de météo mettra en cache des informations météo détaillées à l’intention d’un utilisateur du CDN et selon sa position GPS. Ces mêmes données seront de nouveau fournies à un autre utilisateur situé à proximité du premier, ce qui élimine les allers-retours avec le serveur d’origine. D’autre part, le CDN détectera rapidement le type d’équipement utilisé et fournira des ressources mises en cache et adaptées au dispositif mobile cible. En transférant la couche logique à proximité de l’utilisateur final, le CDN décide ainsi des ressources qui seront stockées en périphérie du réseau et utilisera différentes méthodes de mise en cache. Contrairement aux CDN classiques, qui assurent une mise en cache selon l’URL et le nom du fichier, les CDN de nouvelle génération discriminent selon le type d’équipement, la localisation de l’utilisateur, les conditions réseau et autres critères pertinents. Ces nouveaux critères permettent de maîtriser la latence et d’accélérer la fourniture de contenus puisque le nombre de requête sur le serveur d’origine sera bien moins important : de nombreuses requêtes seront traitées à l’aide de données déjà mises en cache en périphérie de réseau.
Alors que le grand public est toujours plus demandeur de rapidité en environnement mobile, les opérateurs et réseaux CDN continueront à utiliser de nombreuses nouvelles technologies pour accélérer le contenu vers des équipements mobiles dans le monde. La mise à disposition du contenu et de la couche logique à proximité de l’utilisateur, une mise en cache plus intelligente, l’optimisation de la fourniture via TCP selon les conditions du réseau, la compression des fichiers et l’élimination des allers-retours superflus sur HTTP sont autant de leviers pour réduire la latence et améliorer l’expérience utilisateur sur le Web mobile. L’adoption de ces technologies CDN est alimentée par la forte croissance et diversité des applications mobiles et par de nouvelles modalités d’utilisation des données (dynamique, personnel, contenus géolocalisés) adossées à des technologies d’accélération de contenus mobiles. On ne peut qu’espérer que les individus scotchés à leur smartphone attendant qu’une page se charge deviennent une exception.
http://www.infodsi.com/articles/123966/mobilite-est-condamnee-etre-lente-gad-stanislas-directeur-general-france-benelux-cotendo.html?key=
Aucun commentaire:
Enregistrer un commentaire