چگونه تأخیر شبکه را اندازه‌گیری کنیم: راهنمای عملی برای توسعه‌دهندگان

می‌خواهید تأخیر شبکه را اندازه بگیرید؟ می‌توانید با ابزارهای ساده و ساخته‌شده در خط فرمان مانند ping و traceroute شروع کنید تا یک تصویر سریع از زمان رفت‌وبرگشت (RTT) به دست آورید. یا می‌توانید ابزارهای توسعه‌دهنده مرورگرتان را باز کنید تا ببینید تأخیرها چگونه بر تجربه واقعی کاربران تأثیر می‌گذارند.

این روش‌ها یک نمای سریع و مفید از مدت زمانی که یک بسته داده طی می‌کند تا از یک منبع به مقصد برسد و سفر بازگشت را انجام دهد، به شما ارائه می‌دهند.

چرا اندازه‌گیری تأخیر ضروری است

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

عواقب واقعی آن را در نظر بگیرید:

• پاسخگویی API: یک فراخوان API کند می‌تواند اثر دومینو ایجاد کند و همه چیز را از بارگذاری پروفایل کاربر تا پردازش یک پرداخت حیاتی، به تأخیر بیندازد.
• جریان‌های داده بلادرنگ: برای بازی‌های آنلاین، ویدیوی زنده یا معاملات مالی، تأخیر کم و پایدار پایه مطلق است. بدون آن، این برنامه‌ها به سادگی کار نمی‌کنند.
• حفظ کاربر: خط مستقیمی بین وب‌سایت‌ها و اپلیکیشن‌های با بارگذاری کند و نرخ پرش بالا و سبد‌های خرید رها شده وجود دارد. این مسائل مستقیماً بر سودآوری تأثیر می‌گذارند.

تشخیص مفاهیم کلیدی تأخیر

برای اندازه‌گیری دقیق تأخیر شبکه، باید بدانید چه چیزی را مشاهده می‌کنید. دو مفهوم بنیادی زمان رفت‌وبرگشت (RTT) و تأخیر یک‌طرفه.

RTT مدت زمان کلی است که یک سیگنال طی می‌کند تا از نقطه A به نقطه B و دوباره بازگردد. این رایج‌ترین معیاری است که خواهید دید، زیرا اندازه‌گیری آن ساده است—فقط به دسترسی به یک انتهای اتصال نیاز دارید.

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

اهمیت همه اینها زمانی کاملاً واضح می‌شود که در حال انجام آزمایش عملکرد بار جدی هستید، جایی که نظریه با واقعیت روبرو می‌شود و تنگناها آشکار می‌شوند.

برای ارائه اعداد و ارقام، کارشناسان نظارت بر شبکه معمولاً تأخیر را اینگونه طبقه‌بندی می‌کنند:

• تأخیر کم: زیر 50 میلی‌ثانیه
• تأخیر متوسط: 50-150 میلی‌ثانیه
• تأخیر بالا: بیش از 150 میلی‌ثانیه

بر اساس تجربه من، یک آزمایش سریع به سرور نزدیک ممکن است تأخیری کاملاً قابل قبول 20-40 میلی‌ثانیه را نشان دهد. اما این عدد می‌تواند به راحتی برای ترافیکی که باید از اقیانوس عبور کند، به بیش از 200 میلی‌ثانیه افزایش یابد، که می‌تواند نقش تعیین‌کننده‌ای در عملکرد برنامه شما ایفا کند.

برای درک اصطلاحاتی که با آن‌ها مواجه خواهید شد، در اینجا یک مرجع سریع ارائه شده است.

مفهوم کلیدی تأخیر در یک نگاه

می‌باشد.

