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

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Cet article traite des différentes techniques d'optimisation des transferts de données sur les réseaux mobiles. Le but est de permettre d'avoir un aperçu des différentes solutions possibles ainsi que de leurs avantages et leurs inconvénients.

À noter que certaines des techniques présentées ci-dessous ne sont pas limitées aux réseaux mobiles et peuvent s'appliquer à tout type de transferts.

But de l'optimisation[modifier | modifier le code]

Optimiser les transferts de données permet de réduire l'impact énergétique sur les périphériques mobiles (smartphone ou tablette tactile).

Des transferts optimisés permettent :

  • Une réduction de l'utilisation de la puce radio.
  • Une réduction de l'utilisation des ressources de calculs.

Ceci permet en outre un gain d'énergie considérable mais aussi un gain financier de par le coût élevé des communications mobiles ainsi qu'une utilisation plus fluide du périphérique mobile.

Techniques d'optimisation[modifier | modifier le code]

Technique d'optimisation Solution client Solution serveur
Développement d'un site mobile
 Non
 Oui
Compression des données
 Non
 Oui
Mise en cache
 Oui
 Non
Traitement distant
 Oui
 Oui

Développement d'un site mobile[modifier | modifier le code]

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.

JavaScript[modifier | modifier le code]

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.

CSS[modifier | modifier le code]

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.

Compression des données[modifier | modifier le code]

Minification[modifier | modifier le code]

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.

Traitement des images[modifier | modifier le 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.

Format d'encodage[modifier | modifier le code]

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.

Redimensionnement[modifier | modifier le code]

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.
Sprite CSS[modifier | modifier le code]

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.

Traitement des données audio et vidéo[modifier | modifier le code]

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.

Compression des entêtes IP[modifier | modifier le code]

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.

Mise en cache[modifier | modifier le code]

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.

Mise en cache prédictive[modifier | modifier le code]

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.

Traitement distant[modifier | modifier le code]

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].

Web Proxy[modifier | modifier le code]

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.

Serveur distant[modifier | modifier le code]

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.

Protocoles[modifier | modifier le code]

Le protocole standard pour le web est HTTP, cependant des améliorations existent pour en améliorer ses performances.

SPDY[modifier | modifier le code]

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[modifier | modifier le code]

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].

Transferts sans réseaux[modifier | modifier le code]

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.

Mesure de l'optimisation[modifier | modifier le code]

Il existe plusieurs techniques permettant de mesurer l'efficacité de l'optimisation[18] :

  • Mesurer l'utilisation du CPU.
  • Mesurer la durée de la génération du rendu.
  • Mesurer l'utilisation du réseau.
  • Mesurer l'utilisation de la batterie.
Technique de mesure Solution logicielle Solution matérielle Modification logicielle Modification matérielle
Utilisation du CPU
 Oui
 Non
 Non
 Non
Durée de la génération du rendu
 Oui
 Non
 Oui
 Non
Utilisation du réseau
 Oui
 Non
 Oui[19]
 Non
Utilisation de la batterie
 Non
 Oui
 Oui
 Oui

L'analyse de l'utilisation du réseau peut être élargie à une analyse des communications. Dans ce cas, on analysera non seulement les échanges effectués entre l'application et l'internet mais aussi[20] :

  • Les échanges effectués entre l'application et le système d'exploitation.
  • Les échanges effectués entre l'application et les autres applications.

Conclusion[modifier | modifier le code]

Si on regarde l'évolution des périphériques mobiles, terminaux mobiles et smartphones, on constate que leur puissance de calcul, leur capacité de stockage et le volume des données échangées ont été démultipliés ces dernières années. Cependant, l'autonomie des smartphones reste un point critique, la technologie des batteries évolue lentement et l'optimisation de l'autonomie est principalement réalisée par des optimisations logicielles et matérielles (CPU/GPU à fréquence variable, écran à luminosité variable, etc). À moyen terme, l'optimisation des transferts de données et des ressources des périphériques mobiles reste donc indispensable.

Références[modifier | modifier le code]

  1. Who killed my battery?: analyzing mobile browser energy consumption p10
  2. Who killed my battery?: analyzing mobile browser energy consumption p6
  3. a et b Who killed my battery?: analyzing mobile browser energy consumption p7
  4. Who killed my battery?: analyzing mobile browser energy consumption p7-8
  5. Performances observées sur Android
  6. a et b Who killed my battery?: analyzing mobile browser energy consumption p8
  7. Who killed my battery?: analyzing mobile browser energy consumption p9
  8. AmbiStream: a middleware for multimedia streaming on heterogeneous mobile devices
  9. (en) « RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed », Request for Comments no 3095, juillet 2001.
  10. Web caching on smartphones: ideal vs. reality p1
  11. How far can client-only solutions go for mobile browser speed? p5
  12. How far can client-only solutions go for mobile browser speed? p5-6
  13. Who killed my battery?: analyzing mobile browser energy consumption p8-9
  14. « SPDY white paper » (consulté le 11 décembre 2012)
  15. « Not as SPDY as You Thought » (consulté le 11 décembre 2012)
  16. « Speed and Mobility: An Approach for HTTP 2.0 to Make Mobile Apps and the Web Faster - Interoperability @ Microsoft » (consulté le 12 décembre 2012)
  17. VisualComm
  18. Who killed my battery?: analyzing mobile browser energy consumption p2-4
  19. Modifications requises uniquement si l'on désire analyser les communications entre l'application et le système ou entre deux applications
  20. ARO

