کپسوله سازی در شبکه

کپسوله سازی در شبکه – آموزش شبکه درس 11

کپسوله سازی در شبکه

یک لحظه این مورد را بررسی کنید، که چه اتفاقی می افتد اگر  یک برنامه یک پیام را به همتای خود به وسیله پاس دادن پیام در قالب پروتکل درخواست پاسخ (RRP) ارسال کند. از چشم انداز پروتکل درخواست پاسخ (RRP)، این پیام که به وسیله نرم افزار ارسال شده است، یک پیام تفسیر نشده متشکل از بایت های اطلاعاتی است. پروتکل درخواست پاسخ (RRP) هیچ تلاش و مراقبتی در زمینه اینکه پیام ها را در قالب آرایه ای از اعداد صحیح، یک پیام ایمیل، یک تصویر دیجیتالی و یا هر چیز دیگر باشد، نمی کند؛ آن به سادگی اقدام به ارسال این پیام به همتای خودش می کند. هرچند، پروتکل درخواست پاسخ (RRP) باید به بررسی و کنترل اطلاعات ارتباطی با همتای خود کند، و به او دستور دهد که چطور در زمان دریافت با پیام ها برخورد کند. پروتکل درخواست پاسخ (RRP) این کار را به وسیله ملحق کردن یک هدر (Header) به پیام انجام می دهد. به صورت کلی،یک هدر یک ساختار داده کوچک است، که از چند بیت و یا چند بایت ساخته شده است، که در میان همتایان به کار می رود تا بتوانند با همدیگر ارتباط برقرار کنند. همانطور که از نام این موضوع پیداست، هدرها، به صورت معمول به ابتدای یک پیام می چسبند. هرچند، در برخی از موارد،  اطلاعات کنترلی همتا به همتا، در انتهای پیام ارسال می شوند، که در این مورد به آن دنباله (Trailer) می گویند. فرمت دقیق هدر در پروتکل درخواست پاسخ (RRP)  به وسیله تعریف پروتکل آن تعیین می شود. بقیه پیام،  یعنی داده هایی که به وسیله نرم افزار منتقل می شوند، به عنوان بدنه (Body) یا بار (Payload) پیام شناخته می شوند. ما در اینجا می گوئیم که داده های نرم افزار در پیام تازه ای که به وسیله پروتکل درخواست پاسخ (RRP) ساخته شده اند، کپسوله شده اند.

کپسوله سازی در شبکه

تصویر 1.12 نشان دهنده پیامها سطح بالا هستند که در درون پیامهای سطح پائین تر کپسوله شده اند.

فرایند کپسوله سازی (Encapsulation) در هر سطح از گراف پروتکل تکرار می شود، برای مثال HHP پیامهای پروتکل RRP را به وسیله اضافه کردن هدرهای خودش به آنها کپسوله می کند. اگر ما اکنون فرض کنیم که HHP یک پیام را به همتای خودش در چند شبکه دیگر بفرستد، پس در زمانی که پیام بههاست مقصد برسد، آن به ترتیبی مخالف در اینجا پردازش می شود: HHP در ابتدا هدر  HHP که در ابتدای پیام است (که به او می گوید چه اقدامی را متناسب با محتوای پیام انجام دهد) را تفسیر می کند، و سپس بدنه پیام (بدون هدر HHP) را به RRP پاس می دهد، در این بخش نیز RRP اقدام به تفسیر هدر مخصوص RRP می کند و سپس بدنه پیام را بدون هدر  RRP به نرم افزار درخواست دهنده ارسال می کند. پیامی که از طرق RRP به نرم افزار درهاست دوم پاس داده می شود که دقیقا همان پیامی است که نرم افزار در هاست اول به پروتکل درخواست پاسخ (RRP) ارائه داده بود؛ اپلیکیشن هایی که در دو سوی این ارتباط قرار گرفته اند، هیچکدام نمی توانند هدرهایی که به پیام چسبیده اند را ببینند،  زیرا آنها در سرویسهای ارتباطاتی سطح پائین تر به کار گرفته می شوند. این فرایند به صورت کامل در تصویر 1.12 نمایش داده شده است. توجه کنید که در این مثال، گره هایی که در شبکه وجود داشته اند (مانند سوئیچها و روترها) ممکن است که هدر HHP در ابتدای هر پیام را بررسی کنند.

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

اگر پرسش یا پیشنهادی درباره این پست داشتید، می توانید آن را در پایین همین پست، برای ما کامنت کنید، ما در سریع ترین زمان ممکن به تمامی آنها پاسخ خواهیم داد.

No votes yet.
Please wait...

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

منو اصلی

question