مفهوم	چه چیزی را اندازه می‌گیرد	چرا مهم است
تأخیر (پینگ)	زمانی که یک بسته داده از یک منبع به مقصد و بازمی‌گردد. با میلی‌ثانیه (ms) اندازه‌گیری می‌شود.	این اندازه خام تأخیر است. تأخیر کم برای برنامه‌های بلادرنگ مانند بازی، VoIP و کنفرانس ویدیویی حیاتی است.
زمان رفت‌وبرگشت (RTT)	اساساً مانند تأخیر است، این مدت کل زمانی است که یک سیگنال ارسال می‌شود به اضافه زمانی که تأییدیه دریافت می‌شود.	RTT رایج‌ترین و عملی‌ترین راه برای اندازه‌گیری تأخیر از یک نقطه است و معیار اصلی ابزارهایی مانند ping.
تأخیر یک‌طرفه	زمانی که یک بسته در یک جهت از منبع به مقصد سفر می‌کند.	دید جزئی‌تری ارائه می‌دهد، به ویژه برای شبکه‌های نامتقارن که مسیرهای آپلود و دانلود دارای تأخیرهای متفاوتی هستند.
نوسان تأخیر (جیتر)	تغییرات تأخیر در طول زمان. عدم ثبات در زمان رسیدن بسته‌ها را اندازه می‌گیرد.	نوسان تأخیر بالا به اندازه تأخیر بالا برای رسانه‌های جریانی و تماس‌های آنلاین مضر است و باعث لکنت، بافرینگ و اشکال می‌شود.
پهنای باند	حداکثر مقدار داده‌ای که می‌تواند در یک زمان معین از طریق یک اتصال شبکه منتقل شود. با Mbps یا Gbps اندازه‌گیری می‌شود.	اغلب با سرعت اشتباه گرفته می‌شود، پهنای باند درباره ظرفیت است. می‌توانید پهنای باند بالایی داشته باشید اما همچنان از تأخیر بالا رنج ببرید.

این مفاهیم بلوک‌های سازنده برای درک هرگونه مشکل عملکرد شبکه هستند.

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

آشنایی عملی با ابزارهای خط فرمان برای اندازه‌گیری تأخیر

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

ابزار کلاسیک و پرکاربرد ping است. این ابزار به زیبایی ساده است: یک بسته داده کوچک (یک درخواست ICMP echo) به یک سرور ارسال می‌کند و منتظر بازگشت آن می‌ماند. همین رفت و برگشت ساده، پایه محاسبه زمان رفت و برگشت (RTT) است و فوراً وضعیت سلامت یک اتصال را به شما می‌دهد.

اولین بررسی تأخیر خود با Ping

اجرای یک تست ping به هیچ وجه پیچیده نیست. ترمینال یا پرامپت دستور خود را باز کنید، ping را تایپ کنید و نام دامنه‌ای را که می‌خواهید تست کنید پشت آن بنویسید.

به طور پیش‌فرض، ping در macOS و Linux به طور نامحدود ادامه می‌یابد، در حالی که ویندوز فقط چهار بسته ارسال کرده و متوقف می‌شود. برای هر تحلیل جدی، می‌خواهید این را کنترل کنید. ارسال ده یا بیست بسته، تصویر قابل اطمینان‌تری از پایداری اتصال به شما می‌دهد تا فقط دو بسته.

پس از اتمام، یک خلاصه منظم با اعداد کلیدی دریافت خواهید کرد:

• تعداد بسته‌های ارسالی/دریافتی: این به شما می‌گوید که آیا در طول مسیر داده‌ای از دست رفته است یا خیر. حتی مقدار کمی از دست دادن بسته، نشانه بزرگی از مشکل شبکه است.
• Round-trip min/avg/max/mdev: اینها آماره‌های اصلی تاخیر شما هستند. بهترین حالت زمان (min)، میانگین (avg)، و بدترین حالت (max) را می‌بینید. mdev (انحراف میانگین) معیار Jitter شماست—میزان تغییرات تاخیر از یک پاکت به پاکت بعدی.

به فاصله بین حداقل و حداکثر RTT توجه ویژه‌ای کنید. اگر این فاصله زیاد باشد، اتصال شما ناپایدار است، حتی اگر میانگین به نظر خوب بیاید. این jitter می‌تواند برای برنامه‌های بلادرنگ مانند تماس‌های ویدیویی یا بازی‌ها بسیار مزاحم‌تر از اتصالی باشد که به طور مداوم کمی کند است.

یک اشتباه رایج فقط نگاه اجمالی به میانگین RTT است. میانگین 50ms ممکن است خوب به نظر برسد، اما اگر حداقل شما 20ms و حداکثر آن 250ms باشد، تجربه کاربر پرشی و غیرقابل اعتماد خواهد بود. همیشه به محدوده کامل نگاه کنید تا jitter را درک کنید.

پیگیری مسیر با Traceroute و MTR

پس، وقتی ping تاخیر بالا یا از دست رفتن پاکت را نشان می‌دهد، چه باید کرد؟ کار بعدی شما این است که بفهمید مشکل کجا است. به همین دلیل است که traceroute (یا tracert در ویندوز) وجود دارد. این ابزار کل مسیری را که پاکت‌های شما طی می‌کنند نقشه‌برداری می‌کند و هر "پرش"—هر روتر—بین ماشین شما و مقصد نهایی را نشان می‌دهد.

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

