ทำไมการดาวน์โหลดผ่าน VPN จึงเอาชนะการเชื่อมต่อโดยตรงของคุณได้

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

นั่นหมายความว่าตัวเลขที่น่าสนใจไม่ใช่ว่า VPN เร็วแค่ไหน แต่เป็นว่าคุณไม่เคยได้รับส่วนไหนของสายเลย และเพราะอะไร

เพดานที่ตามพอร์ต ไม่ใช่ตามเส้นทาง

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

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

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

วัดที่ราบ ไม่ใช่วัดยอด

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

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

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

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

การเปรียบเทียบสามแบบที่แยกสาเหตุ

ทำตามลำดับและหยุดทันทีที่รูปแบบชัดเจน เพราะแต่ละแบบตัดเรื่องเล่าคนละเรื่องออก

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

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

สิ่งที่การวัดนี้ยืนยันไม่ได้

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

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

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

เปลี่ยนสิ่งที่พบให้เป็นสิ่งที่ลงมือทำได้

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

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

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