TTL در پینگ چیست و چطور از روی آن تعداد روترهای مسیر را حساب کنیم؟

وقتی با دستور ping وضعیت اتصال به یک سرور را بررسی می‌کنید، در کنار زمان پاسخ، عددی هم جلوی عبارت TTL دیده می‌شود. اما واقعاً TTL در پینگ چیست و چه چیزی را دربارۀ مسیر شبکه نشان می‌دهد؟ عبارت TTL کوتاه‌شدهٔ Time to Live (به معنای زمان حیات) است و در پروتکل IP مشخص می‌کند یک بستۀ اطلاعاتی حداکثر از چند روتر یا گام مسیریابی می‌تواند عبور کند. با رد شدن بسته از هر روتر، یک واحد از این شمارنده کم می‌شود و اگر پیش از رسیدن به مقصد به صفر برسد، روتر آن بسته را دور می‌ریزد. همین سازوکار ساده جلوی سرگردان ماندن همیشگی بسته‌ها را در زمان بروز خطاهای مسیریابی می‌گیرد.

پس اگر می‌خواهید بدانید در عمل TTL در پینگ چیست، کافی است به عدد پایان هر خط از خروجی پینگ (مثل ۶۴، ۱۱۷ یا ۱۲۸) نگاه کنید. این عدد، مقدار TTL باقی‌مانده در بستۀ پاسخ است و به ما کمک می‌کند تعداد روترهای مسیر برگشت را تخمین بزنیم. البته در پاسخ به این پرسش که «TTL چیست»، نباید این عدد را با زمان تأخیر شبکه (Time) اشتباه گرفت؛ «تی تی ال» هیچ ربطی به سرعت اینترنت یا کیفیت پینگ ندارد. در ادامه، شیوۀ کارکرد ttl در پینگ، فرمول محاسبۀ تعداد هاپ، روش تغییر آن در ویندوز و لینوکس و تفاوتش با TTL در DNS را بررسی می‌کنیم. با ما همراه باشید.

ttl در شبکه چگونه کار می‌کند؟

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

این گام‌ها چطور شمرده می‌شوند؟ در هدر بسته‌های IPv4 فیلدی ۸ بیتی به نام TTL وجود دارد که عددی بین ۰ تا ۲۵۵ می‌گیرد. دستگاه فرستنده، مقدار اولیه این فیلد را تعیین می‌کند و هر روتری که بسته را در مسیر جلو می‌فرستد، حداقل یک واحد از آن کم می‌کند (اگر پردازش بسته در روتر بیش از یک ثانیه طول بکشد، ممکن است بیش از یک واحد کسر شود). هرچند در روزهای آغازین طراحی شبکه قرار بود تی تی ال عمر زمانی بسته را برحسب ثانیه محدود کند، اما در شبکه‌های امروزی عملاً یک شمارندۀ معکوس برای محدود کردن تعداد هاپ‌های مجاز است.

برای اینکه کارکرد این شمارنده ملموس‌تر شود، بسته‌ای را در نظر بگیرید که با TTL اولیه ۶۴ ارسال شده است. اگر این بسته در راه رسیدن به مقصد از ۵ روتر عبور کند و هر روتر یک واحد از آن بکاهد، در لحظۀ تحویل به مقصد عدد ۵۹ را نشان می‌دهد. حالا فرض کنید به دلیل یک خطای مسیریابی، بسته در یک حلقه (Loop) بین دو یا چند روتر گیر بیفتد؛ در این وضعیت، عدد TTL در هر بار چرخش یکی‌یکی کم می‌شود تا به صفر برسد و روتر بسته را حذف کند. بدون این قابلیت، بسته‌های سرگردان می‌توانستند پهنای باند شبکه را به‌شدت درگیر کنند.

TTL در پینگ چیست و مقدار آن در خروجی چه می‌گوید؟