اما traceroute یک تصویر لحظه‌ای یکباره است. برای نگاه پویا و مداوم‌تر، اکثر متخصصان شبکه‌ای که می‌شناسم به MTR (My Traceroute) قسم می‌خورند. MTR مانند ابزاری تقویت‌شده است که ping و traceroute را ترکیب می‌کند. این ابزار به طور مداوم پاکت‌ها را به هر پرش در مسیر ارسال می‌کند و نمایی زنده و به‌روز از تاخیر و از دست رفتن پاکت در هر نقطه به شما می‌دهد. این باعث می‌شود در شناسایی مشکلات گاه‌وبیگاه که یک traceroute تکی احتمالاً از دست می‌دهد، بسیار مؤثر باشد.

چرا انتخاب ابزار مهم است

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

جالب است که اعداد می‌توانند تا این حد با هم تفاوت داشته باشند. در آزمایش دقیقی که توسط Google Cloud انجام شد، یک تست استاندارد ping میانگین RTT را ۱۴۶ میکروثانیه گزارش کرد. اما وقتی از ابزار دیگری استفاده شد که تراکنش‌ها را بدون مکث پشت سر هم ارسال می‌کرد، RTT تنها به ۶۶.۵۹ میکروثانیه کاهش یافت—بیش از دو برابر سریع‌تر!

این نمونه‌ای عالی است از اینکه چرا ping گاهی می‌تواند تأخیر را بیش‌ از حد برآورد کند. این نشان می‌دهد که درک نحوه عملکرد یک ابزار برای به دست آوردن اندازه‌گیری‌هایی قابل اعتماد بسیار حیاتی است.

یافتن سرعت بالای اتصال خود با iperf

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

است.

در حالی که ping تأخیر را اندازه می‌گیرد، iperf کاملاً درباره نرخ داده‌ای است. این کار با برقراری یک اتصال کلاینت-سرور انجام می‌دهد و سپس برای مدت زمانی مشخص تا جایی که می‌تواند داده بین آن‌ها ارسال می‌کند.

برای استفاده از iperf، به دو ماشین نیاز خواهید داشت:

1. روی یک ماشین، iperf را در حالت سرور اجرا می‌کنید. این فقط در آنجا می‌نشیند و منتظر یک اتصال می‌ماند.
2. روی ماشین دیگر، iperf را در حالت کلاینت اجرا می‌کنید و آن را به آدرس سرور اشاره می‌دهید.

کلاینت متصل می‌شود و تست شروع می‌شود. خروجی کل داده‌های منتقل شده و مهم‌تر از همه، نرخ بیت (پهنای باند شما) را در مگابیت یا گیگابیت بر ثانیه به شما می‌گوید. این روشی عالی برای تست استرس پیوند شبکه و فهمیدن توانایی واقعی آن است.

اندازه‌گیری تأخیر از دید کاربر

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

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

کاوش در ابزارهای توسعه‌دهنده مرورگر

هر مرورگر اصلی—Chrome, Firefox, Edge, Safari—دارای مجموعه‌ای از ابزارهای توسعه‌دهنده است. تب "Network" در این ابزارها مرکز فرماندهی شما برای درک نحوه بارگذاری سایتتان است. همه چیز را در یک نمودار آبشاری نشان می‌دهد که تفکیک بصری هر درخواستی که مرورگر برای رندر کردن یک صفحه انجام می‌دهد، است.

این نمای آبشاری بی‌نهایت ارزشمند است. می‌توانید به طور دقیق ببینید هر فایل چند زمان برای دانلود صرف کرده، از سند HTML اولیه و شیوه‌نامه‌های CSS گرفته تا تصاویر و فراخوانی‌های API. مهم‌تر از آن، چرخه حیات هر درخواست را به مراحل مجزا تقسیم می‌کند:

• جستجوی DNS: زمانی که برای تبدیل نام دامنه به آدرس IP صرف می‌شود.
• اتصال اولیه: زمان صرف شده برای برقراری اتصال TCP با سرور.
• دست‌انداز SSL/TLS: هزینه اضافی برای راه‌اندازی یک اتصال امن.
• زمان تا بایت اول (TTFB): این یکی خیلی مهم است. اندازه می‌گیرد که مرورگر چقدر منتظر مانده است قبل از دریافت خودِ بایت اول داده از سرور.
• دانلود محتوا: زمان واقعی صرف شده برای دانلود خود منبع.

