ทำไมพร็อกซีที่มีความหน่วงต่ำจึงยังดาวน์โหลดช้าได้

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

ตัวเลขใดตอบคำถามของคุณ?

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

วัดการถ่ายโอนจริง

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

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 30 --silent --show-error --output /dev/null --write-out 'status=%{http_code} bytes=%{size_download} average_Bps=%{speed_download} seconds=%{time_total}\n' https://example.com/test-file.bin

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

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

รักษาเงื่อนไขการเปรียบเทียบให้เท่าเทียม

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

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

เลือกตามภาระงาน

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

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