بیشتر کاربران هنگام کار با دستور ping با مفهوم TTL روبه‌رو می‌شوند. وقتی آدرسی را پینگ می‌کنید، سیستم شما یک پیام درخواست (ICMP Echo Request) به مقصد می‌فرستد و سرور مقصد هم در صورت برقراری ارتباط، با یک بستۀ پاسخ (ICMP Echo Reply) جواب می‌دهد. نکتۀ مهمی که در تحلیل خروجی پینگ باید به آن توجه کنید این است که عدد نمایش‌داده‌شده در مقابل TTL، مربوط به بستۀ پاسخِ برگشتی از سمت سرور است، نه بسته‌ای که سیستم شما در ابتدا فرستاده است.

خروجی دستور پینگ در محیط ویندوز معمولاً چنین شکلی دارد:

Reply from 8.8.8.8: bytes=32 time=20ms TTL=117

و در ترمینال لینوکس به این صورت نمایش داده می‌شود:

64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=20.0 ms

در هر دو نمونه، عبارت‌های Reply from و bytes from نشان می‌دهند که پاسخ از مقصد (در اینجا سرور DNS گوگل با آدرس 8.8.8.8) دریافت شده است. بخش bytes اندازۀ بسته، time زمان رفت‌وبرگشت برحسب میلی‌ثانیه و TTL=117 مقدار باقی‌مانده تی تی ال در لحظۀ رسیدن بسته به سیستم شماست.

هنگام خواندن این خروجی، دو باور رایج اما اشتباه را کنار بگذارید: اول اینکه عدد TTL در پینگ به‌تنهایی نوع سیستم‌عامل سرور یا تعداد دقیق روترها را با قطعیت مشخص نمی‌کند؛ دوم اینکه عدد بالاتر هرگز به معنای اینترنت سریع‌تر یا پینگ بهتر نیست. برای ارزیابی کیفیت واقعی اتصال باید معیارهایی مثل زمان پاسخ (Time)، نوسان تأخیر (Jitter) و درصد بسته‌های ازدست‌رفته (Packet Loss) را بررسی کنید که در مقالۀ «پینگ چیست» با جزئیات درباره آن‌ها صحبت کرده‌ایم.

فرمول محاسبۀ تعداد هاپ از روی TTL

همانطور که پیش‌تر گفتیم، عدد TTL به‌طور مستقیم تعداد روترها را نشان نمی‌دهد، اما اگر مقدار اولیۀ آن را در سرور مقصد بدانیم (یا حدس بزنیم)، به‌راحتی می‌توانیم حساب کنیم که بسته در مسیر برگشت از چند روتر گذشته است. فرمول محاسبه بسیار سرراست است:

تعداد هاپ = TTL اولیه − TTL دریافتی

در همان مثال پینگ گوگل، فرض کنید سرور مقصد بستۀ پاسخ را با مقدار اولیه ۱۲۸ ارسال کرده و سیستم شما عدد ۱۱۷ را در خروجی نشان داده است:

۱۲۸ − ۱۱۷ = ۱۱

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

مقادیر پیش‌فرض TTL در سیستم‌عامل‌ها و تجهیزات

در فرمول بالا یک سؤال باقی می‌ماند: از کجا بفهمیم سرور مقصد بسته را با چه TTL اولیه‌ای فرستاده است؟ هر سیستم‌عامل یا تجهیز شبکه‌ای، به‌طور پیش‌فرض از یک عدد مشخص برای ارسال بسته‌ها استفاده می‌کند که رایج‌ترین آن‌ها را در جدول زیر می‌بینید:

سیستم‌عامل یا تجهیز شبکه	مقدار پیش‌فرض TTL
ویندوز (Windows)	۱۲۸
لینوکس (Linux)	۶۴
مک (macOS)	۶۴
اندروید (Android)	۶۴
برخی تجهیزات شبکه (مانند روترهای سیسکو – Cisco IOS)	۲۵۵