برای مثال، یک TTFB بالا، نشانه کلاسیک یک سمت سرور کند یا مشکل در پردازش سمت سرور است—چیزی که یک ping تست ساده هرگز کشف نمی‌کند. با تحلیل این آبشار، می‌توانید به سرعت شناسایی کنید کدام منابع در حال مسدود کردن رندر هستند یا فقط بیش از حد طولانی برای بارگذاری زمان می‌برند.

یک نکته کلیدی از تجربه من این است که فقط به زمان کل بارگذاری نگاه نکنید، بلکه به دنبال طولانی‌ترین میله‌ها در آبشار باشید. یک تصویر بهینه‌نشده تنها یا یک API کند شخص ثالث می‌تواند کل صفحه را گروگان بگیرد و حتی اگر بقیه سایت سریع‌تر از رعد و برق باشد، تجربه کاربری ضعیفی ایجاد کند.

اندازه‌گیری برنامه‌نویسی شده با Timing APIs

برای اندازه‌گیری‌های خودکارتر و دقیق‌تر، می‌توانید از JavaScript API‌های داخلی مرورگر استفاده کنید. Navigation Timing API و Resource Timing API دسترسی برنامه‌نویسی شده به همان داده‌های عملکرد دقیقی که در ابزارهای توسعه‌دهنده می‌بینید را فراهم می‌کنند. این برای جمع‌آوری داده‌های نظارت بر کاربر واقعی (RUM) و درک عملکرد سایتتان برای بازدیدکنندگان واقعی در سراسر جهان عالی است.

می‌توانید این معیارها را تنها با چند خط کد JavaScript، درست در کنسول مرورگر دریافت کنید. به عنوان مثال، برای دریافت زمان‌بندی‌های اصلی عملکرد برای بارگذاری صفحه اصلی، می‌توانید از performance.getEntriesByType('navigation') استفاده کنید. این یک شیء با ارزش پر از مهرهای زمانی باارزش برمی‌گرداند.

از آن داده‌ها، می‌توانید معیارهای حیاتی را محاسبه کنید:

• زمان جستجوی DNS: domainLookupEnd - domainLookupStart
• زمان دست‌انداز TCP: connectEnd - connectStart
• زمان تا بایت اول (TTFB): responseStart - requestStart
• زمان کل بارگذاری صفحه: loadEventEnd - startTime

این رویکرد به شما امکان می‌دهد داشبوردهای سفارشی بسازید یا داده‌های عملکرد را به ابزارهای تحلیل خود بفرستید، و نبضی مداوم از عملکرد واقعی برنامه خود داشته باشید. در توسعه وب، بهینه‌سازی تصاویر راهی رایج برای بهبود این معیارهاست؛ برای علاقه‌مندان، راهنمای مفیدی در مورد انتخاب بهترین فرمت تصویر برای وب‌سایت شما.

داریم.

ساده‌سازی بررسی‌ها با ابزارهای یکپارچه

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

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

چگونه یک تست تأخیر طراحی کنیم که واقعاً چیزی به شما بگوید

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

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

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

همانطور که می‌بینید، از جستجوی اولیه DNS تا رندر نهایی، چندین مرحله به زمان انتظار کل کمک می‌کنند.

انتخاب نقاط پایانی تست خود

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

فهرست اندپوینت‌های شما باید چند حوزه کلیدی را پوشش دهد:

• بزرگ‌ترین مراکز کاربری شما: اکثر مشتریان شما کجا زندگی می‌کنند؟ از آنجا تست کنید.
• مسیرهای فرا قاره‌ای: ببینید وقتی داده‌ها باید از اقیانوس عبور کنند چه اتفاقی می‌افتد. بین اروپا و آمریکای شمالی، یا آسیا و ایالات متحده تست کنید تا عملکرد مسافت‌های طولانی را درک کنید.
• منطقه‌های ابری شما: اگر از AWS، Azure یا GCP استفاده می‌کنید، اتصال به و بین مناطق مرکز داده خاصی که به آن‌ها وابسته هستید را تست کنید.

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

یافتن ریتم تست مناسب

شرایط شبکه مدام در حال تغییر است. آن‌ها در طول روز، هفته و حتی دقیقه تغییر می‌کنند. یک تست که ساعت ۳ صبح سه‌شنبه اجرا شده ممکن است عالی به نظر برسد، اما آن نتیجه بی‌فایده است اگر پیک ترافیک شما ساعت ۲ بعدازظهر جمعه باشد، زمانی که همه آنلاین هستند.

