چرا یک پروکسی با تأخیر کم باز هم می‌تواند کند دانلود کند؟

پروکسی‌ای که صفحه‌ای کوچک را سریع برمی‌گرداند، ممکن است هنگام دانلود فایل کند باشد. درخواست اول بیشتر تأخیر برقراری اتصال و پاسخ را نشان می‌دهد. انتقال بزرگ‌تر به میزان داده‌ای که مسیر می‌تواند به‌طور مداوم جابه‌جا کند نیز بستگی دارد.

کدام عدد پاسخ پرسش شماست؟

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 ارائه نمی‌کند. فیلتر پروتکل یا کشور، رتبه‌بندی سرعت نیست.