VPN กินแบตเตอรี่จริงหรือ? ควรวัดอะไรก่อน

การใช้แบตเตอรี่ที่ปรากฏขึ้นหลังเปิด VPN มักเป็นการเปลี่ยนแปลงของภาระงานที่ใส่ป้ายชื่ออื่นอยู่ อุโมงค์ที่ปล่อยทิ้งไว้เฉย ๆ การสำรองข้อมูลตอนกลางคืน และไคลเอนต์ที่เชื่อมต่อใหม่ทุกไม่กี่นาที ใช้พลังงานในปริมาณที่ต่างกันมาก ไอคอนบนแถบสถานะบอกคุณไม่ได้ว่าคุณกำลังดูกรณีไหนอยู่

แยกอุโมงค์ออกจากสิ่งที่มันขนส่ง

การสำรองข้อมูลรูปภาพหรือการโทรวิดีโอผลักข้อมูลที่ VPN ต้องเข้ารหัส ตรวจสอบยืนยัน และส่งต่อภายหลัง พลังงานส่วนหนึ่งเป็นของแอปที่สร้างทราฟฟิก และมีเพียงบางส่วนที่เป็นของอุโมงค์เอง การอ่านรายงานแบตเตอรี่ควบคู่กับสถิติเครือข่ายและหน้าจอคือวิธีแยกสองสิ่งนี้ออกจากกัน เริ่มตรงนั้นก่อนจะแก้การตั้งค่าแม้แต่ข้อเดียว

รายงานของแพลตฟอร์มก็ระบุภาระงานในแบบของตัวเอง คอมโพเนนต์ที่ติดป้ายว่าเป็น VPN อาจรวมเวลาใช้งานวิทยุที่ต้องเสียไปอยู่แล้ว และแทบไม่เคยแยกต้นทุนการเข้ารหัสออกมาเดี่ยว ๆ ให้ถือว่าเปอร์เซ็นต์เป็นจุดเริ่มต้น ไม่ใช่การวัด

adb shell dumpsys batterystats --charged com.example.vpn | head -60
adb shell dumpsys netstats detail | head -40

คำสั่งแรกพิมพ์การจัดสรรพลังงานรายคอมโพเนนต์สำหรับรอบชาร์จล่าสุด คำสั่งที่สองแสดงว่าอินเทอร์เฟซใดย้ายข้อมูลไปเท่าไร และนั่นคือบริบทที่เปลี่ยนเปอร์เซ็นต์ให้เป็นคำอธิบายภาระงาน เปรียบเทียบทั้งสองก่อนสรุปอะไรเกี่ยวกับอุโมงค์

ถ้าอุปกรณ์ร้อนขึ้นระหว่างรับส่งข้อมูล ให้เปรียบเทียบไคลเอนต์หรือการตั้งค่าโปรโตคอลในสภาวะเดียวกัน การทำให้การเข้ารหัสอ่อนลงเพื่อไล่ตามตัวเลขพลังงานคือการแลกต้นทุนที่รู้จักกับต้นทุนที่ไม่รู้จัก

การเชื่อมต่อใหม่ทำให้วิทยุตื่นอยู่

หน้าจอที่ดูเหมือนไม่มีการใช้งานไม่ได้หมายถึงเครือข่ายที่ไม่มีการใช้งาน ข้อความ การซิงก์ และการตรวจสอบอัปเดตยังส่งแพ็กเก็ตอยู่ และการแลกเปลี่ยนเล็ก ๆ แต่ละครั้งสามารถปลุกวิทยุได้นานกว่าเวลาที่แพ็กเก็ตนั้นมีอายุอยู่มาก ช่องว่างระหว่างอายุของแพ็กเก็ตกับเวลาที่วิทยุเปิดอยู่คือที่ที่การใช้พลังงานตอน idle ซ่อนตัวอยู่ นี่ยังอธิบายด้วยว่าทำไมอุโมงค์ที่ idle อยู่ยังมีต้นทุนสูงกว่าอุปกรณ์ที่ idle ได้

keepalive มีอยู่ด้วยเหตุผล เพราะมันทำให้การแมป NAT เปิดค้างไว้หรือตรวจจับคู่ที่หายไป ช่วงเวลาของมันขึ้นอยู่กับ โปรโตคอลและเครือข่ายที่ใช้ การปิดมันอาจลดกิจกรรมลงได้ แต่ทำให้อุโมงค์ใช้งานไม่ได้หลังจากช่วง idle