برای داشتن یک مبنا واقعی، باید در طول زمان به طور مداوم تست کنید. آن را متنوع کنید:

• تست‌ها را در ساعات اوج کاری اجرا کنید.
• برخی را برای پنجره‌های تعمیرات شبانه برنامه‌ریزی کنید.
• آخر هفته‌ها را فراموش نکنید، زمانی که الگوهای ترافیک می‌توانند کاملاً متفاوت باشند.

با نمونه‌برداری مکرر از داده‌ها، می‌توانید افزایش‌ها و کاهش‌های تصادفی را هموار کنید. این راهی است که مشکلات تکرارشونده را کشف کنید، مانند شلوغ شدن شبکه هر عصر روزهای کاری درست پس از ناهار.

جاگر را فراموش نکنید

تأخیر متوسط یک نقطه شروع خوب است، اما اغلب مشکل خطرناک‌تری را پنهان می‌کند: جاگر. جاگر به سادگی نوسان در تأخیر شما در طول زمان است. به آن فکر کنید - یک اتصال پایدار با تأخیر قابل پیش‌بینی 80ms اغلب برای برنامه‌های بلادرنگ بسیار بهتر است از یک اتصال با متوسط 50ms که به شدت بین 10ms و 200ms.

جاگر قاتل خاموش تجربه کاربر برای هر چیز بلادرنگ، مانند تماس‌های VoIP، ویدئو کنفرانس‌ها یا بازی‌های آنلاین است. جاگر بالا باعث صدای بریده‌بریده، ویدئوی یخ‌زده و افزایش‌های ناامیدکننده تأخیر می‌شود که باعث می‌شود یک برنامه کاملاً خراب به نظر برسد، حتی اگر تأخیر متوسط روی کاغذ خوب به نظر برسد.

درک نوسان (jitter) به معنای فراتر رفتن از حد میانگین است. این پدیده قهرمان نادیده‌ی زمان است، زیرا نشان می‌دهد چرا تنها اتکا به میانگین‌ها می‌تواند بسیار گمراه‌کننده باشد. به عنوان مثال، داده‌های Pandora FMS نشان می‌دهند که نوسان بیش از 30 میلی‌ثانیه می‌تواند نرخ از دست رفتن بسته‌ها (packet loss) در بازی‌ها را تا 15% افزایش دهد—به حدی که بازی را غیرقابل بازی می‌کند. اندازه‌گیری انحراف معیار نتایج تأخیر اولین قدم برای دادن یک عدد به این بی‌ثباتی است.

چک‌لیست طراحی تست تأخیر

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

آیتم چک‌لیست	چرا مهم است	نکته عملی
تعیین اهداف روشن	شما نمی‌توانید چیزی را که تعریف نکرده‌اید، اندازه بگیرید. آیا در حال عیب‌یابی یک مشکل خاص هستید یا یک خط پایه (baseline) ایجاد می‌کنید؟	هدف خود را قبل از شروع یادداشت کنید. "تشخیص تأخیر برای کاربران در جنوب شرق آسیا" هدف بهتری از "بررسی تأخیر" است.
انتخاب نقاط پایانی متنوع	یک مسیر واحد نمایانگر تجربه جهانی کاربران شما نیست.	۳ تا ۵ مکان را انتخاب کنید: یکی محلی، یکی در قاره‌ای دیگر، و چند مورد در بازارهای کلیدی کاربرانتان.
ایجاد یک ریتم منظم	تست‌های مقطعی الگوهای مبتنی بر زمان مانند ازدحام ساعات اوج مصرف را از دست می‌دهند.	تست‌ها را طوری برنامه‌ریزی کنید که هر ساعت به صورت خودکار در طول یک هفته اجرا شوند تا یک چرخه کامل رفتار شبکه ثبت شود.
اندازه‌گیری نوسان (Jitter)	میانگین‌ها عملکرد نامنظمی را که برنامه‌های کاربردی بلادرنگ (real-time) را خراب می‌کند، پنهان می‌کنند.	فقط به میانگین RTT نگاه نکنید. انحراف معیار را محاسبه کنید یا از ابزاری مانند mtr استفاده کنید که حداقل/حداکثر/میانگین تأخیر را نشان می‌دهد.
استفاده از ابزارهای مناسب	ping برای یک بررسی سریع خوب است، اما ابزارهایی مانند mtr یا iperf بینش‌های عمیق‌تری ارائه می‌دهند.	برای عملکرد وب، از ابزارهای توسعه‌دهنده مرورگر استفاده کنید. برای مسیرهای خام شبکه، mtr یک انتخاب عالی است.
مستندسازی همه چیز	شش ماه دیگر "چرای" آزمون خود را فراموش خواهید کرد.	یک گزارش ساده نگه دارید: تاریخ، زمان، نقاط پایانی، ابزار مورد استفاده، و یک یادداشت مختصر درباره مشاهداتتان.

