VPN ใช้ข้อมูลมากกว่าจริงหรือ? โอเวอร์เฮด คีย์พอะไลฟ์ และตัวนับ

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

ความเชื่อผิด: VPN ทำให้ปริมาณการใช้ทวีคูณ

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

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

อะไรกันแน่ที่เพิ่มไบต์

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

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

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

ทำไมตัวนับสองตัวไม่ตรงกันเลย

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

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

adb shell dumpsys netstats | grep -A3 "iface=wlan0"
adb shell dumpsys netstats detail | grep -i vpn

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

วัดงานที่ทำซ้ำได้แทนการทดสอบความเร็ว

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

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

ดูตรงไหนเมื่อบิลกับแอปไม่ตรงกัน

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

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