Bibliographie[modifier | modifier le code]

  • (en) Narendran Thiagarajan (Stanford University, Stanford, CA, USA), Gaurav Aggarwal (Stanford University, Stanford, CA, USA), Angela Nicoara (Deutsche Telekom R&D Laboratories USA, Los Altos, CA, USA), Dan Boneh (Stanford University, Stanford, CA, USA), Jatinder Pal Singh (Stanford University, Stanford, CA, USA), « Who killed my battery?: analyzing mobile browser energy consumption », WWW '12 Proceedings of the 21st international conference on World Wide Web,
  • (en) Zhen Wang (Rice University, Houston, TX, USA), Felix Xiaozhu Lin (Rice University, Houston, TX, USA), Lin Zhong (Rice University, Houston, TX, USA), Mansoor Chishtie (Texas Instruments, Dallas, TX, USA), « How far can client-only solutions go for mobile browser speed? », WWW '12 Proceedings of the 21st international conference on World Wide Web,
  • (en) Feng Qian (University of Michigan, Ann Arbor, MI, USA), Kee Shen Quah (University of Michigan, Ann Arbor, MI, USA), Junxian Huang (University of Michigan, Ann Arbor, MI, USA), Jeffrey Erman (AT&T Labs - Research, Florham Park, NJ, USA), Alexandre Gerber (AT&T Labs - Research, Florham Park, NJ, USA), Zhuoqing Mao (University of Michigan, Ann Arbor, MI, USA), Subhabrata Sen (AT&T Labs - Research, Florham Park, NJ, USA), Oliver Spatscheck (AT&T Labs - Research, Florham Park, NJ, USA), « Web caching on smartphones: ideal vs. reality », MobiSys '12 Proceedings of the 10th international conference on Mobile systems, applications, and services,
  • (en) Feng Qian (University of Michigan, Ann Arbor, MI, USA), Zhaoguang Wang (University of Michigan, Ann Arbor, MI, USA), Alexandre Gerber (AT&T Labs Research, Florham Park, NJ, USA), Zhuoqing Mao (University of Michigan, Ann Arbor, MI, USA), Subhabrata Sen (AT&T Labs Research, Florham Park, NJ, USA), Oliver Spatscheck (AT&T Labs Research, Florham Park, NJ, USA), « Demo: mobile application resource optimizer (ARO) », MobiSys '11 Proceedings of the 9th international conference on Mobile systems, applications, and services,
  • (en) Emil Andriescu (ARLES Project-Team, INRIA Paris-Rocquencourt, Le Chesnay, France), Roberto Speicys Cardoso (Ambientic, Le Chesnay, France), Valérie Issarny (ARLES Project-Team, INRIA Paris-Rocquencourt, Le Chesnay, France), « AmbiStream: a middleware for multimedia streaming on heterogeneous mobile devices », Middleware'11 Proceedings of the 12th ACM/IFIP/USENIX international conference on Middleware,
  • (en) Zeyu Liu (North Carolina State University, Raleigh, NC, USA), Khiem Lam (North Carolina State University, Raleigh, NC, USA), Sirote Chaiwattanapong (North Carolina State University, Raleigh, NC, USA), Kyunghan Lee (North Carolina State University, Raleigh, NC, USA), Injong Rhee (North Carolina State University, Raleigh, NC, USA), « Demo: VisualComm - new robust channel of file transfer in mobile communications », MobiSys '12 Proceedings of the 10th international conference on Mobile systems, applications, and services,
  • (en) Patrick Stuedi (IBM Research, Zurich, Switzerland), Iqbal Mohomed (IBM Research, T.J. Watson), Mahesh Balakrishnan (Microsoft Research, Silicon Valley), Z. Morley Mao (University of Michigan), Venugopalan Ramasubramanian (Microsoft Research, Silicon Valley), Doug Terry (Microsoft Research, Silicon Valley), Ted Wobber (Microsoft Research, Silicon Valley), « Contrail: Enabling Decentralized Social Networks on Smartphones », Middleware'11 Proceedings of the 12th ACM/IFIP/USENIX international conference on Middleware,

Voir aussi[modifier | modifier le code]