با رعایت نظم و روش، از صرف اندازه‌گیری ساده تاخیر به درک واقعی آن می‌رسید. این رویکرد دقیق است که یک عدد تصادفی را از یک شاخص عملکرد قابل اعتماد جدا می‌کند.

درک معنای اعداد (و مواردی که باید از آنها اجتناب کنید)

بسیار خب، آزمون‌های خود را اجرا کردید و انبوهی از داده دارید. اینجاست که کار واقعی آغاز می‌شود—ترجمه آن اعداد خام به چیزی که واقعاً معنادار باشد. داده‌ها داستانی درباره سلامت شبکه شما را روایت می‌کنند؛ فقط باید یاد بگیرید چگونه آن را بخوانید.

به عنوان مثال، یک افزایش ناگهانی در زمان رفت و برگشت (RTT) در traceroute یک سرنخ کلاسیک است. اگر تاخیر در پرش شماره سه جهش کند و تا انتها بالا بماند، احتمالاً مشکل خود را پیدا کرده‌اید: آن روتر سوم یا لینک درست پس از آن است. اما محتاط باشید. اگر فقط همان یک پرش تاخیر بالایی نشان دهد و مقصد نهایی همچنان سریع باشد، ممکن است فقط یک روتر باشد که دقیقاً نوع ترافیک آزمون شما را در اولویت پایین‌تری قرار داده است. این یک هشدار نادرست رایج است که می‌تواند شما را به بن‌بست بکشاند.

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

نگاه فراتر از RTT ساده جایی است که مهم‌ترین بینش‌ها را خواهید یافت. نوسان بسته‌ها بالا، که فقط یک اصطلاح پر طمطراق برای تاخیر نامنظم است، می‌تواند بسیار آسیب‌رسان‌تر از تاخیری باشد که به طور مداوم بالاست. این به‌ویژه برای هر چیزی که به صورت لحظه‌ای (real-time) است صادق است.

اگر نتایج شما میانگین RTT برابر 40ms را نشان دهد، اما حداقل 10ms و حداکثر 150ms بوده است، اتصال شما ناپایدار است. آن تغییرات عظیم دقیقاً چیزی است که باعث لرزش‌های آزاردهنده در تماس‌های ویدیویی و تاخیرهای خشم‌آور در بازی‌های آنلاین می‌شود.

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

یکی از بزرگترین اشتباهاتی که می‌بینم مردم مرتکب می‌شوند، فرض کردن این است که یک تست تنها کل داستان را روایت می‌کند. شرایط شبکه به طور مداوم در حال تغییر است. یک تست که ساعت ۳ صبح اجرا می‌شود، کاملاً متفاوت از تستی است که ساعت ۳ بعدازظهر در ساعات اوج کاری اجرا شود. تنها راه برای به دست آوردن یک خط پایه عملکرد واقعی، از طریق تست‌های مداوم و تکرار شده است.

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

متداول‌ترین اشتباهات در اندازه‌گیری

حتی با بهترین ابزارهای جهان، چند اشتباه ساده می‌تواند نتایج شما را کاملاً بی‌فایده کند. اجتناب از این دام‌های رایج، در صورتی که به دنبال داده‌هایی هستید که واقعاً بتوانید به آنها اعتماد کنید، ضروری است.