برای تخمین مقدار اولیه، کافی است عدد TTL دریافتی در پینگ را با سه عدد استاندارد ۶۴، ۱۲۸ و ۲۵۵ مقایسه کنید و نزدیک‌ترین عدد بزرگ‌تر را مبنا قرار دهید. مثلاً اگر در خروجی پینگ عدد ۵۴ را دیدید، نزدیک‌ترین سقف استاندارد به آن ۶۴ است؛ پس مقدار اولیه احتمالاً ۶۴ بوده و بسته در راه برگشت از ۱۰ روتر (۱۰ = ۵۴ − ۶۴) عبور کرده است. به همین ترتیب، برای عدد ۱۱۷ مقدار اولیه را ۱۲۸ و برای اعداد بالاتر از ۱۲۸، مقدار اولیه را ۲۵۵ در نظر می‌گیریم.

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

شیوۀ تغییر و تنظیم TTL در ویندوز و لینوکس

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

تغییر تی تی ال پینگ در ویندوز

در محیط Command Prompt ویندوز، برای تعیین TTL بسته ارسالی از پارامتر «/i» استفاده می‌شود (که عددی تا حداکثر ۲۵۵ می‌گیرد). برای نمونه، دستور زیر یک پینگ با TTL اولیه ۵ به سمت آدرس 8.8.8.8 می‌فرستد:

ping /i 5 8.8.8.8

با اجرای این دستور، بسته فقط اجازۀ عبور از ۵ روتر را دارد و اگر مقصد دورتر باشد، در میانۀ راه حذف می‌شود. برای مشاهدۀ فهرست کامل پارامترهای پینگ در ویندوز می‌توانید فرمان زیر را وارد کنید:

ping /?

تغییر ttl پینگ در لینوکس

در ابزار iputils لینوکس، همین کار با سوییچ -t انجام می‌شود. دستور زیر بسته‌ای با TTL برابر ۵ را در ترمینال لینوکس ارسال می‌کند:

ping -t 5 8.8.8.8

توجه داشته باشید که در ویندوز سوییچ -t برای پینگ ممتد به کار می‌رود، اما در لینوکس وظیفۀ تنظیم Time to Live را بر عهده دارد. اگر می‌خواهید جزئیات کامل‌تر این ابزار را در توزیع لینوکس خود ببینید، راهنمای آن را با دستور زیر باز کنید:

man ping

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

سیستم‌عامل	دستور نمونه	کاربرد
ویندوز	ping /i 5 8.8.8.8	ارسال درخواست پینگ با TTL برابر ۵
لینوکس	ping -t 5 8.8.8.8	ارسال درخواست پینگ با TTL برابر ۵

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

خطای TTL Exceeded چیست و چه ارتباطی با traceroute دارد؟

اگر دستور بخش قبل را با TTL برابر ۵ اجرا کرده باشید، به احتمال زیاد به جای دریافت پاسخ از سرور گوگل، با خطای TTL Exceeded روبه‌رو می‌شوید. این پیام زمانی ظاهر می‌شود که شمارندۀ تی تی ال در میانۀ راه به صفر برسد؛ در این لحظه، آخرین روتر بسته را دور می‌ریزد و یک پیام خطای ICMP Time Exceeded به سیستم شما برمی‌گرداند تا اعلام کند بسته به مقصد نرسیده است.

این پیام در ویندوز به شکل زیر دیده می‌شود:

TTL expired in transit.

و در لینوکس معمولاً عبارتی شبیه به خط زیر نمایش داده می‌شود (آدرس IP ابتدای خط، آدرس همان روتری است که بسته در آن متوقف شده است):

From 192.0.2.1 icmp_seq=1 Time to live exceeded

بنابراین دیدن این پیام همیشه به معنای قطع بودن اینترنت یا از کار افتادن سرور مقصد نیست، بلکه می‌گوید سقف ttl برای طی کردن تمام روترهای مسیر کافی نبوده است (یا بسته در یک حلقه مسیریابی گیر افتاده و تمام اعتبار TTL خود را از دست داده است).

نکتۀ جالب اینجاست که ابزار پرکاربرد traceroute دقیقاً از همین خطا برای شناسایی روترهای مسیر استفاده می‌کند. وقتی این ابزار را اجرا می‌کنید، ابتدا بسته‌ای با TTL=1 می‌فرستد؛ یعنی روتر اول یک واحد از آن کم می‌کند، عدد به صفر می‌رسد و با ارسال پیام خطای Time Exceeded، آدرس IP خود را لو می‌دهد. در گام بعد، ابزار بسته‌ای با TTL=2 می‌فرستد تا روتر دوم را شناسایی کند و این روند را آن‌قدر ادامه می‌دهد تا به سرور مقصد برسد.

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

tracert 8.8.8.8

و در لینوکس فرمان زیر را وارد کنید:

traceroute 8.8.8.8

اگر در خروجی این دستورات، جلوی بعضی از گام‌ها به جای آدرس IP علامت ستاره (*) دیدید، به معنی قطع بودن مسیر نیست. بسیاری از روترها به دلایل امنیتی پاسخ‌های ICMP را مسدود یا محدود می‌کنند، اما بسته‌های عادی شبکه را بدون هیچ مشکلی از خود عبور می‌دهند.

در سطح پیشرفته‌تر، مدیران شبکه روی تجهیزات سیسکو (Cisco) علاوه بر اجرای traceroute، از دستور show ip route 8.8.8.8 هم برای بررسی مسیر انتخاب‌شده توسط روتر استفاده می‌کنند. همچنین در شبکه‌های سرویس‌دهنده که بر پایۀ پروتکل MPLS کار می‌کنند، گاهی انتشار TTL غیرفعال می‌شود تا روترهای هستۀ شبکه در خروجی traceroute پنهان بمانند؛ به همین دلیل تعداد هاپ‌های نمایش‌داده‌شده همیشه با تعداد واقعی تمام تجهیزات عبوری برابر نیست.

تفاوت ttl در پروتکل IPv4 و IPv6

حالا که با مفهوم «TTL در پینگ چیست» به طور کامل آشنا شدیم و همان‌طور که در ابتدا دیدیم، در پروتکل IPv4 این فیلد ۸ بیتی با نام قدیمی TTL شناخته می‌شود که در عمل تعداد گام‌های مسیریابی را محدود می‌کند. در نسل جدیدتر یعنی پروتکل IPv6، طراحان شبکه نام این فیلد را به عبارت دقیق‌ترِ Hop Limit (محدودیت گام) تغییر دادند. در مسیرهای مبتنی بر روتر IPv6، هر گره مسیریاب دقیقاً یک واحد از مقدار Hop Limit کم می‌کند و با رسیدن آن به صفر، بسته حذف می‌شود.

ویژگی	پروتکل IPv4	پروتکل IPv6
نام فیلد در هدر	TTL (Time to Live)	Hop Limit
اندازۀ فیلد	۸ بیت	۸ بیت
حداکثر مقدار مجاز	۲۵۵	۲۵۵
نحوۀ کاهش در هر روتر	حداقل ۱ واحد	دقیقاً ۱ واحد
کاربرد اصلی	محدود کردن تعداد عبور بسته از روترها	محدود کردن تعداد عبور بسته از روترها

تفاوت TTL در پینگ با TTL در DNS

یکی از مواردی که اغلب باعث سردرگمی می‌شود، تشابه اسمی میان TTL در پینگ و تی تی ال در سرویس DNS است. هر دو عبارت مخفف Time to Live هستند، اما در دو بخش کاملاً متفاوت کار می‌کنند. در بستۀ IP، عدد TTL مشخص می‌کند بسته از چند روتر می‌تواند عبور کند؛ درحالی‌که در DNS، مقدار TTL تعیین می‌کند اطلاعات یک رکورد تا چند ثانیه در حافظۀ کش (Cache) معتبر بماند (برای آشنایی با سازوکار تبدیل نام دامنه به IP، مقالۀ DNS چیست را مطالعه کنید).

برای مثال، وقتی TTL یک رکورد DNS روی ۳۶۰۰ ثانیه تنظیم می‌شود، یعنی سرورهای Resolver می‌توانند پاسخ آن استعلام را تا یک ساعت در کش خود نگه دارند و در این مدت، برای هر بار باز شدن سایت دوباره سراغ سرور اصلی نروند.

ویژگی	TTL در پینگ (شبکه)	TTL در DNS
کاربرد اصلی	محدود کردن عبور بسته IP از روترها	تعیین مدت اعتبار اطلاعات در حافظۀ کش
واحد عملکرد در عمل	تعداد هاپ (روتر)	ثانیه
محل قرارگیری	هدر بسته IP	رکوردهای DNS (مانند A یا MX رکورد)
هدف	جلوگیری از گردش بی‌پایان بسته‌ها در شبکه	کنترل زمان نگهداری و به‌روزرسانی اطلاعات دامنه

شناخت این تفاوت در مدیریت زیرساخت اهمیت زیادی دارد. مثلاً TTL تنظیم‌شده روی یک MX رکورد فقط مشخص می‌کند اطلاعات سرور ایمیل چقدر در کش DNS بماند و هیچ ارتباطی با TTL بستۀ پاسخ در دستور ping ندارد. یا در وب‌سایت‌هایی که از شبکۀ CDN استفاده می‌کنند، TTL رکورد DNS مشخص می‌کند پس از تغییر آدرس IP سرور، چقدر طول می‌کشد تا Resolverها کش قبلی را کنار بگذارند و ترافیک را به سرور جدید بفرستند؛ بنابراین تغییر DNS در تمام شبکه‌ها هم‌زمان اعمال نمی‌شود.

به‌عنوان نکتۀ پایانی در عیب‌یابی سرویس‌ها، به یاد داشته باشید که پینگ موفق یک سرور و دریافت عدد TTL، فقط نشان می‌دهد مقصد در لایۀ شبکه (پروتکل ICMP) روشن است و پاسخ می‌دهد؛ اما فعال بودن پورت سرویس یا سلامت وب‌سرور و API را تضمین نمی‌کند. اگر می‌خواهید از کارکرد درست یک API مبتنی بر HTTPS مطمئن شوید، به جای اکتفا به پینگ، یک درخواست واقعی به پورت ۴۴۳ بفرستید و کد وضعیت HTTP را بررسی کنید (دامنه نمونه را با آدرس واقعی جایگزین کنید):

curl -i https://api.example.com/health

اگر پینگ سرور بدون مشکل برقرار بود اما دستور بالا خطا برگرداند، باید سراغ بررسی وب‌سرور، خود برنامه، گواهی TLS یا تنظیمات فایروال بروید.

کلام آخر

بررسی عدد TTL در خروجی پینگ، دید خوبی دربارۀ مسیر حرکت بسته‌های IP به ما می‌دهد و کمک می‌کند با مقایسۀ عدد دریافتی با مقادیر پیش‌فرض (۶۴، ۱۲۸ یا ۲۵۵)، تعداد روترهای مسیر برگشت را تخمین بزنیم. با این حال، از آنجا که این عدد یک مقدار تخمینی است و ارتباطی با سرعت اینترنت ندارد، برای عیب‌یابی دقیق شبکه همیشه باید آن را در کنار خروجی traceroute، زمان پاسخ (Time) و میزان Packet Loss قرار دهید.

همچنین هنگام بررسی اختلال در یک سرویس، مرز میان مفاهیم مختلف را در نظر بگیرید و TTL بسته IP، زمان کش در رکوردهای DNS و وضعیت پورت‌های برنامه را جداگانه بررسی کنید. اگر می‌خواهید با روش‌های عملی تست اتصال سرور بیشتر آشنا شوید، مطالعه مقاله «آموزش Ping گرفتن» گام بعدی مناسبی خواهد بود.

سوالات متداول

TTL در پینگ مخفف چیست؟

مقدار TTL در پینگ چند باید باشد؟

آیا TTL تعداد روترهای مسیر را نشان می‌دهد؟

علت نمایش پیام TTL expired in transit چیست؟

تفاوت TTL و Hop Limit چیست؟

آیا TTL بالاتر نشان‌دهنده اینترنت سریع‌تر است؟