grep -i keepalive /etc/wireguard/wg0.conf
wg show wg0 latest-handshakes

คำสั่งแรกแสดงว่ามีการตั้งค่า keepalive แบบถาวรหรือไม่ และที่ช่วงเวลาเท่าไร คำสั่งที่สองแสดงว่า handshake ครั้งล่าสุดเกิดขึ้นเมื่อไร ซึ่งแยกอุโมงค์ที่เงียบออกจากอุโมงค์ที่สร้างตัวเองใหม่ตลอดเวลา

ประวัติการเชื่อมต่อสำคัญที่สุดเมื่อการใช้พลังงานเริ่มขึ้นหลังย้ายระหว่างเครือข่าย การแก้การกู้คืนที่เกิดซ้ำมักคุ้มค่ากว่าการสลับตำแหน่งทางออก เพราะไคลเอนต์ที่เชื่อมต่อใหม่ตลอดเวลาจะใช้พลังงานไปกับการกู้คืนแทนการรับส่ง

เมื่อแพลตฟอร์มระงับอุโมงค์

ระบบปฏิบัติการจำกัดการทำงานเบื้องหลัง และอุโมงค์ที่หายไปเมื่อหน้าจอดับอาจเป็นเหยื่อของนโยบายนั้นมากกว่าความล้มเหลวของเซิร์ฟเวอร์ จากมุมของผู้ใช้ทั้งสองอย่างดูเหมือนกัน นั่นคือเหตุผลที่บันทึกของแพลตฟอร์มสำคัญ

การยกเว้นทุกแอปจากการจัดการพลังงานจะเปลี่ยนภาระงานและทำให้การเปรียบเทียบครั้งต่อ ๆ ไปไม่มีความหมาย ยกเว้นไคลเอนต์ VPN และแอปเดียวที่ต้องใช้มัน แล้ววัดใหม่เทียบกับเส้นฐานเดิม

ตัดสินแยกกันว่าควรเกิดอะไรขึ้นหลังการพักเครื่อง การทำงานตลอดเวลา กฎการบล็อกเมื่อไม่มี VPN และการปรับแต่งแบตเตอรี่ตามปกติตอบคำถามคนละข้อ และการตั้งค่าที่ประหยัดพลังงานด้วยการทิ้งความครอบคลุมที่จำเป็นอย่างเงียบ ๆ ยังไม่ได้ตอบโจทย์เดิม

เปรียบเทียบสิ่งที่เทียบกันได้ แล้วจึงตัดสินใจ

ใช้ภาระงานเดียวกัน เครือข่ายเดียวกัน และระยะเวลาเดียวกันในการวัดทั้งสองครั้ง และบันทึกปริมาณที่รับส่ง จำนวนการเชื่อมต่อใหม่ อุณหภูมิ และความแรงของสัญญาณ การเปลี่ยนแปลงของเปอร์เซ็นต์แบตเตอรี่ในช่วงสั้น ๆ มีสัญญาณรบกวน ดังนั้นรูปแบบที่เกิดซ้ำภายใต้การใช้งานที่เทียบกันได้จึงเป็นหลักฐานเดียวที่คุ้มค่าจะลงมือทำ การวัดครั้งเดียวเป็นเพียงเกร็ดเรื่องเล่า

ย้ายการรับส่งข้อมูลขนาดใหญ่ที่เป็นทางเลือกไปยังที่ชาร์จและเครือข่ายที่ไม่จำกัดปริมาณเมื่อตารางเวลาอนุญาต จากนั้นมองทั้งวันอีกครั้ง เพราะอุโมงค์ที่ idle หลายชั่วโมงมีต้นทุนน้อยกว่าอุโมงค์ที่ยุ่งอยู่ยี่สิบนาทีมาก

จดบันทึกว่าคุณเปลี่ยนอะไรและผลการวัดครั้งที่สองแสดงอะไร หากไม่มีบันทึกนั้น การเปรียบเทียบครั้งถัดไปจะเริ่มจากเส้นฐานอื่น และการถกเถียงเดิมก็เริ่มใหม่จากศูนย์