چگونه تأخیر شبکه را اندازهگیری کنیم: راهنمای عملی برای توسعهدهندگان
با این راهنمای جامع یاد بگیرید که چگونه تأخیر شبکه را اندازهگیری کنید. ما ابزارهای ضروری مانند ping و traceroute و تکنیکهای تست مبتنی بر مرورگر را پوشش میدهیم.
افزونههای پیشنهادی
میخواهید تأخیر شبکه را اندازهگیری کنید؟ میتوانید با ابزارهای ساده و داخلی خط فرمان مانند ping و traceroute شروع کنید تا یک خوانش سریع از زمان رفت و برگشت (RTT) به دست آورید. یا میتوانید ابزارهای توسعهدهنده مرورگر خود را باز کنید تا ببینید تأخیرها چگونه بر تجربه واقعی کاربران شما تأثیر میگذارند.
این روشها به شما یک نمای سریع و مفید از مدت زمانی که طول میکشد تا یک بسته داده از یک منبع به مقصد برسد و دوباره به عقب برگردد، میدهند.
چرا اندازهگیری تأخیر غیرقابل مذاکره است
قبل از اینکه به "چگونه" بپردازیم، بیایید درباره "چرا" صحبت کنیم. برای توسعهدهندگان و مهندسان شبکه، تأخیر فقط یک عدد روی صفحه نیست؛ این دست نامرئی است که کل تجربه کاربری را شکل میدهد. در برنامههای امروزی، میلیثانیهها همه چیز هستند. حتی یک تأخیر کوچک میتواند تفاوت بین یک سرویس که احساس فوری بودن میدهد و یکی که احساس خرابی میدهد، باشد.
به عواقب واقعی فکر کنید:
- پاسخگویی API: یک تماس API کند میتواند اثر دومینو ایجاد کند و همه چیز را از بارگذاری پروفایل کاربر تا پردازش یک پرداخت حیاتی متوقف کند.
- جریانهای داده در زمان واقعی: برای بازیهای آنلاین، ویدیوهای زنده یا تجارت مالی، تأخیر کم و ثابت اساس مطلق است. بدون آن، این برنامهها به سادگی کار نمیکنند.
- نگهداری کاربر: یک خط مستقیم وجود دارد که وبسایتها و برنامههای کند بارگذاری را به نرخهای پرش بالاتر و سبدهای خرید رها شده متصل میکند. این مسائل به شدت بر خط پایانی تأثیر میگذارد.
تمایز مفاهیم کلیدی تأخیر
برای اندازهگیری دقیق تأخیر شبکه، باید بدانید که به چه چیزی نگاه میکنید. دو مفهوم بنیادی زمان رفت و برگشت (RTT) و تأخیر یکطرفه هستند.
RTT کل زمانی است که طول میکشد تا یک سیگنال از نقطه A به نقطه B و دوباره به عقب برگردد. این متریک رایجترین متریک است که خواهید دید زیرا اندازهگیری آن ساده است—شما فقط به یک انتهای اتصال نیاز دارید.
تأخیر یکطرفه، همانطور که از نامش پیداست، زمان لازم برای سفر داده در یک جهت را اندازهگیری میکند. این اندازهگیری بسیار دشوارتر است زیرا نیاز به ساعتهای کاملاً همزمان در هر دو انتها دارد. با این حال، این یک نشانگر بسیار دقیقتر برای اتصالات نامتقارن است، جایی که مسیرهای بارگذاری و بارگیری رفتار بسیار متفاوتی دارند.
اهمیت همه اینها زمانی کاملاً روشن میشود که شما در حال انجام آزمایش بار عملکرد جدی هستید، جایی که نظریه با واقعیت ملاقات میکند و گلوگاهها نمایان میشوند.
برای قرار دادن برخی اعداد، کارشناسان نظارت بر شبکه معمولاً تأخیر را به این صورت طبقهبندی میکنند:
- تأخیر کم: کمتر از 50 میلیثانیه
- تأخیر متوسط: 50-150 میلیثانیه
- تأخیر بالا: بیش از 150 میلیثانیه
از تجربه من، یک آزمایش سریع به یک سرور نزدیک ممکن است تأخیری کاملاً قابل قبول 20-40 میلیثانیه را نشان دهد. اما آن عدد به راحتی میتواند به بیش از 200 میلیثانیه برای ترافیکی که باید از اقیانوس عبور کند، افزایش یابد، که میتواند برای عملکرد برنامه شما تغییر دهنده بازی باشد.
برای درک اصطلاحاتی که با آنها مواجه خواهید شد، در اینجا یک مرجع سریع وجود دارد.
مفاهیم کلیدی تأخیر در یک نگاه
| مفهوم | چه چیزی را اندازهگیری میکند | چرا مهم است |
|---|---|---|
| تأخیر (Ping) | زمانی که طول میکشد تا یک بسته داده از یک منبع به یک مقصد و دوباره برگردد. اندازهگیری شده در میلیثانیه (ms). | این اندازهگیری خام تأخیر است. تأخیر کم برای برنامههای زمان واقعی مانند بازی، VoIP و کنفرانس ویدیویی حیاتی است. |
| زمان رفت و برگشت (RTT) | در واقع همانند تأخیر است، این کل مدت زمانی است که برای ارسال یک سیگنال و سپس دریافت یک تأییدیه طول میکشد. | RTT رایجترین و عملیترین راه برای اندازهگیری تأخیر از یک نقطه واحد است و آن را به متریک اصلی برای ابزارهایی مانند ping تبدیل میکند. |
| تأخیر یکطرفه | زمانی که طول میکشد تا یک بسته از منبع به مقصد در یک جهت سفر کند. | نمایی دقیقتر ارائه میدهد، بهویژه برای شبکههای نامتقارن که در آن مسیرهای بارگذاری و بارگیری تأخیرهای متفاوتی دارند. |
| جیتتر | تغییرات تأخیر در طول زمان. این ناپایداری زمانهای ورود بستهها را اندازهگیری میکند. | جیتتر بالا به اندازه تأخیر بالا برای رسانههای استریم و تماسهای آنلاین بد است و باعث لکنت، بافر و اشکالات میشود. |
| پهنای باند | حداکثر مقدار دادهای که میتواند در یک اتصال شبکه در یک بازه زمانی معین منتقل شود. اندازهگیری شده در Mbps یا Gbps. | اغلب با سرعت اشتباه گرفته میشود، پهنای باند مربوط به ظرفیت است. شما میتوانید پهنای باند بالا داشته باشید اما هنوز از تأخیر بالا رنج ببرید. |
این مفاهیم بلوکهای سازنده برای درک هر مسئلهای در عملکرد شبکه هستند.
اینجاست که داشتن ابزارهای یکپارچه و قابل دسترسی بسیار مهم میشود. به جای اجرای مجموعههای تشخیصی پیچیده، افزونههای مدرن مرورگر و ابزارهای توسعه میتوانند بینشهایی را که نیاز دارید بدون ترک جریان کار شما ارائه دهند. این به معنای آسان کردن اندازهگیری تأخیر به عنوان بخشی بیدردسر و روتین از ساخت و نگهداری نرمافزار عالی است.
دست به کار شدن با ابزارهای تأخیر خط فرمان
برای اینکه واقعاً احساس کنید عملکرد شبکه شما چگونه است، باید ترمینال را باز کنید. خط فرمان جایی است که ابزارهای بنیادی را پیدا خواهید کرد که دادههای خام و بدون فیلتر درباره اتصال شما را ارائه میدهند. این به معنای دیدن آنچه که واقعاً در حال وقوع است با بستههایی است که بین شما و یک مقصد در حال حرکت هستند و این اولین قدم ضروری برای هر توسعهدهندهای است که به اندازهگیری تأخیر جدی است.
ابزار کلاسیک و مرجع ping است. این ابزار به طرز زیبایی ساده است: یک بسته داده کوچک (یک درخواست اکو ICMP) به یک سرور ارسال میکند و فقط منتظر میماند تا به عقب برگردد. آن سفر ساده مبنای محاسبه زمان رفت و برگشت (RTT) است و به شما یک بررسی فوری از سلامت یک اتصال میدهد.
اولین بررسی تأخیر شما با Ping
ping را تایپ کنید و آن را با دامنهای که میخواهید آزمایش کنید دنبال کنید.
بهطور پیشفرض، ping در macOS و Linux بهطور نامحدود ادامه مییابد، در حالی که ویندوز فقط چهار بسته ارسال میکند و متوقف میشود. برای هر تحلیل واقعی، شما میخواهید این را کنترل کنید. ارسال ده یا بیست بسته تصویری بسیار قابل اعتمادتر از ثبات اتصال نسبت به فقط چند بسته به شما میدهد.
پس از اتمام، یک خلاصه مرتب با اعداد حیاتی دریافت خواهید کرد:
- بستههای ارسال شده/دریافتی: این به شما میگوید که آیا دادهای در طول مسیر گم شده است یا خیر. حتی مقدار کمی از گم شدن بسته یک علامت خطر بزرگ برای مشکلات شبکه است.
- حداقل/میانگین/حداکثر/انحراف معیار رفت و برگشت: اینها آمار اصلی تأخیر شما هستند. شما زمان بهترین حالت (
min)، میانگین (avg) و بدترین حالت (max) را دریافت میکنید.mdev(انحراف معیار) اندازهگیری جیتری شماست—اینکه تأخیر چقدر از یک بسته به بسته دیگر متفاوت است.
به فاصله بین حداقل و حداکثر RTT خود توجه ویژهای داشته باشید. اگر این فاصله زیاد باشد، اتصال شما ناپایدار است، حتی اگر میانگین خوب به نظر برسد. این جیتری میتواند برای برنامههای زمان واقعی مانند تماسهای ویدیویی یا بازیها بسیار مخربتر از اتصالی باشد که به طور مداوم کمی کند است.
یک اشتباه رایج فقط نگاهی به میانگین RTT است. یک میانگین 50ms ممکن است خوب به نظر برسد، اما اگر حداقل شما 20ms و حداکثر شما 250ms باشد، تجربه کاربری احساس ناپایداری و ناپیوستگی خواهد داشت. همیشه به دامنه کامل نگاه کنید تا جیتری را درک کنید.
پیگیری مسیر با Traceroute و MTR
پس، وقتی ping تأخیر بالا یا از دست رفتن بسته را نشان میدهد، چه کار میکنید؟ کار بعدی شما این است که بفهمید مشکل کجاست. این همان چیزی است که traceroute (یا tracert در ویندوز) برای آن طراحی شده است. این ابزار مسیر کامل بستههای شما را ترسیم میکند و هر "پرش"—هر روتر—بین دستگاه شما و مقصد نهایی را به شما نشان میدهد.
هر خط در خروجی traceroute یک پرش است و معمولاً سه اندازهگیری تأخیر جداگانه تا آن نقطه را نشان میدهد. این به شما اجازه میدهد تا مشخص کنید آیا یک روتر خاص در مسیر باعث کاهش سرعت عمده یا از دست رفتن بستهها میشود یا خیر.
اما traceroute یک تصویر ثابت و یکباره است. برای نگاهی پویا و مداوم، بیشتر متخصصان شبکهای که میشناسم به MTR (My Traceroute) اعتماد دارند. MTR مانند ابزاری فوقالعاده است که ping و traceroute را ترکیب میکند. این ابزار به طور مداوم بستهها را به هر پرش در مسیر ارسال میکند و به شما نمای زنده و بهروزرسانی از تأخیر و از دست رفتن بسته در هر نقطه میدهد. این باعث میشود که در شناسایی مشکلات مقطعی که یک traceroute معمولی احتمالاً از دست میدهد، بسیار مؤثر باشد.
چرا انتخاب ابزار شما مهم است
ابزاری که انتخاب میکنید و نحوه پیکربندی آن میتواند نتایج شما را به طور چشمگیری تغییر دهد. این موضوع بهویژه در محیطهای فوقسریع و با تأخیر کم مانند مراکز داده ابری صادق است.
واقعاً جالب است که چقدر اعداد میتوانند متفاوت باشند. در یک آزمایش دقیق که توسط Google Cloud انجام شد، یک آزمایش استاندارد ping میانگین RTT را 146 میکروثانیه گزارش کرد. اما وقتی از ابزار دیگری استفاده کردند که تراکنشها را بدون وقفه ارسال میکند، RTT به 66.59 میکروثانیه کاهش یافت—بیش از دو برابر سریعتر!
این یک مثال عالی از این است که چرا ping گاهی اوقات میتواند تأخیر را بیش از حد برآورد کند. این نشان میدهد که درک چگونه یک ابزار کار میکند برای به دست آوردن اندازهگیریهایی که میتوانید به آنها اعتماد کنید، حیاتی است.
یافتن حداکثر سرعت اتصال شما با iperf
تأخیر همیشه تصویر کاملی نیست. گاهی اوقات شما نیاز دارید که حداکثر مقدار دادهای که اتصال شما میتواند واقعاً منتقل کند—پهنای باند آن—را بدانید. برای این کار، ابزاری که میخواهید iperf است.
در حالی که ping تأخیر را اندازهگیری میکند، iperf تماماً درباره توان عملیاتی است. این ابزار با راهاندازی یک اتصال کلاینت-سرور کار میکند و سپس به مدت معین، هر مقدار دادهای که میتواند بین آنها ارسال میکند.
برای استفاده از iperf، به دو دستگاه نیاز دارید:
- در یک دستگاه،
iperfرا در حالت سرور اجرا میکنید. این ابزار فقط آنجا مینشیند و منتظر اتصال میماند. - در دستگاه دیگر،
iperfرا در حالت کلاینت اجرا میکنید و آن را به آدرس سرور اشاره میکنید.
کلاینت متصل میشود و آزمایش آغاز میشود. خروجی به شما مجموع دادههای منتقل شده و، مهمتر از همه، نرخ بیت (پهنای باند شما) به صورت مگابیت یا گیگابیت در ثانیه را میگوید. این بهترین راه برای آزمایش فشار یک لینک شبکه و کشف قابلیتهای واقعی آن است.
اندازهگیری تأخیر از دیدگاه کاربر
در حالی که ابزارهای خط فرمان به شما نگاهی خام و بدون فیلتر به شبکهتان میدهند، تنها تأخیری که واقعاً برای یک برنامه وب اهمیت دارد، آن چیزی است که کاربر نهایی واقعاً تجربه میکند. اینجاست که تمرکز خود را از ترمینال به خود مرورگر تغییر میدهیم. آنچه در داخل مرورگر اتفاق میافتد داستانی بسیار غنیتر و مرتبطتر درباره عملکرد را روایت میکند.
هرگز فقط درباره یک سفر رفت و برگشت بسته نیست. تأخیری که کاربر احساس میکند یک کوکتل پیچیده از جستجوهای DNS، دست دادنهای TCP، مذاکرات TLS، زمان پردازش سرور و البته، زمانی است که برای واقعی نمایش محتوا روی صفحه صرف میشود. خوشبختانه، مرورگرهای مدرن با ابزارهای قدرتمند داخلی برای کمک به ما در تجزیه و تحلیل این فرآیند کامل پر شدهاند.
غوطهوری در ابزارهای توسعهدهنده مرورگر
هر مرورگر اصلی—Chrome، Firefox، Edge، Safari—با مجموعهای از ابزارهای توسعهدهنده مجهز شده است. زبانه "Network" در این ابزارها مرکز فرماندهی شما برای درک نحوه بارگذاری سایتتان است. این زبانه همه چیز را در یک نمودار آبشاری قرار میدهد، که یک تجزیه بصری از هر درخواست واحدی است که مرورگر برای نمایش یک صفحه انجام میدهد.
این نمای آبشاری بسیار ارزشمند است. شما میتوانید به دقت ببینید که هر دارایی چقدر طول کشید تا دانلود شود، از سند HTML اولیه و استایلهای CSS تا تصاویر و درخواستهای API. مهمتر از همه، این نمای آبشاری چرخه عمر هر درخواست را به مراحل متمایز تقسیم میکند:
- جستجوی DNS: زمان لازم برای حل یک نام دامنه به یک آدرس IP.
- اتصال اولیه: زمان صرف شده برای برقراری یک اتصال TCP با سرور.
- دست دادن SSL/TLS: بار اضافی لازم برای راهاندازی یک اتصال امن.
- زمان تا اولین بایت (TTFB): این یکی بسیار مهم است. این زمان را اندازهگیری میکند که مرورگر قبل از دریافت اولین بایت داده از سرور منتظر ماند.
- دانلود محتوا: زمان صرف شده برای دانلود خود منبع.
یک TTFB بالا، به عنوان مثال، نشانهای کلاسیک از یک پردازش کند در سمت سرور یا مشکل در backend است—چیزی که یک آزمایش ساده ping هرگز نمیتواند کشف کند. با تجزیه و تحلیل این آبشار، میتوانید به سرعت تشخیص دهید که کدام منابع مانع از رندر شدن یا به طور کلی بارگذاری بیش از حد طولانی میشوند.
یک نکته کلیدی از تجربه من این است که فقط به زمان بارگذاری کل نگاه نکنید، بلکه به دنبال بلندترین نوارها در آبشار باشید. یک تصویر بهینهنشده یا یک API کند از شخص ثالث میتواند کل صفحه را به گروگان بگیرد و تجربه کاربری ضعیفی ایجاد کند حتی اگر بقیه سایت بسیار سریع باشد.
اندازهگیری برنامهنویسی با APIهای زمانبندی
برای اندازهگیریهای خودکار و دقیقتر، میتوانید به APIهای جاوااسکریپت داخلی مرورگر دسترسی پیدا کنید. Navigation Timing API و Resource Timing API به شما دسترسی برنامهنویسی به همان دادههای عملکرد دقیقی که در ابزارهای توسعهدهنده میبینید، میدهند. این برای جمعآوری دادههای نظارت بر کاربران واقعی (RUM) به منظور درک نحوه عملکرد سایت شما برای بازدیدکنندگان واقعی در سرتاسر جهان عالی است.
شما میتوانید این معیارها را با چند خط جاوااسکریپت، درست در کنسول مرورگر، به دست آورید. به عنوان مثال، برای به دست آوردن زمانهای عملکرد اصلی برای بارگذاری صفحه اصلی، میتوانید از performance.getEntriesByType('navigation') استفاده کنید. این یک شیء حاوی زمانهای ارزشمند را برمیگرداند.
از آن دادهها، میتوانید معیارهای حیاتی را محاسبه کنید:
- زمان جستجوی DNS:
domainLookupEnd - domainLookupStart - زمان دست دادن TCP:
connectEnd - connectStart - زمان تا اولین بایت (TTFB):
responseStart - requestStart - زمان کل بارگذاری صفحه:
loadEventEnd - startTime
با دنبال کردن این چکلیست، میتوانید اطمینان حاصل کنید که تستهای شما به درستی طراحی شده و دادههای مفیدی را ارائه میدهند.
با رویکردی منظم، شما از اندازهگیری صرف تأخیر به درک واقعی آن منتقل میشوید. این رویکرد دقیق است که یک عدد تصادفی را از یک نشانگر عملکرد قابل اعتماد جدا میکند.
درک اعداد (و چه چیزهایی را باید اجتناب کرد)
به عنوان مثال، یک افزایش ناگهانی در زمان رفت و برگشت (RTT) در یک traceroute یک سرنخ کلاسیک است. اگر تأخیر در هاپ شماره سه افزایش یابد و تا انتها بالا بماند، احتمالاً مشکل خود را پیدا کردهاید: این روتر سوم یا لینک بلافاصله بعد از آن است. اما مراقب باشید. اگر فقط آن هاپ واحد تأخیر بالایی نشان دهد و مقصد نهایی هنوز سریع باشد، ممکن است فقط یک روتر باشد که برای ترافیک خاصی که آزمایش شما استفاده میکند، اولویت کمتری قائل شده است. این یک زنگ خطر رایج است که میتواند شما را به سمت یک مشکل غیرواقعی هدایت کند.
کدگشایی از جیتر و از دست دادن بستهها
نگاه کردن به فراتر از RTT ساده جایی است که شما مهمترین بینشها را پیدا خواهید کرد. جیتر بالا، که فقط یک کلمه شیک برای تأخیر نامنظم است، میتواند بسیار بیشتر از تأخیری که به طور مداوم بالا است، مزاحمت ایجاد کند. این به ویژه برای هر چیزی که به صورت زنده است، صادق است.
اگر نتایج شما میانگین RTT 40ms را نشان میدهد، اما حداقل 10ms و حداکثر 150ms بوده است، اتصال شما ناپایدار است. آن تغییرات بزرگ دقیقاً همان چیزی است که باعث ایجاد لکنتهای آزاردهنده در تماسهای ویدیویی و افزایش تأخیر در بازیهای آنلاین میشود.
از دست دادن بستهها یک زنگ خطر بزرگتر است. حتی 1% از دست دادن بسته میتواند به شدت برنامههای مبتنی بر TCP را مختل کند و آنها را مجبور به ارسال مجدد دادهها کند و همه چیز را به حالت کندی بکشاند. وقتی به نتایج آزمایش خود نگاه میکنید، هر تفاوت واقعی بین بستههای ارسال شده و بستههای دریافت شده باید فوراً بررسی شود.
یکی از بزرگترین اشتباهاتی که میبینم مردم مرتکب میشوند این است که فرض میکنند یک آزمایش تمام داستان را میگوید. شرایط شبکه به طور مداوم در حال تغییر است. یک آزمایش در ساعت 3 صبح کاملاً متفاوت از یکی در ساعت 3 بعد از ظهر در ساعات اوج کاری خواهد بود. تنها راه برای به دست آوردن یک خط پایه واقعی عملکرد، آزمایش مداوم و تکراری است.
برای پیشگیری از مشکلات، ارزش دارد که به ابزارهای اختصاصی برای نظارت بر عملکرد شبکه نگاه کنید. این رویکرد شما را از تعمیرات اضطراری به سمت حفظ سلامت شبکه به صورت پیشگیرانه منتقل میکند.
متداولترین اشتباهات اندازهگیری
حتی با بهترین ابزارهای دنیا، چند اشتباه ساده میتواند نتایج شما را کاملاً بیفایده کند. اجتناب از این دامهای رایج غیرقابل مذاکره است اگر میخواهید دادههایی داشته باشید که واقعاً به آن اعتماد کنید.
- آزمایش از طریق Wi-Fi: واقعاً، فقط این کار را نکنید. اتصالات بیسیم به طور مشهور ناپایدار هستند و مستعد تداخل از هر چیزی از مایکروویوها تا روتر همسایه شما هستند. برای هر آزمایش تأخیر جدی، با یک کابل Ethernet متصل شوید. این تنها راه برای به دست آوردن یک خط پایه پایدار و قابل اعتماد است.
- فراموش کردن بار اضافی VPN: VPNها برای امنیت عالی هستند، اما یک توقف و رمزگذاری اضافی به سفر ترافیک شما اضافه میکنند. این همیشه تأخیر را افزایش میدهد. اگر در حال تلاش برای تشخیص اتصال کند یک کاربر هستید، یکی از اولین سوالات شما باید این باشد: "آیا شما در VPN هستید؟" آزمایش با و بدون آن به شما نشان میدهد که دقیقاً چقدر تأخیر اضافه میکند.
- نادیده گرفتن ترافیک محلی شبکه: نتایج آزمایش شما اگر شخص دیگری در شبکه شما تمام پهنای باند را اشغال کند، تحریف خواهد شد. اگر یک همکار در حال پخش ویدیو 4K یا دانلود فایلهای بزرگ باشد در حالی که شما در حال آزمایش هستید، اعداد تأخیر شما افزایش مییابد و شما در نهایت به دنبال مشکلی میگردید که وجود ندارد.
یک عامل ظریف اما حیاتی دیگر، ابزاری است که انتخاب میکنید. همانطور که پوشش دادهایم، ابزارهای مختلف تأخیر را به روشهای مختلف اندازهگیری میکنند. همیشه با ابزارهایی که برای مقایسه استفاده میکنید، سازگار باشید و مطمئن شوید که میدانید هر کدام واقعاً چه چیزی را اندازهگیری میکند—چه یک اکو ICMP ساده باشد یا یک درخواست پیچیده در سطح برنامه. و به یاد داشته باشید، عملکرد میتواند تحت تأثیر لایههای زیادی قرار گیرد؛ به عنوان مثال، اگر در حال بررسی عملکرد وب هستید، راهنمای ما در مورد افزونه ویرایشگر کوکی Chrome میتواند نشان دهد که عناصر سمت کاربر چگونه نقش ایفا میکنند.
با تفسیر نتایج خود در زمینه مناسب و دوری از این اشتباهات رایج، شما فراتر از جمعآوری اعداد خواهید رفت. شما شروع به درک چرا عملکرد شبکه خود خواهید کرد و این کلید ساخت سیستمهای سریعتر و قابل اعتمادتر است.
سوالات متداول درباره تأخیر شبکه
حتی با ابزارهای مناسب، چند سوال رایج همیشه به نظر میرسد زمانی که شما شروع به بررسی تأخیر شبکه میکنید. بیایید به برخی از متداولترین سوالاتی که میشنوم بپردازیم تا به شما کمک کنیم نتایج خود را درک کنید.
عدد "خوب" تأخیر واقعاً چیست؟
این سوال کلاسیک "به شرایط بستگی دارد" است، اما ما قطعاً میتوانیم چند معیار محکم تعیین کنیم. یک تأخیر "خوب" کاملاً نسبی است به آنچه که شما سعی در دستیابی به آن دارید.
- مرور وب عادی: برای اکثر ما، هر چیزی زیر 100ms RTT کاملاً خوب به نظر میرسد. صفحات به سرعت بارگذاری میشوند و شما هیچ تأخیر واقعی را متوجه نخواهید شد.
- بازی آنلاین رقابتی: اینجا جایی است که هر میلیثانیه اهمیت دارد. گیمرهای جدی و معاملهگران با فرکانس بالا به دنبال تأخیری بسیار پایینتر از 20ms هستند. این تفاوت بین پیروزی و شکست است.
- تماسهای ویدیویی و VoIP: در اینجا، ثبات مهم است. شما به یک تأخیر پایدار زیر 150ms و جیتر پایین (کمتر از 30ms) نیاز دارید تا از احساس لکنت و عدم همزمانی یا بدتر، تماسهای قطع شده جلوگیری کنید.
به عنوان یک قاعده کلی، بیشتر حرفهایهای شبکهای که میشناسم هر چیزی زیر 50ms را به عنوان تأخیر پایین طبقهبندی میکنند. از 50-150ms متوسط است و وقتی از 150ms عبور کنید، شروع به احساس کشش در بیشتر برنامههای تعاملی خواهید کرد.
چرا نتایج تست پینگ و سرعت مرورگر من هرگز مطابقت ندارند؟
این یک سوال فوقالعاده است و یک نقطه سردرگمی بسیار رایج. این اتفاق میافتد زیرا یک ping خط فرمان و یک تست سرعت مبتنی بر مرورگر ابزارهای بنیادی متفاوتی هستند که چیزهای مختلفی را اندازهگیری میکنند.
برای شروع، آنها تقریباً قطعاً با سرورهای متفاوتی صحبت میکنند. وقتی شما یک دامنه را ping میکنید، به یک هدف خاص ضربه میزنید. از طرف دیگر، یک تست سرعت وب برای پیدا کردن یک سرور جغرافیایی نزدیک از شبکه خود طراحی شده است تا بهترین نتیجه ممکن را به شما بدهد.
پروتکلها نیز کاملاً متفاوت هستند. Ping از یک پروتکل بسیار سبک به نام ICMP استفاده میکند. بیشتر تستهای مرورگر بر روی TCP اجرا میشوند، که نیاز به یک فرآیند راهاندازی کامل (دست دادن سهطرفه) فقط برای برقراری ارتباط دارد. آن رفت و برگشت اولیه کمی زمان اضافه میکند قبل از اینکه آزمایش واقعی حتی آغاز شود.
در نهایت، تستهای مرورگر اغلب بیشتر از فقط زمان سفر خالص شبکه را در نظر میگیرند. عدد "تأخیر" آنها ممکن است شامل زمان پردازش سرور یا حتی تأخیرهای کوچک در خود مرورگر شما باشد، که میتواند عدد نهایی را در مقایسه با یک پینگ خام ICMP افزایش دهد.
چگونه میتوانم واقعاً تأخیر شبکه خود را کاهش دهم؟
کاهش تأخیر به معنای شناسایی و حذف گلوگاهها است، چه در دفتر شما و چه در سراسر اینترنت.
اولین جایی که باید به آن نگاه کنید، محیط نزدیک شماست. مؤثرترین تغییری که میتوانید ایجاد کنید، تغییر از Wi-Fi به اتصال اترنت با سیم است. این تغییر برای ثبات و سرعت یک تغییر اساسی است. اگر مجبور به استفاده از Wi-Fi هستید، به روتر خود نزدیکتر شوید و اگر میتوانید، به باند 5GHz بروید—این باند معمولاً شلوغی کمتری دارد.
با نگاهی به فراتر از شبکه محلی خود، گاهی اوقات تعویض DNS میتواند کمک کند. استفاده از یک سرور DNS سریعتر میتواند میلیثانیههایی از زمان اتصال اولیه شما هنگام جستجوی یک وبسایت کم کند.
اگر سعی دارید دسترسی به یک سرویس که تحت کنترل شماست را بهبود ببخشید، شبکه تحویل محتوا (CDN) پاسخ است. این کار با قرار دادن نسخههایی از محتوای شما در نزدیکی فیزیکی کاربران شما انجام میشود. و اگر از VPN استفاده میکنید، سعی کنید آن را خاموش کنید. آن پرش اضافی و لایه رمزگذاری تقریباً همیشه تأخیر را اضافه میکند.
من دیدهام که VPNهای شرکتی میتوانند تا 70ms به زمان رفت و برگشت اضافه کنند. این میتواند یک اتصال عالی را به یک اتصال به شدت کند تبدیل کند. همیشه با VPN و بدون آن تست کنید تا ببینید واقعاً چه نوع افت عملکردی را تجربه میکنید.
تفاوت واقعی بین تأخیر و پهنای باند چیست؟
درست درک کردن این موضوع برای فهم عملکرد شبکه اساسی است. آسان است که آنها را با هم اشتباه بگیرید، اما آنها دو چیز بسیار متفاوت را اندازهگیری میکنند.
این تشبیه را همیشه استفاده میکنم: آن را مانند یک بزرگراه تصور کنید.
- پهنای باند تعداد لایههای بزرگراه است. لایههای بیشتر به معنای این است که خودروهای بیشتری (دادهها) میتوانند همزمان حرکت کنند.
- تأخیر حد سرعت است. این تعیین میکند که یک خودرو (یک بسته داده) چقدر سریع میتواند از A به B برسد.
شما میتوانید یک بزرگراه عظیم با ده لایه (پهنای باند بزرگ) با حد سرعت 20 مایل در ساعت (تأخیر بالا) داشته باشید. شما میتوانید در نهایت مقدار زیادی داده منتقل کنید، اما چیزهای زمان واقعی مانند یک تماس ویدیویی به شدت کند خواهد بود. از طرف دیگر، یک اتصال با تأخیر بسیار کم احساس فوقالعادهای از سرعت و پاسخگویی دارد، حتی اگر پهنای باند آن زیاد نباشد. شما واقعاً به یک تعادل خوب از هر دو برای یک تجربه عالی نیاز دارید.
آمادهاید که تست عملکرد را به بخشی یکپارچه از جریان کار روزانه خود تبدیل کنید؟ مجموعه ShiftShift Extensions یک تست سرعت قدرتمند، فرمتکننده JSON و دهها ابزار دیگر توسعهدهنده را درست در داخل مرورگر شما قرار میدهد که با یک فرمان قابل دسترسی است. از جابجایی تبها دست بردارید و شروع به کار هوشمندانهتر کنید. ShiftShift Extensions را به صورت رایگان دانلود کنید و امروز بهرهوری خود را افزایش دهید.