آن‌چه در این مقاله می‌خوانید:
زمان رفت و برگشت (Round-trip time – RTT) معیاری بسیار مهم در شبکه است که می‌تواند کیفیت ارتباطات بین دو نقطه پایانی (endpoint) را نشان دهد. عوامل متعددی، به ویژه توپولوژی شبکه می‌تواند در محاسبه این معیار مؤثر باشد. در این مقاله می‌خواهیم به بررسی مفهوم RTT، نحوه محاسبه آن و همچنین تأثیر استفاده از CDN برای بهبود RTT بپردازیم.
زمان رفت و برگشت (RTT) چیست؟
زمان رفت و برگشت (RTT) در شبکه، که به عنوان زمان تأخیر رفت و برگشت (RTD) نیز شناخته می‌شود، معیاری است که برحسب میلی ثانیه (ms) مدت زمان ارسال یک بسته داده، به اضافه مدت زمان دریافت تأییدیه سیگنال آن را نشان می‌دهد.
به عبارت دیگر، RTT از زمانی که مرورگر درخواستی را به سرور ارسال می‌کند تا زمانی که پاسخی از سرور دریافت می‌کند، محاسبه می‌شود. عدد حاصل از این محاسبه برای برنامه‌های کاربردی وب بسیار مهم است. RTT به همراه TTFB از اصلی‌ترین معیارهای اندازه‌گیری زمان بارگذاری صفحه و تأخیر شبکه محسوب می‌شود.
تفاوت بین RTT و Ping چیست؟
گاهی اوقات، زمان Round-trip و Ping (پینگ) مترادف یکدیگر در نظر گرفته می‌شوند. اگرچه زمان پینگ هم می‌تواند تخمین خوبی از RTT ارائه دهد، اما تفاوت بین Ping و RTT این است که تست‌های پینگ معمولا در پروتکل Transport انجام می‌شود و از بسته‌های ICMP استفاده می‌کند.
درحالیکه، RTT در لایه‌ی کاربرد (لایه 7 OSI/ISO) اندازه‌گیری می‌شود و شامل تأخیرهای اضافی ناشی از پروتکل‌ها و برنامه‌های سطح بالاتر (مانند ارتباطات رمزگذاری شده توسط HTTP) است.
تفاوت بین RTT و تأخیر (Latency) چیست؟
تأخیر شبکه ارتباط نزدیکی با RTT دارد، اما متفاوت است. تأخیر، مدت زمانی است که طول می‌کشد تا یک بسته داده از نقطه پایانی مبدأ به نقطه پایانی مقصد (فقط یک رفت) ارسال شود. عوامل زیادی ممکن است بر این مسیر تأثیر بگذارد.
تأخیر ممکن است بین هر دو نقطه پایانی نامتقارن باشد، یعنی عواملی که در مسیر رفت تأثیرگذار هستند، ممکن است در مسیر برگشت وجود نداشته باشند؛ بنابراین نمی‌توان گفت که “تأخیر” دقیقا برابر با نیمی از RTT است!
RTT خوب چقدر است؟
هر نوع برنامه‌ای نیازمندی‌های خاص خودش را دارد و تقریبا غیرممکن است که بتوان زمان مشخصی را به عنوان RTT خوب تعیین کرد. به طور کلی هر چه مقدار RTT کمتر باشد، نشان‌دهنده عملکرد سریع‌تر و بهتر است. اما این کمتر یا بیشتر بودن نسبت به میزانی در نظر گرفته می‌شود که برای یک سرویس آنلاین تعریف شده است.
برای مثال، سرویس استریم مدیا اَبر دِراک که به کاربران اجازه می‌دهد ویدئوهای خود را به صورت آنلاین یا پخش زنده با مخاطبان خود به اشتراک بگذارند، میزان RTT را این‌گونه برای خود تعریف کرده است:
- زمان رفت و برگشت (RTT) بین شبکه مشتری تا سرورهای سرویس استریم مدیا باید کمتر از 8000ms باشد.
- اگر RTT بین 8000ms و 16000ms باشد، کاربر می‌تواند به سرویس دسترسی داشته باشد، اما عملکرد آن تحت تأثیر قرار می‌گیرد.
- اگر RTT بین 16000ms و 20000ms باشد، عملکرد سرویس کاهش می‌یابد.
- و اگر RTT از 20000ms بیشتر شود، دسترسی کاربر به سرویس قطع می‌شود.
بنابراین، می‌توان گفت که کاربران باید حداقل 8000ms و حداکثر 16000ms RTT داشته باشند تا بتوانند بدون نگرانی از سرویس استفاده کنند.
چرا RTT در شبکه مهم است؟
زمان رفت و برگشت شبکه تأثیر زیادی بر تجربه کاربری دارد. مدیران شبکه می‌توانند از این معیار برای تشخیص سرعت و قابلیت اطمینان اتصال شبکه استفاده کنند. اگر RTT خیلی زیاد باشد، بسیاری از برنامه‌های کاربردی وب قطع می‌شوند.
نحوه محاسبه یا اندازه گیری RTT
محاسبه RTT
بهترین راه برای محاسبه RTT درک مراحل لازم برای مشاهده یک صفحه‌ی وب است. وقتی کاربر بخواهد یک صفحه وب را در مرورگر بارگذاری کند، ابتدا باید درخواست بارگیری صفحه را ارسال کند، که برای دریافت پاسخ توسط کاربر، حداقل یک RTT مورد نیاز است.
RTT یک متریک پیچیده است که چندین مؤلفه دارد. این مؤلفه‌ها شامل تأخیر انتشار (propagation delay)، تأخیر پردازش (processing delay)، تأخیر در صف (queuing delay) و تأخیر رمزگذاری (encoding delay) است. اما معمولا تأخیر پردازش، تأخیر در صف و تأخیر رمزگذاری مقادیر ناچیزی دارند.
تأخیر انتشار، مدت زمانی است که صرف می‌شود تا درخواست به مقصد برسد. معمولا، تأخیر انتشار مؤلفه غالب در RTT است و می‌توان با استفاده از یک فرمول ساده، تخمین خوبی از RTT را بدست آورد:
زمان انتشار * 2 = RTT
نکته دیگری که در رابطه با این موضوع وجود دارد این است که معمولا بیش از یک درخواست برای بارگیری کل صفحه وب لازم است. صفحه درخواستی ممکن است متشکل از تصاویر، اسکریپت‌ها و موارد دیگری باشد که هر کدام نیاز به درخواست جداگانه‌ای برای بارگیری دارند. اگر صفحه از 20 جزء تشکیل شده باشد، ممکن است RTT x 20 طول بکشد تا کل صفحه کاملا بارگذاری شود.
اندازه‌گیری RTT
رایج‌ترین ابزاری که برای اندازه‌گیری RTT استفاده می‌شود، دستور ping است. دستور پینگ بسته‌های ICMP را به مقصد ارسال می‌کند و سپس زمان دریافت سیگنال پاسخ را بر حسب میلی ثانیه گزارش می‌دهد. در ویندوز می‌توان با نوشتن ping Domain or IP در محیط CMD این مقادیر را مشاهده کرد. (به جای Domain or IP باید آدرس وب‌سایت یا ip مورد نظرتان را بنویسید)
همچنین، برای اندازه گیری میانگین، حداکثر و حداقل RTT برای یک سرور مشخص می‌توانید از دستور زیر در محیط ترمینال لینوکس استفاده کنید.
ping -c 20 -i 1 "domain name or ip address"
/*example
ping -c 20 -i 1 google.com
اگر نیاز به اطلاعات بیشتری در مورد “مسیر” (نقطه شروع تا سرور مبدأ) دارید، می‌توانید از دستور traceroute نیز استفاده کنید و اطلاعات خوبی در مورد مدت زمان هر پرش در مسیر را دریافت کنید.
چه عواملی بر RTT تأثیر می‌گذارند؟
عواملی که می‌توانند بر RTT تأثیر بگذارند، عبارتند از:
- فاصله فیزیکی: فاصله بین نقطه شروع (سرور مبدأ) و نقطه پایان (کامپیوتر کاربر) عامل اصلی مؤثر بر RTT است. با نزدیک‌تر کردن محتوا به کاربر می‌توان این مدت زمان را کاهش داد.
- زمان پاسخگویی سرور مبدأ: مدت زمانی که طول می‌کشد تا سرور درخواست ورودی را پردازش کرده و به آن پاسخ دهد، نقش زیادی در تأخیر شبکه دارد. هنگامی که سرور مبدأ با درخواست‌های زیادی مواجه می‌شود، مانند حمله DDoS، توانایی پاسخ‌دهی موثر آن مهار شده و RTT افزایش می‌یابد.
- رسانه انتقال (کابل): نحوه ایجاد اتصالات بر سرعت حرکت داده‌ها تأثیر می‌گذارد. مثلا، اتصالات فیبر نوری رفتار متفاوتی نسبت به اتصالات سیم مسی دارند. همچنین، اتصالی که از طریق فرکانس بی‌سیم انجام می‌شود، رفتار متفاوتی با ارتباط ماهواره‌ای خواهد داشت.
- ترافیک شبکه LAN: میزان ترافیک در شبکه باعث کندی اتصال اینترنت یا قطعی آن می‌شود. بنابراین، زمانی که ترافیک شبکه زیاد باشد، میزان RTT به شدت افزایش یافته و وقتی این ترافیک کاهش پیدا کند، RTT نیز کاهش می‌یابد.
- تعداد پرش‌های (hops) شبکه: روترها یا سرورهای میانی مدت زمان متغیری برای پردازش سیگنال صرف می‌کنند و RTT را افزایش می‌دهند. هر چه یک سیگنال جهش بیشتری را طی کند (یعنی در مسیر خود با روترها و سرورهای میانی مواجه شود)، RTT نیز بالاتر می‌رود.
چگونه RTT را کاهش دهیم؟
راه‌های مختلفی برای کاهش RTT وجود دارد. در این بخش، به معرفی دو روش می‌پردازیم: روش‌های عمومی و CDN.
کاهش RTT با روش‌های عمومی
- کاهش تعداد نام‌های میزبان (hostname) منحصربه‌فرد: این کار باعث می‌شود تا تعداد رزولوشن‌های DNS که مرورگر باید ایجاد کند، کاهش یابد.
- به حداقل رساندن تغییر مسیرهای HTTP/S: تغییر مسیر (Redirect) از یک URL به URL دیگر باعث افزایش RTT و مدت زمان انتظار برای کاربران می‌شود.
- حذف “لینک‌های شکسته”: حذف لینک‌های خراب یا درخواست‌هایی که منجر به خطاهای 404/410 می‌شود، از درخواست‌های بیهوده بعدی جلوگیری می‌کند.
- ترکیب فایل‌های اسکریپت، CSS و…: ترکیب و فشرده کردن این نوع فایل‌ها به تعداد فایل‌های کمتر باعث کاهش RTT می‌شود، زیرا به تعداد دانلود کمتری نیاز خواهد بود.
- کش مرورگر (Browser caching): مرورگرها منابع خاصی از یک وب‌سایت را به صورت محلی در حافظه کش خود ذخیره می‌کنند تا به بهبود RTT کمک کنند.
- نزدیک‌تر کردن محتوا به کاربر: با نزدیک کردن سرورها به کاربر نهایی، RTT به میزان قابل توجهی کاهش می‌یابد. CDN (شبکه توزیع محتوا) این کار را به‌طور خودکار برای شما انجام می‌دهد.
کاهش RTT با استفاده از CDN
Content Delivery Network (CDN) شبکه‌ای از سرورهای لبه است که به‌طور استراتژیک در سراسر جهان پراکنده شده‌اند و هر کدام یک کپی از محتوای وب‌سایت‌های مختلف را در خود ذخیره دارند. CDN می‌تواند تأثیر بسزایی در کاهش RTT داشته باشد و عوامل موثر بر RTT را به روش‌های زیر بررسی کند:
- نقاط حضور (PoPs) – نقاط حضور یا پاپ‌سایت‌ها شامل سرورهای لبه بوده و مسئول توزیع محتوای وب‌سایت بین کاربران هستند. کاربران به نزدیک‌ترین سرور لبه متصل می‌شوند و مسافتی که درخواست آن‌ها برای مشاهده صفحه وب باید طی کند، کوتاه‌تر شده و در نتیجه تعداد پرش‌های شبکه مورد نیاز برای رسیدن به سرور کاهش می‌یابد. کاهش پرش‌ها باعث کاهش RTT می‌شود.
- کش وب (Web Caching) – CDN فایل‌های HTML، عکس و فیلم، و حتی محتوای پویای یک وب‌سایت را در پاپ‌سایت‌های خود ذخیره کرده و در مجاورت کاربران نگهداری می‌کند. درخواست کاربر توسط PoP محلی مورد بررسی قرار می‌گیرد و دیگر نیازی به رفتن به سرور مبدأ وجود ندارد؛ در نتیجه RTT کاهش پیدا می‌کند.
- توزیع بار (Load distribution) – زمانی که ترافیک زیاد است، CDNها درخواست‌ها را به سرورهای پشتیبان با ترافیک کمتر هدایت می‌کنند. این استراتژی باعث افزایش سرعت پاسخ سرور می‌شود و RTT را کاهش می‌دهد.
- مقیاس پذیری (Scalability) – سرویس CDN در فضای ابری کار می‌کند و مقیاس‌پذیری بالا و توانایی پردازش تعداد تقریبا نامحدودی از درخواست‌های کاربران را ممکن می‌سازد. این امر موجب از بین رفتن گلوگاه در سمت سرور می‌شود.
- دسترسی Tier 1 – شبکه‌های توزیع محتوا با بزرگ‌ترین ارائه‌دهندگان خدمات اینترنتی (ISP) برای ارائه دسترسی Tier 1 به Backbone اینترنت توافقاتی دارند. این امر تعداد پرش‌های شبکه را کاهش داده و همچنین، زمان رفت و برگشت سیگنال را تا حد زیادی کاهش می‌دهد.
یکی از مشکلات اصلی که CDNها برای حل آن طراحی شده بودند، کاهش زمان رفت و برگشت بود. با توجه به نکات ذکر شده در بالا، می‌توان گفت که این هدف تا حد مطلوبی برآورده شده است. بنابراین، انتظار می‌رود پس از خرید و راه‌اندازی سرویس CDN مقدار RTT حداقل به میزان 50٪ یا بیشتر کاهش پیدا کند.
بهبود RTT با خرید سرویس CDN اَبر دِراک
سرورهای CDN اَبر دِراک با قرار گرفتن در نقاط تبادل اینترنت (IXP) و مراکز داده متعدد در سراسر جهان، مسیریابی شبکه را برای تحویل محتوا به کاربر بهینه می‌کند؛ در نتیجه RTT وب‌سایت به طور چشمگیری کاهش یافته و بازدیدکنندگان وب‌سایت تأخیر کمتری را تجربه می‌کنند.
جهت آشنایی با سرویس CDN و نحوه کاهش RTT توسط آن، می‌توانید به مقالاتی درباره “Caching“، “دیتاسنتر” و “بهینه‌سازی فایل” که در وب‌سایت موجود است، مراجعه کنید.
برای کسب اطلاعات خرید سرویس CDN به صفحه محصول CDN اَبر دِراک و هزینه‌ها مراجعه نمایید.
