Un VPN vide-t-il la batterie ? Ce que la radio faisait déjà
Le chiffrement ne représente qu’une petite part de la facture. Séparez le transfert, les réveils de la radio et les reconnexions, puis comparez deux exécutions qui ne diffèrent que par une chose.
Une plainte sur la consommation arrive généralement sous la forme « le VPN me mange la batterie », qui est une conclusion et non une observation. Ce que montre la mesure, c’est qu’un mélange de transferts, de réveils de la radio et de reconnexions a maintenu l’appareil occupé. Le chiffrement contribue à cette facture, et sur un téléphone moderne il est rarement le poste le plus important. Séparez les trois et la plainte devient quelque chose que vous pouvez réellement tester.
Ce qu’un tunnel ajoute au trajet d’un paquet
Chaque paquet transporté par le tunnel est authentifié, chiffré, enveloppé dans un autre en-tête puis déballé à l’autre extrémité. Ce travail coûte des cycles de processeur et, surtout, garde l’interface réseau occupée plus longtemps que la seule charge utile ne le ferait. Une sauvegarde qui dure dix minutes à travers un tunnel reste une sauvegarde de dix minutes, avec un peu plus de surcoût par paquet. Les octets et la durée viennent de l’application, pas du tunnel.
C’est pourquoi un pourcentage dans un rapport de batterie est un mauvais guide du surcoût. Le rapport attribue le travail par composant, et les règles d’attribution diffèrent selon les plateformes.
Lisez le rapport à côté d’un compteur réseau et du temps d’écran allumé. Quand la fenêtre de transfert coïncide avec celle de la décharge, la charge de travail explique le résultat et le protocole passe au second plan. Quand la décharge continue alors que les compteurs restent plats, quelque chose maintient la radio éveillée, et la section suivante indique où chercher.
Keepalives, reconnexions et l’état d’éveil de la radio
Un écran qui semble inactif ne prouve pas un réseau inactif. La synchronisation, la messagerie et les vérifications de mises à jour envoient toutes de petites quantités de trafic, et chacune peut sortir la radio d’un état de faible consommation bien plus longtemps que l’échange lui-même. Un trafic faible et fréquent coûte cher par octet parce que le coût fixe domine.
Un tunnel ajoute son propre trafic réduit sous forme de keepalives, qui servent à maintenir ouverte une correspondance NAT ou à remarquer qu’un pair a disparu. Leur rôle dépend du protocole et du réseau, et les désactiver peut réduire l’activité tout en laissant le tunnel inutilisable après une période d’inactivité. Si vous testez une autre valeur, notez l’originale et confirmez que le tunnel se rétablit encore ensuite. N’importez jamais un intervalle d’un autre protocole, car une constante qui convient à une conception est arbitraire dans une autre.
Le brassage des connexions est le second coût. Un client qui se reconnecte toutes les quelques minutes passe son temps en poignées de main au lieu de charge utile, et la radio n’a jamais l’occasion de se stabiliser.
Quand la plateforme arrête le tunnel pour économiser l’énergie
Les systèmes d’exploitation mobiles limitent l’exécution en arrière-plan, et un tunnel n’échappe pas à cette politique. Une connexion qui disparaît quand l’écran s’éteint est généralement un problème d’intégration avec la plateforme, et non un serveur qui refuse la session. Les indications de batterie du client lui-même sont le point de départ, car elles décrivent la manière prise en charge de rester connecté pendant le sommeil.
Exempter tout de la gestion de l’énergie n’est pas une solution. Cela crée une charge de travail différente et détruit la comparaison que vous cherchiez à faire.
Décidez ensuite ce qui doit se passer quand l’appareil dort, car le fonctionnement permanent, le blocage sans tunnel et l’optimisation de la batterie répondent à trois questions différentes. Un réglage qui économise de l’énergie en abandonnant discrètement la couverture requise n’a pas préservé l’objectif initial : il a masqué la défaillance. Écrivez la politique prévue avant de régler quoi que ce soit. Sans cela, vous finissez par choisir entre un tunnel qui vide la batterie et un tunnel simplement absent, et par appeler succès l’un ou l’autre résultat.
Montez une comparaison plutôt qu’une croyance
Comparez ce qui est comparable: même tâche, même réseau, même durée, signal similaire. Notez les données transférées, le nombre de reconnexions, la température de l’appareil et les conditions du signal, car chacun de ces éléments peut à lui seul déplacer le résultat. Quelques pour cent de batterie sur une heure se situent dans le bruit de la plupart des téléphones, alors qu’un motif reproductible sur plusieurs exécutions non. Guide VPN d’Android décrit le cycle de vie et le comportement permanent que suit un client bien conçu, ce qui est un contexte utile quand ce n’est pas le cas.
Déplacez les gros transferts facultatifs vers un moment où l’énergie et le réseau sont tous deux bon marché.
Agissez ensuite selon ce que la comparaison a montré. Si la charge de travail l’explique, planifiez la charge de travail. Si le brassage l’explique, corrigez la transition réseau qui le provoque. Si la plateforme l’explique, suivez la politique de batterie prise en charge pour ce client. Affaiblir les réglages cryptographiques est le seul changement qui améliore le chiffre sans toucher à la cause, et c’est pourquoi il devrait être la dernière chose à laquelle quiconque recourt.