• تست کردن از طریق Wi-Fi: واقعاً، فقط این کار را نکنید. اتصالات بی‌سیم به طور بدآوازه بی‌ثبات هستند و در معرض تداخل از همه چیز، از اجاق‌های مایکروفر گرفته تا روتر همسایه شما، قرار دارند. برای هرگونه تست جدی تأخیر، با کابل اترنت وصل شوید. این تنها راه برای به دست آوردن یک خط پایه پایدار و قابل اعتماد است.
• فراموش کردن سربار VPN: VPN‌ها برای امنیت عالی هستند، اما یک توقف اضافی و رمزگذاری به مسیر ترافیک شما اضافه می‌کنند. این همیشه تأخیر را افزایش می‌دهد. اگر سعی دارید اتصال کند کاربری را تشخیص دهید، یکی از اولین سوالات شما باید این باشد: "آیا شما از VPN استفاده می‌کنید؟" تست کردن با و بدون VPN به شما دقیقاً نشان خواهد داد که چه مقدار تأخیر اضافه می‌کند.
• نادیده گرفتن ازدحام شبکه محلی: نتایج تست شما تحریف خواهد شد اگر شخص دیگری در شبکه شما در حال بلعیدن تمام پهنای باند باشد. اگر یک همکار در حال پخش ویدیوی 4K یا دانلود فایل‌های حجیم در حین تست شما باشد، اعداد تأخیر شما بالا خواهند رفت و در نهایت به دنبال مشکلی خواهید گشت که وجود ندارد.

یک عامل دیگر ظریف اما حیاتی، ابزاری است که انتخاب می‌کنید. همانطور که بحث کردیم، ابزارهای مختلف تأخیر را به روش‌های مختلفی اندازه‌گیری می‌کنند. همیشه در ابزارهایی که برای مقایسه استفاده می‌کنید ثابت قدم باشید و مطمئن شوید که دقیقاً درک می‌کنید هر کدام واقعاً چه چیزی را اندازه می‌گیرند—چه یک ICMP echo ساده باشد چه یک درخواست پیچیده در سطح برنامه. و به یاد داشته باشید، عملکرد می‌تواند تحت تأثیر لایه‌های متعددی قرار گیرد؛ به عنوان مثال، اگر به دنبال کندوکاو در عملکرد وب هستید، راهنمای ما در مورد افزونه کروم ویرایشگر کوکی می‌تواند نشان دهد چگونه عناصر سمت کلاینت نقش ایفا می‌کنند.

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

سوالات متداول در مورد تأخیر شبکه

حتی با ابزارهای مناسب، وقتی شروع به بررسی تأخیر شبکه می‌کنید، همیشه چند سؤال رایج به نظر می‌رسد. اجازه دهید برخی از متداول‌ترین سؤالاتی که می‌شنوم را مرور کنیم تا به شما در درک نتایج‌تان کمک کنیم.

عدد «خوب» برای تأخیر دقیقاً چقدر است؟

این سؤال کلاسیک «بستگی دارد» است، اما قطعاً می‌توانیم معیارهای مشخصی تعیین کنیم. یک تأخیر «خوب» کاملاً نسبی است و به این بستگی دارد که چه چیزی می‌خواهید به دست آورید.

• گشت و گذار معمولی در وب: برای بیشتر ما، هر چیزی کمتر از ۱۰۰ میلی‌ثانیه RTT کاملاً مناسب به نظر می‌رسد. صفحات به سرعت بارگذاری می‌شوند و هیچ تأخیر واقعی احساس نخواهید کرد.
• بازی‌های آنلاین رقابتی: اینجاست که هر میلی‌ثانیه اهمیت دارد. گیمرهای جدی و معامله‌گران با فرکانس بالا به دنبال تأخیری به مراتب کمتر از ۲۰ میلی‌ثانیه هستند. این تفاوت بین بُرد و باخت است.
• تماس‌های تصویری و VoIP: اینجا، ثبات حرف اول را می‌زند. به یک تأخیر پایدار کمتر از ۱۵۰ میلی‌ثانیه و jitter پایین (کمتر از ۳۰ میلی‌ثانیه) نیاز دارید تا از آن حس ناهمگون و نامتعادل، یا بدتر، قطع تماس جلوگیری کنید.

به عنوان یک قاعده کلی، بیشتر متخصصان شبکه‌ای که من می‌شناسم، هر چیزی کمتر از ۵۰ میلی‌ثانیه را به عنوان تأخیر کم طبقه‌بندی می‌کنند. از ۵۰ تا ۱۵۰ میلی‌ثانیه متوسط است و وقتی از ۱۵۰ میلی‌ثانیه بالاتر می‌روید، شروع به احساس کندی در بیشتر برنامه‌های تعاملی خواهید کرد.

چرا نتایج Ping و تست سرعت مرورگر من هرگز با هم مطابقت ندارند؟

