تأخیر (Latency) چیست؟ تفاوت آن با پینگ و راه‌های کاهش آن

تماس تصویری‌ای که در آن همه مدام حرف یکدیگر را قطع می‌کنند، صفحه وبی که لحظه‌ای سفید می‌ماند، یا یک API که بیشتر وقت‌ها در 40 میلی‌ثانیه پاسخ می‌دهد و هر از گاهی در 900 میلی‌ثانیه. هر سه، مشکل تأخیر (latency) هستند و هیچ‌کدام با سرویس اینترنت سریع‌تر حل نمی‌شوند. تأخیر زمان انتظار پیش از رسیدن داده است و رفتاری متفاوت با سرعت دانلودی دارد که ارائه‌دهنده اینترنت تبلیغ می‌کند.

در ادامه می‌خوانید تأخیر چیست، از کجا می‌آید، چه تفاوتی با پینگ و پهنای باند دارد، چگونه با ping و curl اندازه‌گیری می‌شود (با خروجی واقعی رایانه آزمایشی ما)، چه مقدارهایی خوب‌اند، چگونه می‌توان آن را کاهش داد و پروکسی چه چیزی را تغییر می‌دهد.

تأخیر چیست؟#

تأخیر فاصله زمانی میان فرستادن داده و رسیدن آن است، یا میان یک درخواست و پاسخ آن. با میلی‌ثانیه اندازه‌گیری می‌شود و هر 1,000 میلی‌ثانیه یک ثانیه است. وقتی روی یک لینک کلیک می‌کنید، درخواست تا سرور می‌رود و پاسخ برمی‌گردد، و هر یک از این دو مسیر پیش از آنکه صفحه بتواند ظاهر شود زمان انتظاری اضافه می‌کند.

تأخیر یک‌طرفه فقط مسیر رفت از A به B است؛ اندازه‌گیری آن دشوار است، چون ساعت هر دو دستگاه باید تا حد میلی‌ثانیه با هم هماهنگ باشد. زمان رفت‌وبرگشت (RTT) رفت و برگشت را با هم در بر می‌گیرد و با ساعت خود فرستنده سنجیده می‌شود. ⁦RFC 2681⁩، معیار IETF برای تأخیر رفت‌وبرگشت، آن را زمانی تعریف می‌کند که از فرستادن یک بسته آزمایشی تا رسیدن کامل پاسخ آن می‌گذرد. پینگ، تست‌های سرعت و بیشتر ابزارها RTT را گزارش می‌کنند؛ پس در استفاده روزمره منظور از «تأخیر» یک رفت‌وبرگشت است.

چه چیزی باعث تأخیر می‌شود؟#

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

1. فاصله. سیگنال در فیبر نوری با حدود دو سوم سرعت نور در خلأ حرکت می‌کند. توصیه برنامه‌ریزی اتحادیه بین‌المللی مخابرات (ITU) با نام ⁦G.114⁩ برای هر کیلومتر فیبر 5 میکروثانیه در نظر می‌گیرد: 5 میلی‌ثانیه برای هر 1,000 کیلومتر در یک جهت و 10 میلی‌ثانیه برای رفت‌وبرگشت، پیش از آنکه هیچ دستگاهی سهم خود را اضافه کند. کابل‌ها به‌ندرت در خط مستقیم کشیده می‌شوند، پس مسیرهای واقعی از فاصله روی نقشه بلندترند. برای پیوند ماهواره‌ای زمین‌آهنگ، ⁦G.114⁩ فقط برای مسیر درون فضا حدود 260 میلی‌ثانیه در یک جهت ذکر می‌کند.
2. هاپ‌ها و مسیریابی. میان شما و یک سرور زنجیره‌ای از روترها قرار دارد که هر کدام یک هاپ (hop) است. مسیر تعیین می‌کند یک بسته چه مسافتی را طی کند، و ترافیک میان دو شهر نزدیک به هم ممکن است از مسیری انحرافی و از یک نقطه تبادل ترافیک دوردست بگذرد. نوشته دستور tracert چیست؟ نشان می‌دهد چگونه هاپ‌ها را فهرست کنید و ببینید زمان در کجا بیشتر می‌شود.
3. صف‌ها در پیوندهای شلوغ. روتری که بسته‌ها را سریع‌تر از آنچه می‌تواند جلو بفرستد دریافت می‌کند، آن‌ها را در یک بافر، یعنی یک صف انتظار، نگه می‌دارد. وقتی یک پشتیبان‌گیری ابری یا یک آپلود بزرگ اتصال شما را پر می‌کند، همه بسته‌های دیگر پشت آن منتظر می‌مانند. به تأخیری که فقط هنگام شلوغ بودن خط بالا می‌رود bufferbloat (تورم بافر) می‌گویند.
4. Wi-Fi و رادیوی موبایل. Wi-Fi یک کانال رادیویی مشترک است: دستگاه‌های شما و شبکه‌های همسایه به نوبت از آن استفاده می‌کنند و فریم‌هایی که بر اثر تداخل گم می‌شوند دوباره فرستاده می‌شوند. هر انتظار و هر تکرار تأخیری اضافه می‌کند که لحظه‌به‌لحظه تغییر می‌کند. اینترنت موبایل هم پیوند رادیویی خودش را تا دکل مخابراتی اضافه می‌کند.
5. زمان سرور. سرور باید پاسخ را آماده کند: پایگاه داده را بخواند، صفحه را بسازد و سرویس‌های دیگر را فراخوانی کند. این زمان برای شما تأخیر است و هیچ کاری در سمت شما آن را کوتاه نمی‌کند.

