Optimisation des transferts de données sur les réseaux mobiles

Dans le cadre des applications web, développer un site web dédié au mobile se révèle très bénéfique[1]. Une approche naïve serait d'effectuer une mise à l'échelle via un CSS, ainsi qu'éventuellement une remise en forme. Les sections ci-dessous, ainsi que le chapitre abordant la compression des données nous expliquent pourquoi cela n'est pas suffisant et quelles sont les bonnes pratiques à respecter.

La technologie JavaScript est coûteuse au niveau de l'utilisation du CPU[2]. Dans la mesure du possible, il est recommandé de ne l'utiliser qu'à juste titre[3].

Par exemple, pour attribuer un identifiant aux différents éléments d'une page web on peut :

• Laisser le client générer l'identifiant de chacun des éléments au moyen d'un code JavaScript.
• Laisser le serveur générer l'identifiant qu'il inclura directement dans le code HTML.

Dans le cadre d'un développement mobile, la seconde approche sera préférable afin de minimiser les calculs effectués par le périphérique mobile. D'un point de vue transfert de données, une autre bonne pratique est de créer un fichier JavaScript propre à chaque page web. Celui-ci devant contenir uniquement les fonctions utiles. Ce point est à prendre en compte particulièrement lors de l'utilisation de librairies génériques telles que jQuery. Remarquons également que l'utilisation de requêtes JavaScript dynamiques empêche l'utilisation d'un cache de données.

Tout comme pour le JavaScript, le traitement du CSS est couteux en CPU, il est donc conseillé de minimiser l'utilisation de règles CSS et de proposer une apparence simplifiée[3]. De plus, le support du CSS sur les navigateurs mobiles n'est pas aussi complet que sur les navigateurs de bureau.

Pour optimiser le transfert de données, il est également recommandé de créer un fichier CSS propre à chaque page web. Celui-ci devant contenir uniquement les règles utiles.

La minification est une technique qui permet de réduire la taille des fichiers sources (JavaScript/CSS). Il existe plusieurs techniques de minification :

• La suppression des caractères inutiles tels que les espaces superflus, les retours chariot, les commentaires...
• Le remplacement des noms de variables et de méthodes par des noms plus courts.

L'exécution du code aboutit à un résultat identique, les transferts sont allégés, mais le code devient difficilement lisible. La minification est également une technique d'offuscation du code.

Pour optimiser les transferts des images, on peut travailler sur deux paramètres : son format de codage et sa résolution. Il est également possible de transférer plusieurs images au travers d'une seule grâce aux Sprite CSS.

Suivant la plateforme mobile utilisée, un format d'image peut s'avérer plus performant qu'un autre[4].

	JPEG	PNG	GIF	BMP
Performance[5] - [6]	++	+	-	--
Sans perte	Non	Oui	Oui	Oui
Compression	Oui	Oui	Oui	Non
Transparence	Non	Oui	Oui	Non

Le format Bitmap (bmp) est le plus coûteux par le fait que c'est un format non compressé ; il n'a donc pas besoin d'être décodé avant d'être affiché[7]. Ce coût s'explique par l'absence de compression qui alourdit considérablement le volume des transferts de données. Le gain de ressources CPU n'est, de fait, pas suffisant pour compenser la perte de ressource radio.

Il existe deux stratégies concernant la gestion des images[6] :

• Fournir des images haute résolution et laisser le périphérique mobile effectuer une mise à l'échelle pour son affichage.
• Fournir des images basse résolution que le périphérique mobile pourra afficher directement.

La première solution consomme plus de ressources radio et CPU mais permet d'effectuer un zoom immédiat. La seconde solution permet d'optimiser l'utilisation des ressources, cependant le zoom ne peut plus être effectué de façon immédiate. L'utilisateur devra charger une version haute résolution de l'image avant de pouvoir effectuer un zoom.

Il est donc recommandé de mélanger les deux solutions :

• Si l'image a de forte chance d'être zoomée, il est préférable de fournir directement une version haute résolution à l'utilisateur.
• Si l'image a peu de chance d'être zoomée, il est préférable de lui fournir une version basse résolution de l'image et de lui fournir une version haute résolution sur demande.

Les Sprite CSS permettent de rassembler une multitude de petites images dans une grande image. L'ensemble des images est alors téléchargé en transférant un unique fichier, ce qui est moins couteux que de transférer plusieurs petits fichiers.

Ceci permet de diminuer le RTT. La partie du Sprite CSS que l'on désire afficher est déterminée à l'aide de règles CSS. Cette technique de regroupement peut également être utilisée pour d'autres ressources telles que les fichiers JavaScript.

Lorsqu'un périphérique mobile demande à accéder à un fichier audio ou vidéo, le serveur doit lui retourner un fichier adapté[8].

Pour un fichier vidéo, il sera adapté en fonction du format d'affichage du périphérique (nombre de pixels). Ceci permet de minimiser la quantité de données transférée et de diminuer l'utilisation du CPU en allégeant l'opération de décodage. Pour cela, le serveur peut :

• Transcoder la vidéo à la volée en diminuant son débit et sa résolution.
• Transcoder la vidéo en avance et fournir le fichier le plus adapté au périphérique qui demande l'accès à la vidéo.

