VPN อัปโหลดช้ากว่าดาวน์โหลด? ตัดสินว่าคุณชนเพดานใด

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

สามเพดานที่ดูเหมือนกันจากแถบความคืบหน้า

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

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

วัดทีละทิศทาง

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

iperf3 ส่งจากไคลเอนต์โดยค่าเริ่มต้น การรันธรรมดาจึงวัดเส้นทางอัปโหลดของคุณ -R กลับทิศทางและวัดดาวน์โหลด รันให้ห่างกันสองสามนาทีและบันทึกตัวเลขทั้งสองแทนการหาค่าเฉลี่ย:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

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

ตัดสินจากจุดที่การอัปโหลดเปลี่ยน

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

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

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

เมื่อการหยุดชะงักชนะความช้า

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

ทดสอบเส้นทางด้วยเพย์โหลดที่ไม่ควรถูกแบ่งส่วน แล้วเปรียบเทียบ MTU ของอินเทอร์เฟซอุโมงค์กับค่าที่ผ่านไปได้:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

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

อะไรควรเปลี่ยนและอะไรควรปล่อยไว้

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

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