این یک سؤال عالی و بسیار رایج سردرگمی است. این اتفاق به این دلیل می‌افتد که یک ping خط فرمانی و یک تست سرعت مبتنی بر مرورگر، ابزارهای اساساً متفاوتی هستند که چیزهای متفاوتی را اندازه می‌گیرند.

برای شروع، آن‌ها تقریباً با سرورهای متفاوتی صحبت می‌کنند. وقتی یک دامنه را ping می‌کنید، به یک هدف خاص متصل می‌شوید. از طرف دیگر، یک تست سرعت وب برای یافتن سروری نزدیک از نظر جغرافیایی در شبکه خودش طراحی شده است تا بهترین نتیجه ممکن را به شما بدهد.

پروتکل‌ها نیز کاملاً متفاوت هستند. Ping از یک پروتکل بسیار سبک به نام ICMP استفاده می‌کند. بیشتر تست‌های مرورگر روی TCP اجرا می‌شوند که برای برقراری اتصال، یک فرآیند راه‌اندازی کامل («دست‌دهی سه‌جانبه») نیاز دارد. آن رفت و آمد اولیه مقداری زمان اضافه می‌کند حتی قبل از شروع تست واقعی.

در نهایت، تست‌های مرورگر اغلب بیش از صرفاً زمان صرف شده در شبکه را در بر می‌گیرند. عدد «تأخیر» آن‌ها ممکن است شامل زمان پردازش سرور یا حتی تأخیرهای کوچک در خود مرورگر شما باشد، که می‌تواند رقم نهایی را در مقایسه با یک ICMP ping خام، بزرگ‌تر نشان دهد.

چگونه می‌توانم واقعاً تأخیر شبکه خود را کاهش دهم؟

کاهش تأخیر همه چیز در مورد شناسایی و حذف تنگناهاست، چه در دفتر شما باشند چه در سراسر اینترنت.

اولین جایی که باید بررسی کنید محیط اطراف شماست. مؤثرترین تغییری که می‌توانید انجام دهید، جابه‌جایی از Wi-Fi به اتصال سیمی اترنت است. این کار برای پایداری و سرعت یک تحول بزرگ است. اگر مجبور به استفاده از Wi-Fi هستید، به روتر خود نزدیک‌تر شوید و در صورت امکان از باند 5GHz استفاده کنید—معمولاً شلوغی کمتری دارد.

فراتر از شبکه محلی خود، گاهی جایگزین کردن DNS می‌تواند کمک کند. استفاده از یک سریع‌تر DNS می‌تواند میلی‌ثانیه‌هایی از زمان اتصال اولیه را هنگام جستجوی یک وب‌سایت کاهش دهد.

اگر سعی در بهبود دسترسی به سرویسی دارید که کنترل آن را در دست دارید، شبکه تحویل محتوا (CDN) پاسخ است. این شبکه با قرار دادن کپی‌هایی از محتوای شما در فیزیک نزدیک‌تر به کاربرانتان کار می‌کند. و اگر از VPN استفاده می‌کنید، سعی کنید آن را خاموش کنید. آن پرش اضافی و لایه رمزگذاری تقریباً همیشه تأخیر ایجاد می‌کند.

دیده‌ام که VPN‌های شرکتی به اندازه 70ms به زمان رفت و برگشت اضافه کنند. این می‌تواند یک اتصال عالی را به اتصالی کند و ناامیدکننده تبدیل کند. همیشه با و بدون VPN خود تست کنید تا ببینید دقیقاً چه نوع کاهش عملکردی را تجربه می‌کنید.

تفاوت واقعی بین تأخیر و پهنای باند چیست؟

درک درست این موضوع برای فهم عملکرد شبکه اساسی است. اشتباه گرفتن آن‌ها آسان است، اما دو چیز بسیار متفاوت را اندازه‌گیری می‌کنند.

این تشبیهی است که همیشه استفاده می‌کنم: آن را مانند یک بزرگراه در نظر بگیرید.

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

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

---

آماده‌اید آزمون عملکرد را بخشی یکپارچه از جریان کاری روزانه خود کنید؟ مجموعه افزونه‌های ShiftShift یک آزمون سرعت قدرتمند، فرمت‌کننده JSON، و ده‌ها ابزار توسعه‌دهنده دیگر را درست در مرورگر شما قرار می‌دهد و با یک فرمان در دسترس است. دیگر با زبانه‌ها کلنجار نروید و شروع به هوشمندانه‌تر کار کنید. افزونه‌های ShiftShift را به صورت رایگان دانلود کنید و امروز بهره‌وری خود را افزایش دهید.