Tömmer en VPN batteriet? Vad radion redan gjorde

Ett klagomål på batteriförbrukning kommer oftast som ”VPN:en äter mitt batteri”, vilket är en slutsats och inte en observation. Mätningen visar att en blandning av överföringar, radiovakningar och återanslutningar höll enheten upptagen. Krypteringen bidrar till den räkningen och på en modern telefon är den sällan den största posten. Dela upp de tre och klagomålet blir något du faktiskt kan testa.

Vad en tunnel tillför en pakets resa

Varje paket som tunneln bär autentiseras, krypteras, packas in i ytterligare en header och packas upp i andra änden. Det arbetet kostar processorcykler och, viktigare, håller nätverksgränssnittet upptaget längre än enbart nyttolasten skulle göra. En säkerhetskopiering som pågår i tio minuter genom en tunnel är fortfarande en tiominuterskopia med något mer overhead per paket. Byten och varaktigheten kommer från applikationen, inte från tunneln.

Därför är en procent i en batterirapport en dålig vägledning för overhead. Rapporten tillskriver arbete till komponenter, och tillskrivningsreglerna skiljer sig mellan plattformar.

Läs rapporten bredvid en nätverksräknare och tiden skärmen är på. När överföringsfönstret sammanfaller med urladdningsfönstret förklarar arbetsbelastningen resultatet och protokollet är en bisak. När urladdningen fortsätter medan räknarna står stilla håller något radion vaken, och nästa avsnitt är platsen att titta på.

Keepalives, återanslutningar och radions vakna tillstånd

En skärm som ser inaktiv ut bevisar inte ett inaktivt nätverk. Synkronisering, meddelanden och uppdateringskontroller skickar alla små mängder trafik, och var och en kan dra radion ur ett lågenergitillstånd mycket längre än själva utbytet varar. Liten frekvent trafik är dyr per byte eftersom den fasta kostnaden dominerar.

En tunnel lägger till sin egen lilla trafik som keepalives, vilka finns för att hålla en NAT-mappning öppen eller för att märka att en motpart har försvunnit. Deras syfte beror på protokollet och nätverket, och att stänga av dem kan minska aktiviteten men lämna tunneln oanvändbar efter en viloperiod. Om du testar ett annat värde, notera det ursprungliga och bekräfta att tunneln fortfarande återhämtar sig efteråt. Importera aldrig ett intervall från ett annat protokoll, eftersom en konstant som passar en design är godtycklig i en annan.

Byte av anslutningar är den andra kostnaden. En klient som återansluter varje par minuter lägger tiden på handskakningar i stället för på nyttolast, och radion får aldrig chansen att lugna sig.

När plattformen stoppar tunneln för att spara ström

Mobila operativsystem begränsar bakgrundskörning, och en tunnel är inte undantagen från den policyn. En anslutning som försvinner när skärmen släcks är oftast ett integrationsproblem med plattformen och inte en server som avvisar sessionen. Klientens egna batteririktlinjer är stället att börja, eftersom de beskriver det stödda sättet att förbli ansluten genom sömn.

Att undanta allt från strömhantering är ingen lösning. Det skapar en annan arbetsbelastning och förstör jämförelsen du försökte göra.

Bestäm sedan vad som ska hända när enheten sover, eftersom alltid-på-drift, blockering utan tunnel och batterioptimering svarar på tre olika frågor. En inställning som sparar ström genom att tyst släppa den nödvändiga täckningen har inte bevarat det ursprungliga målet; den har dolt felet. Skriv ner den avsedda policyn innan du justerar något. Utan det väljer du mellan en tunnel som tömmer och en tunnel som helt enkelt inte finns, och kallar båda utfallen för en framgång.

Sätt upp en jämförelse i stället för en övertygelse

Jämför lika med lika: samma uppgift, samma nätverk, samma varaktighet, liknande signal. Notera de överförda data, antalet återanslutningar, enhetens temperatur och signalvillkoren, eftersom vilken som helst av dem kan flytta resultatet på egen hand. Några procent batteri i timmen ligger inom bruset hos de flesta telefoner, medan ett upprepbart mönster över flera körningar inte gör det. Android VPN-vägledning beskriver livscykeln och det alltid-på-beteende som en väluppfostrad klient följer, vilket är en användbar kontext när en klient inte gör det.

Flytta valfria stora överföringar till en tidpunkt då både ström och nätverk är billiga.

Agera sedan efter vad jämförelsen visade. Om arbetsbelastningen förklarar det, schemalägg arbetsbelastningen. Om bytet förklarar det, åtgärda nätverksövergången som orsakar det. Om plattformen förklarar det, följ den stödda batteripolicyn för den klienten. Att försvaga kryptografiska inställningar är den enda ändringen som förbättrar siffran utan att röra orsaken, och därför bör det vara det sista någon griper till.