لایه‌های شبکه و Encapsulation

چرا لایه‌بندی مهم است؟

فرض کنید کاربری می‌گوید «سایت باز نمی‌شود». این یک علامت است، نه یک تشخیص. مشکل می‌تواند از هزار جا باشد: DNS جواب نمی‌دهد، مسیر شبکه قطع است، سرویس web خاموش است یا خود برنامه خطا می‌دهد. اگر بخواهید همه‌ی این حالت‌ها را هم‌زمان بررسی کنید، سردرگم می‌شوید.

راه‌حل این است که شبکه را به لایه‌ها تقسیم کنیم، هر کدام با مسئولیت مشخص خودش. وقتی لایه‌ها را بشناسید، عیب‌یابی از یک حدس شانسی تبدیل می‌شود به یک رشته پرسش منطقی: «DNS جواب می‌دهد؟ خب پس بعدی، TCP وصل می‌شود؟ اگر آری، HTTP چه پاسخی می‌دهد؟» همین ترتیب ساده، بخش زیادی از استرس عیب‌یابی را می‌گیرد.

دو مدل لایه‌بندی رایج‌اند:

• مدل هفت‌لایه‌ی OSI: Physical، Data Link، Network، Transport، Session، Presentation، Application
• مدل چهارلایه‌ی TCP/IP: Network Access (شبکه‌ی محلی)، Internet، Transport، Application

مدل OSI برای آموزش دقیق‌تر و کامل‌تر است، اما در عمل بیشتر با واژگان TCP/IP کار می‌کنیم؛ این جدول را برای مرجع نگه دارید:

Encapsulation

هر لایه داده‌ی لایه‌ی بالاتر را می‌گیرد و آن را در بسته‌بندی خودش می‌گذارد. هنگام ارسال، هر لایه یک سربرگ(Header) به داده اضافه می‌کند؛ در مقصد، همین هدرها یکی‌یکی و به‌ترتیب برداشته می‌شوند تا داده‌ی اصلی بیرون بیاید:

• داده‌ی برنامه (مثلاً یک درخواست از HTTP) به Segment تبدیل می‌شود؛ اینجا لایه‌ی Transport شماره‌ی پورت مبدأ و مقصد را اضافه می‌کند
• Segment درون Packet قرار می‌گیرد و لایه‌ی Internet آدرس IP مبدأ و مقصد را روی آن می‌گذارد
• در نهایت Packet درون Frame جا می‌گیرد؛ لایه‌ی Network Access آدرس MAC گام بعدی مسیر را اضافه می‌کند

این همان چیزی است که توضیح می‌دهد چرا هر ابزار عیب‌یابی فقط یک تکه از تصویر را می‌بیند: ping با لایه‌ی Internet سروکار دارد، ss با لایه‌ی Transport، و مرورگر تنها لایه‌ی Application را می‌بیند — بقیه‌اش برایش شفاف است.

عیب‌یابی لایه‌به‌لایه

وقتی چیزی خراب است، از پایین شروع کنید و بالا بروید؛ این ترتیب منطقی‌ترین راه برای پیدا کردن ریشه‌ی مشکل است:

1. Network Access — آیا کابل/شبکه‌ی مجازی وصل است؟ آیا IP دارید؟ (ip addr)
2. Internet — آیا مسیر تا مقصد باز است؟ (ping، traceroute)
3. Transport — آیا TCP روی آن پورت وصل می‌شود؟ (nc، ss)
4. Application — آیا سرویس خودش پاسخ درست می‌دهد؟ (curl -v)

این الگو را دوباره می‌بینید — درس پایانی همین هفته کاملاً حول همین چهار قدم می‌چرخد.

تمرین: دیدن یک درخواست در Browser DevTools

روی سیستم میزبان، مرورگر را باز کنید و F12 را بزنید تا DevTools باز شود. به تب Network بروید، این تب را باز نگه دارید و یک سایت ساده را بار کنید (رفرش صفحه هم کافی است). برای هر درخواست ستون‌هایی مثل Status، Type و Time می‌بینید؛ با کلیک روی یک درخواست جزئیات Headers هم باز می‌شود. این‌ها همه در سطح Application اتفاق افتاده‌اند — مرورگر از وجود لایه‌های پایین‌تر بی‌خبر است و فقط همین سطح را به شما نشان می‌دهد.

حالا همین درخواست را از زاویه‌ی لایه‌ی Internet ببینید. در VM، مسیر بسته‌ها تا همان دامنه را بررسی کنید:

1traceroute example.com

هر خط از خروجی یک Hop است — یعنی یک روتر در مسیر. traceroute نشان می‌دهد بسته‌ها در لایه‌ی Internet از کجاها رد می‌شوند تا به مقصد برسند؛ اگر traceroute روی سیستم شما نصب نبود، این دستور را اجرا کنید:

1sudo apt update && sudo apt install traceroute

تعداد Hopها را به خاطر بسپرید و دوباره به تب Network در مرورگر برگردید. حالا یک تناقض ظاهری را حل کنید: مرورگر درخواست را یک مسیر مستقیم نشان می‌دهد، در حالی که بسته باید از همه‌ی این Hopها عبور کند. چطور ممکن است؟ یادگیری همین مفهوم، دقیقاً همان مهارتی است که در درس پایانی هفته به کارتان می‌آید: مشکل واقعی معمولا در یک لایه‌ی مشخص است، نه در «همه‌جا».

منابع یادگیری

ویدیو

از سری Practical Networking — «How Data Moves Through the Internet» — این چهار قسمت مرتبط با این درس: