چطور اندازه می‌گیریم

دکمهٔ «شروع آزمایش» را بزنید و مرورگرتان حدود یک دقیقه چهار کار انجام می‌دهد: چند فایل دانلود می‌کند، ده دامنه را پروب می‌کند، به ده سایت معمولاً فیلترشده سر می‌زند، و مجموعه‌ای از تصاویر را بارگذاری می‌کند که ابعادشان را از قبل می‌دانیم. همه‌چیز سمت کلاینت اجرا می‌شود؛ سرور فقط نتایج را دریافت می‌کند. این صفحه هر مرحله را باز می‌کند — چه چیزی را می‌تواند به شما بگوید و چه چیزی را نمی‌تواند. روند کار با Circumvention Central متعلق به GreatFire یکی است، به‌علاوهٔ دو مورد که خودمان اضافه کرده‌ایم: دسترس‌پذیری و اوج سرعت با جریان‌های موازی.

سرعت

برای هر URL سرعت، آزمایش یک fetch با cache: 'no-store' ارسال می‌کند و سپس بدنهٔ پاسخ را به‌صورت جریانی می‌خواند — بایت‌ها را همان‌طور که می‌رسند می‌شمارد، به‌جای اینکه منتظر کل فایل بماند. در پایان فایل یا در سررسید مهلت زمانی، هر کدام زودتر برسد، متوقف می‌شود. speed = bytes read / elapsed time.

در حال حاضر دو URL وجود دارد: /api/speedtest-file خودمان (۵۰ MB بایت تصادفی، مهلت ۱۵ ثانیه) و speed.cloudflare.com/__down متعلق به Cloudflare (باز هم ۵۰ MB، مهلت ۱۰ ثانیه). چرا دو تا؟ فایل محلی مسیر شما تا سرور ما را اندازه می‌گیرد؛ فایل Cloudflare مسیر تا نزدیک‌ترین لبهٔ یک CDN جهانی را. این دو مسیر اغلب از خروجی‌های متفاوتی از کشور بیرون می‌روند. یک ابزار می‌تواند تا CDN فوق‌العاده سریع و تا یک VPS معمولی کند باشد، یا برعکس.

«سرعتی» که در جدول نشان داده می‌شود avgAll است، میانگین هر دو فایل. این معیار اصلی است و با averageSpeedAllFiles در GreatFire متناظر است. ما avgVideo را هم محاسبه می‌کنیم — میانگین فقط فایل‌های غیرمحلی — که به تخمین پخش ویدیو در ادامه خوراک می‌دهد.

اضافهٔ ما: یک انفجار موازی ۳ جریانه به مدت ۵ ثانیه روی فایل محلی، که توان عبوری ترکیبی آن به‌عنوان max گزارش می‌شود. دانلود تک‌جریانه اسیر کنترل ازدحام TCP و اتلاف بسته است، و مسیرهای پراتلاف بین‌المللی دقیقاً پر از همین چیزهاست. سه جریان نشان می‌دهد مسیر می‌تواند چقدر حمل کند؛ فاصلهٔ زیاد بین max و عدد تک‌جریانه معمولاً یعنی اتلاف شدید.

تأخیر

آزمایش تأخیر ۲ درخواست HEAD به هر یک از ۱۰ دامنه می‌فرستد، با mode: 'no-cors'، cache: 'no-store' و مهلت ۸ ثانیه. هر درخواست موفق یک نمونهٔ زمانی می‌دهد؛ میانهٔ این بیست نمونه، تأخیر آزمایش است. خطاها به فهرست failures می‌روند.

انتخاب no-cors توضیحی لازم دارد. مرورگرها اجازه نمی‌دهند یک صفحه پاسخ‌های origin‌های دیگر را بخواند، اما در حالت no-cors درخواست همچنان ارسال می‌شود — فقط یک پاسخ «مات» (opaque) برمی‌گردد. نه کد وضعیت، نه بدنه، اما می‌دانید کی رسیده است. همین کافی است؛ ما فقط زمان رفت‌وبرگشت را می‌خواهیم.