اتصال تازه به یک وب‌سایت هم پیش از جابه‌جا شدن هر محتوایی چند رفت‌وبرگشت هزینه دارد: جست‌وجوی DNS برای تبدیل نام به آدرس (مگر اینکه در کش باشد)، اتصال TCP، دست‌دادن TLS که HTTPS را امن می‌کند، و سپس خود درخواست. بنابراین یک اتصال HTTPS تازه به سروری که 100 میلی‌ثانیه دورتر است، پیش از رسیدن نخستین بایت دست‌کم به سه رفت‌وبرگشت، یعنی حدود 300 میلی‌ثانیه، نیاز دارد.

تفاوت تأخیر با پهنای باند، توان عملیاتی، جیتر و از دست رفتن بسته#

این اصطلاح‌ها جنبه‌های مختلف یک اتصال را توصیف می‌کنند: تأخیر می‌گوید داده چقدر منتظر می‌ماند، پهنای باند چه مقدار می‌تواند جریان یابد، توان عملیاتی (throughput) چه مقدار واقعاً جریان می‌یابد، جیتر (jitter) تأخیر چقدر نوسان دارد و از دست رفتن بسته (packet loss) چه مقدار هرگز نمی‌رسد.

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

تفاوت پینگ و تأخیر چیست؟#

تأخیر خود انتظار است؛ پینگ ابزاری است که یک نوع از آن را اندازه می‌گیرد. فرمان ping درخواست‌های کوچک اکوی ICMP (echo request) می‌فرستد و زمان هر پاسخ اکو (echo reply) را می‌سنجد؛ ICMP پروتکل اینترنت برای پیام‌های کنترلی و خطاست. تست‌های سرعت این نام را قرض گرفته‌اند، پس «⁦Ping 12 ms⁩» یعنی تأخیر رفت‌وبرگشت 12 میلی‌ثانیه.

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

تأخیر را چگونه اندازه بگیریم؟#

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

اندازه‌گیری رفت‌وبرگشت با ping#

در ویندوز، در کادر Search (جست‌وجو) روی نوار وظیفه cmd را تایپ کنید، Command Prompt (خط فرمان) را باز کنید و این فرمان را اجرا کنید:

ping example.com

رایانه آزمایشی ما با ویندوز 11 در 15 نوامبر 2026 این خروجی را چاپ کرد:

Pinging example.com [104.20.23.154] with 32 bytes of data:
Reply from 104.20.23.154: bytes=32 time=11ms TTL=50
Reply from 104.20.23.154: bytes=32 time=10ms TTL=50
Reply from 104.20.23.154: bytes=32 time=12ms TTL=50
Reply from 104.20.23.154: bytes=32 time=11ms TTL=50

Ping statistics for 104.20.23.154:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 12ms, Average = 11ms

هر مقدار time= یک رفت‌وبرگشت است؛ مقدار Lost شمار بسته‌های گم‌شده را نشان می‌دهد و زیر Approximate round trip times کمترین، بیشترین و میانگین زمان‌ها آمده است. ویندوز به‌طور پیش‌فرض چهار درخواست می‌فرستد؛ -n 20 بیست درخواست می‌فرستد و -t تا زمانی که Ctrl+C را بزنید ادامه می‌دهد.

