ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
ปรับปรุงประสบการณ์ของผู้ใช้ VPN
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
หน้านี้มีหลักเกณฑ์สำหรับผู้ให้บริการเครือข่ายเพื่อให้มั่นใจว่าแอปเครือข่ายส่วนตัวเสมือน (VPN) สำหรับผู้บริโภคและองค์กรจะมอบประสบการณ์การใช้งานที่ดีให้แก่ผู้ใช้ปลายทางในเครือข่าย Android มีคลาส VpnManager ไว้ให้นักพัฒนาแอปสร้างโซลูชัน VPN ซึ่งผู้บริโภคและองค์กรต่างๆ นำไปใช้เข้ารหัสการสื่อสารหรือกำหนดเส้นทางไปยังเครือข่ายต่างๆ
เราขอแนะนำให้ผู้ให้บริการเครือข่ายปฏิบัติตามหลักเกณฑ์ต่อไปนี้
- รองรับแพ็กเก็ตโปรโตคอล Encapsulating Security Payload (ESP) ของ IPv6 (ส่วนหัวถัดไป 50) ในเครือข่าย เพื่อให้การรับส่งข้อมูลนี้มีประสิทธิภาพเทียบเท่ากับการเชื่อมต่อโปรโตคอล User Datagram Protocol (UDP) หรือ Transmission Control Protocol (TCP) ควรอนุญาตให้เซสชัน ESP ขาเข้าไปยังอุปกรณ์ หรือตั้งค่าการหมดเวลาให้สูงมาก และส่งต่อที่อัตราบรรทัด
- ตั้งค่าการหมดเวลาของการเปลี่ยนที่อยู่เครือข่าย (NAT) และไฟร์วอลล์ที่มีสถานะเป็นอย่างน้อย 600 วินาทีสำหรับการเชื่อมต่อ UDP ในพอร์ต 4500 เพื่อให้มั่นใจว่าโซลูชัน VPN จะรักษาการเชื่อมต่อที่เชื่อถือได้โดยไม่สิ้นเปลืองพลังงาน
Encapsulating Security Payload (ESP) คือรูปแบบแพ็กเก็ตที่กําหนดเป็นส่วนหนึ่งของชุดโปรโตคอล Internet Protocol Security (IPSec) เพื่อเข้ารหัสและตรวจสอบสิทธิ์แพ็กเก็ตในโซลูชัน VPN ระบบปฏิบัติการ Android ใช้โปรโตคอลการรักษาความปลอดภัยมาตรฐานนี้ในโซลูชัน VPN ในตัว
ในเครือข่ายที่รองรับ IPv6 ระบบจะส่งแพ็กเก็ต ESP ในแพ็กเก็ต IPv6 โดยตรงโดยมีช่องส่วนหัวถัดไปเป็น 50 หากเครือข่ายไม่รองรับแพ็กเก็ตประเภทเหล่านี้อย่างถูกต้อง อาจทำให้โซลูชัน VPN ที่มุ่งใช้โปรโตคอลนี้โดยไม่มีการบรรจุแพ็กเก็ตเพิ่มเติมไม่สามารถเชื่อมต่อได้ เครือข่ายอาจทิ้งแพ็กเก็ตเหล่านี้เนื่องจากการกําหนดค่าไฟร์วอลล์ หรือแพ็กเก็ต ESP อาจใช้เส้นทางที่ช้าในเครือข่าย ซึ่งทำให้ประสิทธิภาพการรับส่งข้อมูลลดลงอย่างมากเมื่อเทียบกับการเชื่อมต่อ TCP หรือ UDP
คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต (IETF) ขอแนะนำให้อนุญาต IPsec ผ่านไฟร์วอลล์ที่บริการอินเทอร์เน็ตสำหรับผู้บริโภคใช้ ตัวอย่างเช่น ดูRFC 6092 ส่วนที่ 3.2.4
แพ็กเก็ต ESP สามารถอนุญาตผ่านไฟร์วอลล์ได้ทั้งสองทิศทางอย่างปลอดภัย เนื่องจากหากอุปกรณ์ได้รับแพ็กเก็ต ESP ที่ไม่ได้เป็นส่วนหนึ่งของการเชื่อมโยงการรักษาความปลอดภัยที่มีอยู่ อุปกรณ์จะทิ้งแพ็กเก็ตนั้น ด้วยเหตุนี้ อุปกรณ์จึงไม่จำเป็นต้องส่งแพ็กเก็ต Keepalive เพื่อรักษาการเชื่อมต่อ VPN ซึ่งจะช่วยประหยัดแบตเตอรี่ เราขอแนะนำให้เครือข่ายอนุญาตแพ็กเก็ต ESP ไปยังอุปกรณ์ตลอดเวลา หรือให้เซสชัน ESP หมดเวลาเฉพาะในกรณีที่ไม่มีการใช้งานเป็นเวลานาน (เช่น 30 นาที)
เราขอแนะนำให้ผู้ให้บริการเครือข่ายรองรับแพ็กเก็ตโปรโตคอล ESP (แพ็กเก็ต IPv6 ที่มีส่วนหัวถัดไป 50) ในเครือข่ายของตนและส่งต่อแพ็กเก็ตเหล่านั้นในฮาร์ดแวร์ด้วยอัตราบรรทัดข้อมูล วิธีนี้ช่วยให้โซลูชัน VPN ไม่พบปัญหาการเชื่อมต่อและมีประสิทธิภาพเทียบเท่ากับการเชื่อมต่อ UDP หรือ TCP
ตั้งค่าการหมดเวลาของ NAT และไฟร์วอลล์ที่มีสถานะเพียงพอ
โซลูชัน VPN ต้องรักษาการเชื่อมต่อกับเซิร์ฟเวอร์ VPN ไว้อย่างยาวนานเพื่อให้การเชื่อมต่อขาออกและขาเข้า (เช่น เพื่อรับข้อความ Push, ข้อความแชท และการโทรด้วยเสียงหรือวิดีโอ) ทำงานได้อย่างเสถียร แอป VPN ที่ใช้ IPsec ส่วนใหญ่ใช้ ESP ที่รวมอยู่ในแพ็กเก็ต UDP ของ IPv4 ที่มีพอร์ตปลายทาง 4500 ตามที่อธิบายไว้ใน RFC 3948
อุปกรณ์ต้องส่งแพ็กเก็ตไปยังเซิร์ฟเวอร์เป็นระยะๆ เพื่อรักษาการเชื่อมต่อนี้ไว้ โดยต้องส่งแพ็กเก็ตเหล่านี้ด้วยความถี่สูงกว่าการหมดเวลาของ NAT และไฟร์วอลล์ที่กำหนดโดยผู้ให้บริการเครือข่าย การรักษาการเชื่อมต่อไว้บ่อยๆ จะสิ้นเปลืองพลังงานฝั่งไคลเอ็นต์และส่งผลต่ออายุการใช้งานแบตเตอรี่อย่างมาก นอกจากนี้ ยังสร้างการเข้าชมสัญญาณจำนวนมากในเครือข่าย แม้ว่าอุปกรณ์จะไม่ได้ใช้งานก็ตาม
เราขอแนะนำให้ผู้ให้บริการเพิ่มการหมดเวลาของ NAT และไฟร์วอลล์แบบคงสถานะให้สูงพอเพื่อหลีกเลี่ยงผลกระทบต่อแบตเตอรี่ ระยะหมดเวลาที่แนะนำสำหรับการเข้ารหัส UDP ของ IPsec (พอร์ต 4500) คือ 600 วินาทีขึ้นไป
ในเครือข่ายมือถือ โดยทั่วไปการหมดเวลาของ UDP NAT จะต่ำอยู่เสมอ เนื่องจากความขาดแคลนที่อยู่ IPv4 ทำให้ต้องนำพอร์ตมาใช้ซ้ำกันมาก อย่างไรก็ตาม เมื่อสร้าง VPN แล้ว เครือข่ายของอุปกรณ์ไม่จำเป็นต้องรองรับการเชื่อมต่อ TCP แบบคงที่ เช่น การเชื่อมต่อที่ใช้ส่งการแจ้งเตือนขาเข้า ดังนั้นจำนวนการเชื่อมต่อระยะยาวที่เครือข่ายต้องรองรับจึงเท่าเดิมหรือต่ำกว่าเมื่อ VPN ทำงานอยู่เมื่อเทียบกับเมื่อ VPN ไม่ทำงาน
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 2025-07-27 UTC"],[],[],null,["# Improve VPN user experience\n\nThis page provides guidelines for network operators to ensure that consumer and\nenterprise virtual private network (VPN) apps provide a good end-user experience\nin their networks. Android provides the\n[`VpnManager`](https://developer.android.com/reference/android/net/VpnManager)\nclass for developers to create VPN solutions, which are used by consumers and\nenterprises to encrypt their communications or route them to different networks.\n\nWe recommend network operators follow these guidelines:\n\n- **Support IPv6 Encapsulating Security Payload (ESP) protocol (Next Header\n 50) packets on your network**, ensuring this traffic has comparable performance to user datagram protocol (UDP) or transmission control protocol (TCP) connections. ESP sessions should be allowed inbound to devices, or set to very high timeouts, and forwarded at line rate.\n- **Set network address translation (NAT) and stateful firewall timeouts** that are a minimum of 600 seconds for UDP connections on port 4500 to ensure VPN solutions can maintain reliable connectivity without incurring excessive power costs.\n\nSupport IPv6 ESP protocol (Next Header 50) packets\n--------------------------------------------------\n\nEncapsulating Security Payload (ESP) is the packet format defined as part of the\nInternet Protocol Security (IPSec) set of protocols to encrypt and authenticate\npackets in a VPN solution. The Android OS implements this standard security\nprotocol in its built-in VPN solution.\n\nOn IPv6-capable networks, ESP packets are carried directly in IPv6 packets with\na Next Header field of 50. If a network doesn't properly support these types of\npackets, it can cause a lack of connectivity for VPN solutions that aim to use\nthis protocol without further encapsulation of the packets. The network might\ndrop these packets due to firewall configuration. Or ESP packets might\nhit slow paths on the network, with severely degraded throughput performance\ncompared to TCP or UDP connections.\n\nThe Internet Engineering Task Force (IETF) recommends allowing IPsec through\nfirewalls used by consumer internet access services. For example, see\n[RFC 6092 section 3.2.4](https://www.rfc-editor.org/rfc/rfc6092.html#section-3.2.4).\nESP packets can be safely allowed through firewalls in both directions because\nif a device receives an ESP packet that isn't part of an existing security\nassociation, the device drops the packet. As a result, the device doesn't need\nto send keepalive packets to maintain VPN connectivity, which saves battery\nlife. We recommend that networks either allow ESP packets to devices at all\ntimes, or time out ESP sessions only after long periods of inactivity (for\nexample, 30 minutes).\n\nWe recommend network operators support ESP protocol packets (IPv6 packets with a\nNext Header of 50) on their networks and forward those packets in hardware at\nline rate. This ensures VPN solutions don't encounter connectivity issues and\nprovide performance comparable to UDP or TCP connections.\n\nSet sufficient NAT and stateful firewall timeouts\n-------------------------------------------------\n\nTo maintain connection reliability, a VPN solution needs to maintain a\nlong-lived connection to the VPN server that provides outbound and inbound\nconnectivity (for example, to receive incoming push notifications, chat\nmessages, and audio or video calls). Most IPsec VPN apps use ESP encapsulated in\nIPv4 UDP packets with destination port 4500, as described in\n[RFC 3948](https://www.rfc-editor.org/rfc/rfc3948.html).\n\nTo maintain this connection, the device needs to periodically send packets to\nthe server. These packets must be sent at a higher frequency than the NAT and\nfirewall timeouts imposed by the network operator. Frequent keepalives are power\nintensive on the client side, and have a major impact on battery life. They also\ngenerate substantial signaling traffic on the network, even if the device is\notherwise idle.\n\nWe recommend that operators raise NAT and stateful firewall timeouts high enough\nto avoid battery impact. The recommended timeout for IPsec UDP encapsulation\n(port 4500) is 600 seconds or greater.\n\nIn mobile networks, UDP NAT timeouts are often kept low because IPv4 address\nscarcity imposes high port reuse factors. However, when a VPN is established,\nthe device network doesn't need to support long-lived TCP connections, such as\nthose used to deliver inbound notifications. So the number of long-lived\nconnections that the network needs to support is the same or lower when a VPN is\nrunning compared to when a VPN isn't running."]]