هزینه‌اش این است که نمی‌توانیم 200 را از 403 یا یک redirect تشخیص دهیم. درخواستی که سرور رد می‌کند دقیقاً شبیه درخواستی است که پاسخ داده. اتصال‌هایی که سامانهٔ فیلترینگ reset می‌کند یا می‌اندازد، به‌صورت timeout یا خطای fetch ظاهر می‌شوند — این‌ها به‌عنوان خطا ثبت و از نمونه‌های تأخیر حذف می‌شوند.

چند منبع نویز شناخته‌شده: مرورگرها DNS را کش می‌کنند، بنابراین درخواست دوم به یک دامنه ممکن است مرحلهٔ حل نام را رد کند؛ استفادهٔ مجدد از اتصال HTTP یعنی درخواست دوم ممکن است روی اتصالی که از قبل باز است سوار شود و خیلی سریع‌تر از اولی برگردد؛ بعضی مرورگرها قبل از اینکه حتی کلیک کنید pre-connect می‌کنند. همهٔ این‌ها عدد را کمی پایین می‌کشند. میانه بخشی از آن را جذب می‌کند، نه همه را.

دسترس‌پذیری

این یکی مال خودمان است؛ GreatFire آن را انجام نمی‌دهد. یک درخواست HEAD با no-cors به هر یک از YouTube، X، Instagram، Facebook، ChatGPT، Telegram Web، Discord، GitHub، Wikipedia و Google، با مهلت ۸ ثانیه، و ثبت اینکه آیا پاسخی برگشت و چقدر طول کشید.

به یک پرسش ساده جواب می‌دهد: با این ابزار، این سایت‌ها همین حالا باز می‌شوند؟ میانهٔ تأخیر کیفیت کلی مسیر را توصیف می‌کند؛ دسترس‌پذیری می‌گوید این مسیر — یا این IP خروجی — به کدام سایت‌های مشخص دسترسی ندارد. بعضی محدوده‌های هاستینگ را Google یا OpenAI یکسره مسدود کرده‌اند و هیچ مقدار سرعتی به آن کمک نمی‌کند.

باز هم به‌خاطر no-cors فقط می‌توانیم بگوییم «پاسخ داد»، نه «پاسخ درستی داد». سایتی که یک صفحهٔ مسدودسازی 403 برمی‌گرداند، در دسترس حساب می‌شود. این محدودیت مرورگر است، نه تنبلی ما.

پایداری

آزمایش پایداری از فهرستی از تصاویر با ابعاد مشخص استفاده می‌کند، [url, width, height]. هر کدام با new Image() و یک timestamp برای دور زدن کش و مهلت ۱۰ ثانیه بارگذاری می‌شود؛ پس از بارگذاری، naturalWidth و naturalHeight باید دقیقاً برابر مقادیر مورد انتظار باشند. stability = passed / total × 100%.

چرا بررسی اندازه مشکلات را می‌گیرد؟ چون بیشتر انواع مداخله اندازه را تغییر می‌دهند. پروکسی شفاف یک ISP تصویر را با گرافیک «این صفحه قابل نمایش نیست» عوض می‌کند — ابعاد متفاوت. یک middlebox رباینده محتوایی به پاسخ تزریق می‌کند — تصویر decode نمی‌شود یا با اندازهٔ دیگری درمی‌آید. مسمومیت DNS دامنه را به یک IP جعلی می‌برد که یا پاسخ نمی‌دهد یا چیز کاملاً دیگری برمی‌گرداند. برعکس، اگر تصویر سالم و با اندازهٔ مورد انتظار برسد، آن مسیر به احتمال زیاد تمیز است.

چیزی که اندازه نمی‌گیرد کارایی است. تصویری که نه ثانیه طول می‌کشد تا برسد اما ابعاد درستی دارد همچنان قبول می‌شود. پایداری و سرعت دو محور جدا هستند؛ پایداری ۱۰۰٪ به معنای سریع بودن نیست.

تخمین پخش ویدیو

اینجا اندازه‌گیری اضافه‌ای در کار نیست — avgVideo به مگابیت بر ثانیه تبدیل می‌شود (بایت × 8 ÷ 10⁶) و در یک جدول آستانه جستجو می‌شود:

سرعت	کیفیت تخمینی
< 0.7 Mbps	240p
< 1.5 Mbps	360p
< 2.5 Mbps	480p
< 5 Mbps	720p
< 8 Mbps	1080p
< 20 Mbps	1440p
≥ 20 Mbps	2160p

آستانه‌ها از پیاده‌سازی GreatFire می‌آیند و ما آن‌ها را بدون تغییر نگه داشته‌ایم تا دو سایت با هم بخوانند. راهنمای تقریبی است: نرخ بیت واقعی YouTube با محتوا و codec تغییر می‌کند و پخش‌کننده پیوسته خودش را تطبیق می‌دهد. اندازه‌گیری ۳ Mbps به مدت ده ثانیه تضمین نمی‌کند که ۳ Mbps برای یک ویدیوی چهل دقیقه‌ای پایدار بماند. آن را به‌صورت «تقریباً در کدام رده می‌افتید» بخوانید.

سوگیری‌هایی که آزمایش مرورگری نمی‌تواند از آن‌ها فرار کند

در نهایت این یک آزمایش در حال اجرا داخل مرورگر است، نه iperf. چند نکته را در ذهن داشته باشید:

یک جریان دانلود تکی محدود به کنترل ازدحام TCP (یا QUIC) است و در مسیری با تأخیر بالا و اتلاف زیاد، لوله را پر نمی‌کند — به همین دلیل اوج موازی را اضافه کردیم. خود مرورگر سربار دارد، و روی گوشی این سربار محسوس است. Wi‑Fi شما، یک فضای ابری که در پس‌زمینه همگام‌سازی می‌کند، کس دیگری که روی همان روتر ویدیو می‌بیند — همهٔ این‌ها در عدد هست. یک گرهٔ خروجی می‌تواند ساعت ۹ شب سه برابر کندتر از ساعت ۳ بامداد باشد.

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

اگر اعداد دقیق می‌خواهید، ابزارهای خط فرمان (iperf3 یا speedtest-cli مستقیم به یک سرور) دقیق‌ترند. اما آن‌ها تجربهٔ یک آدم معمولی را که با مرورگر از داخل تونل استفاده می‌کند ثبت نمی‌کنند، و این سایت دربارهٔ همان تجربه است.

پرسش‌های متداول

چرا سایت‌های آزمایش سرعت دیگر عدد بالاتری به من نشان می‌دهند؟ بیشترشان نزدیک‌ترین سرور را خودکار انتخاب می‌کنند و جریان‌های موازی زیادی باز می‌کنند. معیار اصلی ما یک جریان تکی به یک سرور ثابت است، پس طبیعتاً پایین‌تر است — اما بین ابزارها قابل مقایسه است. عدد max به آنچه سایت‌های دیگر گزارش می‌دهند نزدیک‌تر خواهد بود.

چرا بعضی دامنه‌ها همیشه در آزمایش تأخیر شکست می‌خورند؟ بعضی سرورها HEAD را کند پاسخ می‌دهند؛ بعضی اتصال‌ها را شبکه‌ای که در آن هستید reset می‌کند. خطاها در میانه حساب نمی‌شوند اما در نمای جزئیات ظاهر می‌شوند و خودشان به‌تنهایی اطلاعات مفیدی دارند.

از یک آزمایش چه چیزی ذخیره می‌شود؟ منطقه‌ای که انتخاب کرده‌اید، نام و نسخهٔ ابزاری که وارد کرده‌اید، نتایج و جزئیات چهار آزمایش، و خانوادهٔ مرورگر و سیستم‌عامل شما. وقتی ابزاری در حال استفاده است کشور IP خروجی را ثبت می‌کنیم — هرگز خود IP را.

می‌توانم بدون ابزار آزمایش کنم؟ بله — «هیچ» را انتخاب کنید. آن نتایج وارد رتبه‌بندی نمی‌شوند، اما به میانهٔ «اتصال خام» هر منطقه خوراک می‌دهند که به‌عنوان مبنا استفاده می‌شود.