La première solution permet de fournir un fichier parfaitement adapté au périphérique. Cependant, cela peut entrainer un usage intensif des ressources du serveur s'il reçoit de nombreuses requêtes simultanées. La seconde solution permet de fournir un fichier générique, plus ou moins adapté au périphérique. C'est cette solution qui a été adoptée par les sites de streaming tels que YouTube et DailyMotion. L'avantage est que le travail de transcodage est effectué une fois pour toutes, en contrepartie de l'espace de stockage supplémentaire est utilisé côté serveur.

Le même principe est utilisé pour les fichiers audio : le serveur fournira un fichier adapté à la qualité du système audio du périphérique.

Les entêtes des paquets IP ont une taille importante, de 40 à 60 octets selon les variantes (IPv4 ou IPv6) ; Des méthodes normalisées par l'IETF permettent de compresser fortement ces entêtes, par exemple le protocole ROHC (RFC 3095[9]) qui est adapté aux communications point-à-point via les réseaux mobiles. Ce protocole est notamment utilisé pour compresser la « voix sur IP » (VoLTE) dans les réseaux 4G.

Les caches permettent de conserver sur le périphérique des ressources obtenues et susceptibles d'être réutilisées. Ces ressources sont enregistrées lors de leur chargement afin d'éviter un nouveau chargement par la suite. Ce système est implémenté dans la majorité des navigateurs du marché. Les caches permettent également de diminuer les goulots d'étranglement des entrées/sorties en diminuant le RTT et en diminuant l'utilisation de bande passante.

Le comportement du cache peut être contrôlé au travers de protocoles tels que le Cache-control dans HTTP. De plus, les ressources mises en cache peuvent être associées à un délai d'expiration[10]. Si le délai arrive à expiration, la ressource est supprimée du cache et chargée à nouveau lors de sa prochaine utilisation.

La mise en cache prédictive consiste à mettre en cache les ressources qui seront prochainement utilisées par le client. Il existe différentes techniques de mise en cache prédictives :

• Le préchargement[11] est une technique qui détermine les ressources qui seront prochainement utilisées en se basant sur le contenu de la page courante du navigateur.
• Le chargement spéculatif[12] est une technique qui tente de déterminer les futures actions du client en se basant sur son historique de navigation et en se basant sur un graphe de connaissance. Les ressources nécessaires à la réalisation de ces actions sont ensuite préchargées.

	Cache	Préchargement	Chargement spéculatif
Prédiction	Non	Sur base du comportement de l'utilisateur	Sur base du contenu de la page courante

Notons que les techniques de préchargement et de chargement spéculatif n'offrent aucune garantie d'optimisation ! Dans le meilleur des cas, la navigation s'effectuera de manière quasi instantanée. Dans le pire des cas, des transferts supplémentaires et inutiles auront eu lieu.

Les calculs complexes sont très coûteux en temps CPU et entraîne donc une importante utilisation de la batterie. Il est possible de les déporter dans le Cloud suivant deux approches[13].

Le Web Proxy est une machine intermédiaire située entre le serveur distant et le client. Il intercepte le trafic en provenance du serveur, l'examine, le traite et le transmet au client. Les traitements appliqués peuvent être de nature diverse mais consistent généralement en l'application des autres techniques d'optimisation à la volée : compression des données, redimensionnement des images...

Afin de ne pas produire l'effet inverse de celui désiré, et donc ralentir les transferts, le Web Proxy doit disposer d'une grande bande passante. Notons que le trafic crypté (SSL) ne pourra être traité. Certains navigateurs Web tels que Opera et SkyFire, intègrent nativement un Web Proxy.

Au contraire du Web Proxy, le serveur distant n'agit pas en tant qu'intermédiaire. Le client charge l'ensemble du contenu et choisit d'envoyer au serveur distant ce qu'il veut sous-traiter.

Ce modèle implique donc une forte augmentation des transferts de données. La technologie actuelle ne permet pas de compenser le surcoût, engendré par l'utilisation de la puce radio, par le gain de CPU.

SPDY est un protocole expérimental proposé par Google proposant plusieurs solutions pour accélérer le transfert via HTTP sans remplacer celui-ci. Les fonctionnalités de bases de SPDY sont les suivantes[14] :

• Le multiplexage de flux : récupérer plusieurs ressources simultanément en utilisant une seule connexion TCP.
• La priorisation des requêtes : attribuer une priorité pour aux requêtes sérialisée en fonction de leur importance
• La compression des entêtes : comprimer les entêtes des requêtes et des réponses HTTP pour transférer de plus petits paquets.

Les fonctionnalités avancées sont :

• Le serveur Push qui permet au serveur d'envoyer de l'information au client sans que celui-ci ne l'ait demandé.
• Le serveur Hint qui permet au serveur de proposer au client des ressources à récupérer.

Certaines études tendent à démontrer que SPDY n'améliore pas le protocole HTTP de manière significative[15].

HTTP Speed+Mobility (en) est un protocole proposé par Microsoft. Tout comme le SPDY, celui-ci tend à accélérer les transferts HTTP sans remplacer ce protocole. Contrairement à SPDY, HTTP Speed+Mobility tend également à améliorer les transferts vers les équipements mobiles[16].

Dans le cas extrême où il n'est pas possible d'établir un réseau, il existe tout de même des moyens d'échanger des informations. Le Framework VisualComm[17] permet d'effectuer des transferts de données en utilisant un flux de Code QR.

Les données sont transformées sous forme d'une suite de Code QR qui est ensuite numérisée par le périphérique mobile, à l'aide de la caméra, pour régénérer les données. Un mécanisme de correction d'erreur est inclus afin de compenser les pertes lors de la numérisation.