زمان‌ها کوتاه‌اند، چون example.com از طریق یک شبکه توزیع محتوا (CDN) ارائه می‌شود که از سروری نزدیک به بازدیدکننده پاسخ می‌دهد. در مک یا لینوکس، ping -c 4 example.com را در Terminal (ترمینال) اجرا کنید؛ بدون -c، فرمان ping تا زمانی که Control-C را بزنید ادامه می‌یابد.

دیدن اینکه زمان کجا صرف می‌شود با curl#

curl یک آدرس وب را دریافت می‌کند و با گزینه -w گزارش می‌دهد هر مرحله چقدر طول کشیده است. این ابزار همراه ویندوز 10 و 11، مک و بیشتر توزیع‌های لینوکس ارائه می‌شود. در Command Prompt (خط فرمان):

curl -o NUL -s -w "dns lookup:  %{time_namelookup}\nconnect:     %{time_connect}\ntls:         %{time_appconnect}\nfirst byte:  %{time_starttransfer}\ntotal:       %{time_total}\n" https://example.com

در مک یا لینوکس، به‌جای -o NUL بنویسید -o /dev/null و متن پس از -w را میان نقل‌قول‌های تکی (') بگذارید؛ در Windows PowerShell باید curl.exe را تایپ کنید، چون آنجا curl نام فرمان دیگری است. یکی از اجراهای ما این را چاپ کرد:

dns lookup:  0.005060
connect:     0.017101
tls:         0.036621
first byte:  0.056354
total:       0.056403

مقدارها بر حسب ثانیه‌اند و هر کدام از آغاز درخواست شمرده می‌شود، همان‌طور که راهنمای curl آن‌ها را تعریف می‌کند. هر سطر را از سطر بعدی کم کنید تا مدت یک مرحله را ببینید:

• جست‌وجوی DNS (dns lookup)، 5 میلی‌ثانیه. پیدا کردن آدرس؛ کوتاه است چون این نام همین چند لحظه پیش جست‌وجو شده بود.
• اتصال (connect)، 12 میلی‌ثانیه بیشتر. اتصال TCP، یعنی یک رفت‌وبرگشت، نزدیک به مقدار پینگ.
• دست‌دادن TLS (tls)، 20 میلی‌ثانیه بیشتر. مرحله‌ای که رمزگذاری را برای HTTPS برقرار می‌کند.
• نخستین بایت (first byte)، 20 میلی‌ثانیه بیشتر. درخواست، کار سرور و رسیدن نخستین بایت پاسخ.

از 56 میلی‌ثانیه، فقط 20 میلی‌ثانیه آخر صرف خود درخواست شد؛ بقیه صرف برقراری اتصال شد.

⁦p50⁩ و ⁦p95⁩: چرا یک اندازه‌گیری کافی نیست#

تأخیر از درخواستی به درخواست دیگر تغییر می‌کند، پس یک عدد به‌تنهایی چیز زیادی نمی‌گوید. ما همان درخواست curl را 20 بار اجرا کردیم و زمان‌های first byte را مرتب کردیم. میانه، یا ⁦p50⁩، برابر 70 میلی‌ثانیه بود: نیمی از درخواست‌ها سریع‌تر و نیمی کندتر بودند. ⁦p95⁩، یعنی مقداری که 95 درصد درخواست‌ها زیر آن می‌مانند، 91 میلی‌ثانیه بود؛ یعنی نوزدهمین مقدار از 20 مقدار مرتب‌شده. کندترین درخواست 199 میلی‌ثانیه طول کشید و میانگین را تا 76 میلی‌ثانیه بالا برد.

به همین دلیل ابزارهای پایش و هدف‌های عملکردی API از صدک‌ها (percentile) استفاده می‌کنند: ⁦p50⁩ حالت معمول را نشان می‌دهد و ⁦p95⁩ و ⁦p99⁩ نشان می‌دهند درخواست‌های کند تا چه حد کند می‌شوند.

تأخیر خوب چقدر است؟#

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

• تماس صوتی و تصویری. ⁦ITU-T G.114⁩ می‌گوید با تأخیر یک‌طرفه کمتر از 150 میلی‌ثانیه، بیشتر کاربردها، چه گفتاری و چه غیرگفتاری، تقریباً بی‌وقفه و تعاملی حس می‌شوند، و 400 میلی‌ثانیه یک‌طرفه را سقف برنامه‌ریزی شبکه می‌داند. این بودجه کل زنجیره از میکروفون تا بلندگو را در بر می‌گیرد، پس سهم شبکه باید کمتر باشد.
• صفحه‌های وب. راهنمای گوگل درباره زمان تا نخستین بایت (TTFB)، که همان لحظه first byte در curl است، 0.8 ثانیه یا کمتر را هدفی تقریبی برای بیشتر سایت‌ها می‌داند و بیش از 1.8 ثانیه را ضعیف می‌شمارد.
• APIها و سرویس‌های دیگر. استاندارد عمومی‌ای وجود ندارد. تیم‌ها هدف خود را به شکل یک صدک تعیین می‌کنند، مثلاً «⁦p95⁩ کمتر از تعداد مشخصی میلی‌ثانیه»، و وقتی از آن عقب بمانند هشدار می‌گیرند.
• ترمینال‌های معاملاتی، دسکتاپ از راه دور و برنامه‌های ابری. هرچه کمتر و پایدارتر، بهتر؛ جیتر به اندازه میانگین اهمیت دارد.

در غیر این صورت، پینگ را با سابقه خودتان مقایسه کنید: اگر سروری که دیروز در 11 میلی‌ثانیه پاسخ می‌داد امروز 60 میلی‌ثانیه طول می‌کشد، چیزی در مسیر تغییر کرده است.

چگونه تأخیر را کاهش دهیم؟#

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

1. برای دستگاه مهم از کابل استفاده کنید. کابل اترنت نوبت‌گیری و تلاش‌های دوباره Wi-Fi را از مسیر حذف می‌کند؛ در غیر این صورت به روتر نزدیک‌تر شوید.
2. خط را از آپلودهای سنگین خالی نگه دارید. پشتیبان‌گیری ابری و آپلودهای بزرگ صف را پر می‌کنند و تأخیر همه را بالا می‌برند. آن‌ها را هنگام تماس متوقف کنید، یا تنظیم اولویت‌بندی ترافیک را که بسیاری از روترها QoS (کیفیت خدمات) می‌نامند روشن کنید.
3. از سرورهای نزدیک به کاربران استفاده کنید. شبکه توزیع محتوا نسخه‌هایی از یک سایت را نزدیک بازدیدکنندگانش نگه می‌دارد، پس بیشتر درخواست‌ها مسیر کوتاهی را طی می‌کنند؛ نوشته ما درباره CDN طرز کار آن را توضیح می‌دهد.
4. حل‌کننده DNS خود را بررسی کنید. یک حل‌کننده کند هر نام تازه را به تأخیر می‌اندازد؛ اگر جست‌وجوی نام‌ها در همه سایت‌ها کند است، حل‌کننده دیگری می‌تواند کمک کند.
5. رفت‌وبرگشت‌های کمتری داشته باشید. keep-alive در HTTP درخواست‌ها را یکی پس از دیگری روی یک اتصال باز می‌فرستد، و ⁦HTTP/2⁩ که در ⁦RFC 9113⁩ تعریف شده، درخواست‌های زیادی را هم‌زمان روی یک اتصال واحد حمل می‌کند. وقتی curl صفحه example.com را دو بار روی یک اتصال دریافت کرد، درخواست دوم مراحل DNS، TCP و TLS را تکرار نکرد و نخستین بایت آن به‌جای 71 میلی‌ثانیه پس از 21 میلی‌ثانیه رسید.
6. به ارائه‌دهنده اینترنت مدرک بدهید. اگر تأخیر روی کابل و بدون هیچ فعالیت دیگری همچنان بالا می‌ماند، نتیجه‌های ping و traceroute را برای پشتیبانی بفرستید.

پروکسی چه اثری بر تأخیر دارد؟#

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

• خروجی‌ای سر راه انتخاب کنید، نه در مسیری انحرافی. هر درخواست از شما به پروکسی، از آنجا به سایت و سپس به عقب می‌رود. خروجی‌ای در کشور یا شهر سایت آخرین بخش مسیر را کوتاه نگه می‌دارد؛ خروجی‌ای در قاره‌ای سوم دو بخش طولانی به هر رفت‌وبرگشت اضافه می‌کند.
• اتصال‌ها را دوباره به کار ببرید. هر اتصال HTTPS تازه از طریق پروکسی مراحل برقراری را تکرار می‌کند: اتصال به پروکسی، تونل تا سایت و دست‌دادن TLS. keep-alive و ⁦HTTP/2⁩ این هزینه را یک بار می‌پردازند، و یک نشست ثابت همان خروجی را برای مدتی که انتخاب می‌کنید، از 1 تا 60 دقیقه، نگه می‌دارد.
• روی خطوط خانگی و موبایل انتظار نوسان بیشتری داشته باشید. خروجی‌های مسکونی و موبایل روی اتصال‌های واقعی کاربران خانگی قرار دارند، پس تأخیرشان بیش از خروجی‌هایی که در مراکز داده هستند نوسان دارد.

برای اندازه‌گیری، فرمان curl را با -x از طریق پروکسی اجرا کنید و نتیجه را با اجرای مستقیم مقایسه کنید:

curl -x http://user:pass@pr.proxynet.io:8000 -o NUL -s -w "connect: %{time_connect}  tls: %{time_appconnect}  first byte: %{time_starttransfer}\n" https://example.com

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

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

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

جاهایی که تأخیر اهمیت دارد#

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

خطاهای رایج#

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

راهنمای انتخاب#

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

تأخیر خوب برای اینترنت چقدر است؟#

به کاربرد بستگی دارد. برای تماس‌ها، ⁦ITU-T G.114⁩ می‌گوید بیشتر کاربردها با تأخیر یک‌طرفه سرتاسری کمتر از 150 میلی‌ثانیه تقریباً بی‌وقفه و تعاملی حس می‌شوند؛ پس پینگی بسیار پایین‌تر از آن برای دستگاه‌ها جا باقی می‌گذارد. برای صفحه‌های وب، گوگل زمان تا نخستین بایت 0.8 ثانیه یا کمتر را پیشنهاد می‌کند. مهم‌تر از همه، با مقدار پایه خودتان مقایسه کنید.

تأخیر پایین یعنی چه؟#

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

آیا پهنای باند بیشتر تأخیر را کم می‌کند؟#

معمولاً نه. پهنای باند تعیین می‌کند در هر ثانیه چه مقدار داده عبور کند؛ تأخیر از فاصله، مسیریابی، صف‌ها و سرور می‌آید. استثنا خطی است که اغلب پر است: آنجا ظرفیت اضافه صف‌ها را کوتاه‌تر می‌کند.

تأخیر بیکاری، دانلود و آپلود در تست سرعت چیست؟#

تأخیر بیکاری (Idle) پیش از آزمایش و هنگامی اندازه‌گیری می‌شود که خط آرام است. تأخیر دانلود و آپلود (Download و Upload) هنگامی اندازه‌گیری می‌شود که آزمایش خط را در هر جهت پر می‌کند. فاصله زیاد میان مقدار بیکاری و مقدارهای زیر بار نشانه bufferbloat است.

چرا تأخیر روی Wi-Fi بیشتر از کابل است؟#

Wi-Fi یک کانال رادیویی مشترک است: دستگاه‌ها به نوبت ارسال می‌کنند و فریم‌هایی را که بر اثر تداخل گم شده‌اند دوباره می‌فرستند، و این تأخیر را بیشتر و ناپایدار می‌کند. فاصله، دیوارها و شبکه‌های شلوغ همسایه وضع را بدتر می‌کنند؛ کابل این بخش از مسیر را حذف می‌کند.

آیا پروکسی یا VPN تأخیر را بیشتر می‌کند؟#

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

خلاصه#

تأخیر زمانی است که داده در راه منتظر می‌ماند و معمولاً به‌صورت رفت‌وبرگشت و بر حسب میلی‌ثانیه گزارش می‌شود. فاصله، مسیریابی، صف‌ها، Wi-Fi و سرور آن را می‌سازند و پهنای باند درمانش نیست. آن را با ping و curl -w اندازه بگیرید، به‌جای یک مقدار میانه و ⁦p95⁩ را بخوانید و با کابل، سرورهای نزدیک و رفت‌وبرگشت‌های کمتر کاهشش دهید. وقتی درخواست‌هایتان باید از کشور یا شهر خاصی خارج شوند، گزینه‌های خروجی را در صفحه محصولات پروکسی ما مقایسه کنید.