3.فصل اول - درس دوم : نگاهی بر مدل TCP/IP

مدل TCP/IP بیان کننده ی مفاهیم و پروتکل هایی می باشد که برای برقراری ارتباط بین دستگاه ها مورد استفاده قرار میگیرند. مدل TCP/IP برای تعریف یک پروتکل از سندی تحت عنوان Request For Comments (RFC) استفاده می کند.(در رابطه با هر پروتکلی که در این دوره صحبت می کنیم میتوانید اطلاعات کاملتر و دقیق تری را با استفاده از RFC مربوط به آن پروتکل پیدا کنید.) همچنین مدل TCP/IP از تکرار مفاهیمی که توسط پروتکل ها یا گروه های دیگری ارائه شده اند جلوگیری می کند. در نتیجه هیچ تکراری در مفاهیم و پروتکل ها با کمک مدل TCP/IP وجود ندارد. به عنوان مثال سازمان Institute of Electrical and Electronic Engineers (IEEE) مفهوم Ethernet LAN را بیان کرده است، در نتیجه مدل TCP/IP هیچ RFC ای که Ethernet LAN را توضیح دهد ایجاد نکرده اما برای مطالعه ی دقیق این مفهوم شما را ارجاع می دهد به IEEE.

یک مثال ساده برای بوجود آمدن TCP/IP می تواند تلفن های خانگی شما باشد. به عنوان مثال شما به فروشگاهی می روید و یک تلفن جدید خریداری می کنید به خانه می آورید و همان کابل تلفنی که به تلفن قدیمی شما متصل است را به تلفن جدید متصل می کنید و این تلفن جدید بدون هیچ اشکالی کار می کند. دلیل این موضوع چیست؟ واضح است که سازندگان تمامی تلفن ها از یک اصول و استاندارد یکسان پیروی می کنند در نتیجه تمامی تلفن ها با کابل های یکسان تلفن می توانند کار کنند.

همانند تلفن ها در دنیای شبکه و کامپیوتر نیز اینگونه می باشد. زمانی که شما یک کامپیوتر جدید خریداری می کنید این کامپیوتر براساس مدل TCP/IP ساخته شده است درنتیجه فقط کافیست آن را از جعبه خارج کنید به برق متصل کنید و کابل Ethernet خود را به کامپیوتر متصل کنید و در نهایت کامپیوتر به شبکه و اینترنت متصل می شود. اما چگونه؟ به این صورت که بر روی سیستم عامل کامپیوتر مفاهیم شبکه بر اساس مدل TCP/IP تعریف شده اند. همچنین کارت شبکه ی کامپیوتر شما براساس همین استاندارد و مدل طراحی شده در نتیجه با همان کابل قدیمی Ethernet می تواند به شبکه متصل شود.

برای درک راحتتر مدل TCP/IP، این مدل را به بخش های کوچکتری تقسیم کردند که به هربخش می گوییم یک لایه (Layer). هر لایه شامل پروتکل ها و استاندارد هایی می باشد که یکسری مفاهیم و عملکرد را توضیح میدهند. در واقعیت مدل TCP/IP دو نوع دارد، یک نوع قدیمی و اورجینال و یک نوع بروز شده، همانند شکل زیر:

دو نوع مدل TCP/IP

مدل سمت چپ مدل اورجینال TCP/IP می باشد که RFC شماره ی 1122 به این مدل پرداخته است. این نوع مدل، TCP/IP را به چهار لایه قسمت کرده است. دو لایه ی بالایی تمرکز بیشتری بر روی برنامه های کاربردی دارند که برای ارسال و دریافت دیتا مورد نیاز می باشند. لایه های پایینی با کمک لایه ی Internet تمرکز بیشتری بر روی نحوه ی ارسال دیتا بصورت یکپارچه در سرار شبکه و تبدیل دیتا ها به Bit و سپس ارسال آنها بر روی لینک های فیزیکی دارند. 
مدل TCP/IP سمت راست مدلی معروفی می باشد که امروزه مورد استفاده قرار میگیرد و لایه هایی که در مدل اورجینال وجود دارند با تغییر نام و جزئیات بیشتری در این مدل قرار گرفته اند. همچنین لایه ی Link که در مدل اورجینال وجود دارد به دولایه ی Data Link و Physical در مدل جدیدتر و بروز شده تقسیم شده است.

توجه – لایه ی Link در مدل اورجینال TCP/IP همچنین با عنوان network access و network interface نیز شناخته می شود.

 

ممکن است خیلی از پروتکل هایی که مدل TCP/IP آنها را تعریف می کند بشناسید و در رابطه با آنها چیز هایی شنیده باشید. در لیست زیر یکسری از پروتکل هایی که مدل TCP/IP به معرفی آنها می پردازد قرار گرفته اند. بیشتر پروتکل هایی که در لیست زیر قرار دارند در ادامه بصورت جزئی تر مورد بررسی قرار خواهند گرفت. لیست زیر اجازه می دهد تا نگاهی نزدیک تر به مدل TCP/IP داشته باشید:

جدول 1-1 مدل TCP/IP و مثالی از پروتکل های موجود در هر لایه

لایه Application در مدل TCP/IP

پروتکل و سرویس هایی که در لایه ی Application مدل TCP/IP وجود دارند خدمات نرم افزاری سرویس هایی که کاربر از آنها استفاده می کنند را ارائه می دهند. لایه ی Application تعریف یک برنامه کاربردی را ارائه نمی دهد، اما مفاهیم و سرویس هایی را را ارائه می دهد که برنامه های کاربردی به آنها نیاز دارند. به عنوان مثال پروتکل HTTP که در لایه ی Application فعالیت دارد، این امکان را فراهم می کند که مروگر ها اطلاعات صفحات WEB را از WEB-SERVER دریافت کنند. اگر بخواهیم تعریف ساده ای از لایه ی Application داشته باشیم می توانیم اینگونه بیان کنیم که، لایه ی Application یک ارتباط بین برنامه های کاربردی با شبکه برقرار می کند.

قطعا امروزه یکی از معروف ترین برنامه های لایه ی Application مدل TCP/IP، مرورگر وب می باشد. بنابراین به دور از ذهن نمی باشد که تمامی سازندگان برنامه ها و سرویس ها، برنامه های خود را امروزه به گونه ای طراحی می کنند تا بتوانند از مرورگر وب پشتیبانی کنند. باید یک تشکر بزرگ از مرورگر وب به عمل بیاریم چرا که امروزه مرورگر وب را بر روی کامپیوتر خود باز میکنیم آدرس وبسایت مورد نظرمان را تایپ می کنیم و در نهایت اطلاعات وبسایت مورد نظر نمایان می شود.

نگاهی بر پروتکل HTTP

آیا تابحال به این فکر کرده اید که دقیقا چه چیزی این امکان را فراهم می آورد که اطلاعات یک صفحه ی وب بر روی مرورگر شما نمایان شود؟
تصور کنید باب مرورگر کامپیوتر خود را باز کند. مرورگر باب به گونه ای پیکربندی شده است که بصورت پیش فرض اطلاعات مربوط به صفحه ی پیش فرض وب آلیس را درخواست کند. مفاهیم منطقی همانند تصویر زیر به نظر می رسند.

تصویر 1-2  مفاهیم پایه ای لایه Application برای باز کردن یک صفحه ی وب

به نظر شما دقیقا چه اتفاقی افتاد؟ در ابتدا باب یک پیام درخواست به به سمت آلیس ارسال می کند و این درخواست مبنی بر این می باشد که،آلیس صفحه ی پیش فرض وب خودت را برایم ارسال کن. نرم افزار موجود بر روی WEB Server آلیس اینگونه پیکربندی شده که می داند صفحه ی پیش فرض، صفحه ی وبی می باشد که به عنوان Home.htm در داخل سرور وجود دارد. سپس آلیس این صفحه را برای باب ارسال می کند. در نهایت باب این صفحه دریافت کرده و اطلاعات مربوط به صفحه ی وب پیش فرض آلیس را می تواند مشاهده کند.

مکانیزم پروتکل HTTP

بیاید باهم یک مقدار جزئی تر به این مسئله نگاه کنیم، مثال قبل بیان کننده ی این می باشد که چگونه یک برنامه،خصوصا برنامه ی مرورگر وب و سرور وب از پروتکل لایه ی Application مدل TCP/IP استفاده می کند. برای تکمیل این فرایند یعنی درخواست یک صفحه ی وب از سرور وب و دریافت و مشاهده ی آن برنامه ها از پروتکل Hypertext Transfer Protocol (HTTP) استفاده می کنند.

HTTP اوایل سال 1990 میلادی توسط Tim Berners-Lee که اولین مرورگر وب و سرور وب را بوجود آورد، ایجاد شد. Berners پروتکل HTTP را به گونه ای طراحی کرد تا محتویاتی که در یک سرور وب وجود دارند توسط یک مرورگر وب درخواست شوند و در مقابل سرور وب آن اطلاعات را به سمت مروگر ارسال کند. دقیقا همان مفاهیمی که در تصویر 1-2 وجود دارد. تصویر 2-2 همان ایده را نمایش می دهد اما به جزئیات بیشتری در رابطه با پروتکل HTTP.

تصویر 2-2  پیام های HTTP Get Request, HTTP Reply و پیام حاوی اطلاعات

در قدم اول هنگامی که باب میخواهد از آلیس یک صفحه ی وب را دریافت کند، یک پیام حاوی هدر HTTP به سمت آلیس ارسال می کند. بصورت کلی پروتکل ها از Header ها به عنوان فضایی که اطلاعات مربوط به همان پروتکل را حمل می کنند استفاده می کنند. این Header حاوی درخواست Get یا همان گرفتن فایل و اطلاعات می باشد. این درخواست Get عموما به همراه نام فایل می باشد به عنوان نمونه در این مثال home.htm. اما ممکن به هیچ نامی اشاره نشود در آن صورت سرور وب فرض می کند که درخواست دهنده صفحه ی پیش فرض را نیاز دارد.
 
قدم دوم پاسخ سرور وب از سمت آلیس را توضیح می دهد.این پیام با هدر HTTP با کد شماره ی 200 شروع می شود. به این معنی که در خواست را تایید می کند. پروتکل HTTP کد های دیگری را نیز تعریف می کند که در شرایط متفاوتی ارسال می شوند. ( برای نمونه زمانیکه یک مرورگر درخواست اطلاعاتی را دارد که آن اطلاعات در داخل سرور وب موجود نمی باشد، سرور پیام را با کد 404 "فایل مورد نظر پیدا نشد" به سمت مرورگر ارسال می کند.) قسمت دوم پیام حاوی همان پیام درخواستی می باشد که باب ارسال کرده است و سرور وب با اینکار دارد تایید می کند که صفحه ی وب را به سمت باب ارسال خواهد کرد.
قدم سوم در تصویر 2-2 نشان می دهد که آلیس پیامی را که حاوی Home.htm می باشد را به سمت باب ارسال می کند اما در این پیام هدر HTTP وجود ندارد. دلیل این موضوع این می باشد که یک سرور وب اطلاعات درخواستی را طی چندین پیام پشت سر هم ارسال می کند و برای جلوگیری از تکرار فقط یکبار هدر HTTP را که حاوی کدی مشخص می باشد ارسال می کند.
 
لایه ی Transport در مدل TCP/IP
 
در حالی که لایه Internet مسئول مسیریابی منطقی بین شبکه ها است ، لایه Transport مسئولیت مسیریابی منطقی بین دو Host در شبکه های مختلف را بر عهده دارد. پروتکل های لایه ی Transport یک ارتباط منطقی با لایه ی بالاتر یعنی Application برقرار می کنند و سرویس هایی که برای لایه ی Application مورد نیاز می باشد را ارائه می دهند.  از دیدگاهی دیگر لایه ی Transport یک رابط بین لایه های پایین تر با لایه ی Application می باشد تا این تضمین را در رابطه با نحوه ی تحویل دیتا ها ارائه دهد.
 
در لایه ی Application پروتکلهای زیادی موجود می باشد که طی این دوره تعدادی از آنها را بررسی خواهیم کرد اما در لایه ی Transport تعداد پروتکل های کمتری موجود می باشد. دوتا از مهمترین پروتکل ها و سرویس هایی که لایه ی Transport ارائه می دهد پروتکلهای Transmission Control Protocol (TCP) و User Datagram Protocol (UDP) می باشند.
چگونه پروتکل هایی که در لایه ی Transport قرار دارند سرویس های لایه ی بالاتر از خودشان را ارائه می دهند؟ در این بخش می پردازیم به تمامی این مفاهیم با تمرکز بر روی پروتکل های TCP و UDP.
 
Transmission Control Protocol (TCP)
 
پروتکل Transmission Control Protocol و یا همان TCP یکی از پروتکل های لایه ی Transport می باشد. این پروتکل تحت عنوان یک پروتکل قابل اطمینان و یا Reliable شناخته می شود. پروتکل TCP یک پروتکل استاندارد می باشد که در RFC 793 شرح داده شده است. وظیفه ی اصلی این پروتکل ایجاد و نگهداری یک ارتباط برای تبادل دیتا بین دو Host می باشد. TCP برای برقراری ارتباط و اینکه چگونه یک پکت از Host به Host دیگر ارسال شود از پروتکل IP استفاده می کند. به عبارت دیگر TCP یک ارتباط نقطه به نقطه (Point-to-Point) را فراهم می کند.
یک ارتباط نقطه به نقطه بیان کننده ی دو مفهوم اصلی می باشد:
 
    • تنها یک مسیر برای رسیدن به مقصد وجود دارد. پکتی که وارد یک ارتباط P2P می شود امکان گم شود چرا که تنها یک مسیر وجود دارد و آنهم در نهایت به مقصد        می رسد.
    • پکت ها به همان ترتیبی که وارد می شوند ارسال می شوند.
 
نکته ای که وجود دارد این است که در ظاهر TCP یک ارتصال نقطه به نقطه را فراهم می کند اما در واقعیت چنین ارتباطی وجود ندارد. پروتکل TCP برای ایجاد یک اتصال نقطه به نقطه از مفهومی تحت عنوان TCP Three-Way Handshake استفاده می کند.
 
TCP Three-Way Handshake
 
TCP برای اینکه بتواند یک ارتباط نقطه به نقطه بین دو Host برقرار کند از پیام های زیر استفاده می کند.
 
    • Synchronization (SYN)
    • Acknowledgement, Synchronization (SYN, ACK)
    • Acknowledgment (ACK)
 
زمانی که قرار است بین دو Host توسط TCP یک ارتباط نقطه به نقطه برقرار شود و دیتاها بر روی این ارتباط ارسال شوند، Host ای که قصد ارسال دیتا را دارد شروع کننده ی این ارتباط نقطه به نقطه خواهد بود. شروع کننده ابتدا یک پیام SYN به سمت Host مقابل ارسال می کند با این عنوان که می خواهد یک ارتباط نقطه به نقطه ی TCP با Host دریافت کننده ی SYN داشته باشد. زمانی که Host مقابل پیام SYN را دریافت کرد اگر بخواهد موافقت خود را در رابطه با برقراری این ارتباط اعلام کند از پیام SYN, ACK استفاده می کند. در نهایت شروع کننده ی فرایند TCP زمانی که پیام SYN, ACK را دریافت کند در مقابل آن یک پیام ACK ارسال می کند و ارتباط نقطه به نقطه ی TCP برقرار می شود. برای درک بهتر این به تصویر 3-2 دقت کنید.
 
تصویر 3-2  TCP Three Way Handshake
 

دلیل اینکه پروتکل TCP یک پروتکل قابل اطمینان تلقی می شود این است که شخصا بررسی می کند پکت هایی که ارسال شده اند آیا همگی تحویل مقصد داده شده اند؟ (ممکن  است برخی پکت ها در مسیر از بین بروند و به مقصد تحویل داده نشوند) اگر بسته ای در بین مسیر گم شود و تحویل مقصد داده نشود TCP امکان ارسال دوباره ی پکت هایی که به مقصد نرسیده اند را دارد. از همین رو می توانیم بگوییم TCP یک پروتکل قابل اطمینان است چرا که تضمین این را می هد که در نهایت تمامی پکت ها به مقصد می رسند. برای اینکه TCP بتواند این تضمین را ارائه دهد از چندین مفهوم استفاده می کند که دانستن این مفاهیم برای درک پروتکل TCP ضروری می باشد.

Connection Oriented 

Connection Oriented بیان کننده ی مفهومی است که در آن ارسال دیتا از یک دستگاه به یک دستگاه دیگر زمانی انجام می شود که ابتدا یک ارتباط نقطه به نقطه ایجاد شده باشد. سرویس Connection Oriented عموما تحت عنوان یک سرویس قابل اطمینان شناخته می شود چرا که تضمین میدهد دیتاها به ترتیب مناسبی با مکانیزمی تحت عنوان Sequencing تحویل مقصد داده می شوند. زمانی که بیت به بیت یک دیتا دارای اهمیت می باشد و ما نمی خواهیم به هیچ عنوان حتی یک بیت از دیتا در مسیر گم شود چرا که ممکن است گم شدن یک بیت از دیتا باعث شود دیگر دیتا قابل خواندن نباشد از سرویس Connection Oriented استفاده می کنیم. چرا که این سرویس تضمین می دهد تمامی بیت ها به مقصد تحویل داده خواهند شد. پروتکل TCP برای ارسال دیتا ها از سرویس Connection Oriented استفاده می کند. پس یکی از دلایلی که پروتکل TCP را قابل اطمینان می ساز سرویس Connection Oriented می باشد.

Sequence Number

تمامی پکت ها در یک ارتباط نقطه به نقطه ی TCP شماره گذاری می شوند. به اولین پکت از یک دیتا یک شماره ی رندوم تحت عنوان Initial Sequence Number (ISN) اختصاص داده می شود و بعد از آن این شماره در پکت های بعدی افزایش می یابد. اما چرا تمامی پکت ها شماره گذاری می شوند؟ شماره گذاری پکت دو دلیل دارد. یک اینکه ممکن است پکت ها دقیقا به همان ترتیبی که ارسال می شوند به مقصد تحویل داده نشوند در نتیجه مقصد می تواند از طریق Sequence Number پکت ها را سرهم کرده و دیتا را بخواند. از سویی دلیل دوم استفاده از Sequence Number این می باشد که ممکن یک یا چند پکت در مسیر گم شوند. دریافت کننده ی پکت ها به ازای هر پکتی که دریافت می کن با یک شماره بیشتر پیام ACK به سمت فرستنده ارسال می کند تا تایید کند که پکت ها را دریافت کرده.حال اگر چندین پکت یا به عبارت ساده چندین Sequence گم شوند دریافت کننده متوجه می شود که چه پکت هایی را دریافت کرده و چه پکت هایی را دریافت نکرده است. درنتیجه بابت آن پکت هایی که دریافت نکرده یک درخواست به فرستنده ارسال می کند تا فرستنده دوباره همان پکت ها را به ارسال کند.

CRC-Check

CRC که مخفف Cycle Redundancy Check می باشد یک روش برای شناسایی خطا در دیتا ها است. بصورت ساده CRC یک کد شناسایی خطا برای تعیین اینکه یک بلوک از دیتا سالم است یا خیر می باشد. CRC در لایه های مختلفی از مدل TCP/IP وجود دارد. پروتکل TCP نیز از CRC برای تشخیص خطا استفاده می کند. زمانی که فرستنده می خواهد یک دیتا را ارسال کند ابتدا آن دیتا را با استفاده از عملیات ریاضی محاسبه کرده و خروجی محاسبات یک کد CRC خواهد بود. این کد نشان دهنده ی این می باشد که دیتا سالم است یا خیر. فرستنده این کد را به همراه دیتا به سمت مقصد ارسال می کند و زمانی که مقصد دیتا را دریافت کرد دوباره همان محاسبات ریاضی را بر روی دیتا انجام می دهد. اگر خروجی محاسبات دریافت کننده برا با CRC ای که فرستنده ارسال کرده باشد یعنی دیتا سالم است اما اگر غیر از آن باشد یعنی بخشی از دیتا از بین رفته است.

TCP Flow Control

قبل توضیح Flow Control باهم یک سوال مطرح کنیم. فرض کنید یک Host می خواهد یک دیتا به یک Host دیگر ارسال کند. فرستنده دیتا را با سرعت 1Gbps به سمت دریافت کننده ارسال کند اما دریافت کننده کارت شبکه ای با سرعت 100Mbps داشته باشد در نتیجه نمی تواند تمامی دیتاهایی که فرستنده ارسال می کند را دریافت کند. به نظر شما چه اتفاقی می افتد؟؟ پاسخ ساده است بیشتر پکت هایی که فرستنده ارسال می کند توسط دریافت کننده به دلیل اینکه توانایی پردازش آنها را ندارد دور ریخته می شوند. به نظر شما راه حل چیست؟ برای جلوگیری از این مشکل پروتکل TCP از مبحثی تحت عنوان Flow Control استفاده می کند.
کنترل جریان یا همان Flow Control به این معنی است که اطمینان حاصل شود سرعت فرستنده با سرعت دریافت کننده یکسان باشند تا از Drop شدن پکت ها جلوگیری شود. اگر فرستنده پکت هارا با سرعت بیشتری ارسال کند دریافت کننده اعلام می کند که توانایی پردازش پکت ها با آن سرعت را ندارد در نتیجه فرستنده سرعت ارسال پکت ها را کاهش می دهد. برای درک این موضوع به تصویر 4-2 دقت کنید.

تصویر 4-2  TCP Flow Control

بازیابی خطا (Error Recovery) توسط TCP

برای درک آنچه در لایه ی Transport اتفاق می افتد باید یک نگاهی به لایه ی بالاتر یعنی Application بی اندازیم. اما چرا؟ به دلیل انکه هر لایه سرویس هایی را ارائه می دهد که لایه ی بالاتر به آنها نیاز دارد. به همین علت است که می گوییم تمامی لایه های مدل TCP/IP بایکدگیر در ارتباط می باشند.در نتیجه سرویس Error-recovery توسط پروتکل TCP برای لایه ی Application ارائه می شود.

برای مثال در تصویر 1-2، باب و آلیس از پروتکل HTTP برای انتقال صفحه ی وب آلیس از سرور وب آلیس به مرورگر وب باب استفاده می کنند. اما چه اتفاقی می افتد اگر پیام Get ارسالی از سمت باب در هنگام انتقال گم شود و به مقصد یعنی سرور وب آلیس نرسد؟ یا چه اتفاقی می افتد اگر پاسخی که آلیس برای باب ارسال کرده و حاوی اطلاعات صفحه ی وب آلیس می باشد در بین مسیر از بین رود و تحویل باب داده نشود؟ خب همانطور که انتظار می رود صفحه ی وب در مروگر باب نمایان نمی شود. 

TCP/IP به مکانیزمی احتیاج دارد تا با استفاده از آن بتواند تحویل دیتا به مقصد را در شبکه تضمین کند. از آنجایی که به احتمال زیاد بیشتر برنامه های لایه ی Application یک تضمین برای تحویل دیتا به مقصد می خواهند سازندگان TCP ویژگی Error-recovery را در این پروتکل قرار دادند. برای بازیابی خطاها TCP از مفهومی تحت عنوان Acknowledgments یا همان تایید استفاده می کند. تصویر 5-2 ایده ی ابتدایی گم شدن یا از دست رفتن اطلاعات و اینکه چگونه TCP از Error-recovery استفاده می کند را بیان می کند.

تصویر 5-2  TCP سرویس Error-recovery را برای HTTP ارائه می دهد

تصویر 5-2 نشان دهنده ی این می باشد که سرور وب آلیس صفحه ی وب را توسط سه پیام جداگانه به سمت مرورگر وب باب ارسال می کند. توجه داشته باشید که این تصویر همان هدر HTTP تصویر 2-2 را نمایش می دهد با این تفاوت که در این تصویر هدر TCP نیز اضافه شده است. هدر TCP همراه یک شماره (SEQ number) در هر پیام قرار دارد. در این مثال، در شبکه مشکلی وجود دارد، و شبکه قادر به تحویل پیام TCP شماره ی 2 به مقصد نمی باشد. زمانی که باب پیام هایی که حاوی SEQ شماره ی 1 و 3 می باشند را دریافت می کند اما پیامی که حاوی SEQ شماره ی 2 می باشد را دریافت نمی کند متوجه می شود که پیام 2 گم شده است. این اتفاق باعث می شود که باب یکبار دیگر درخواست به سمت آلیس ارسال کند و بگوید که آلیس پیام 2 را یکبار دیگر ارسال کن.
 
تعاملات یک لایه با لایه ی مجاور و لایه ی مشابه
مثال تصویر 5-2 اشاره ای به مبحثی تحت عنوان تعاملات یک لایه با لایه ی مجاور (Adjacent-layer interaction) دارد که به مفاهیمی اشاره دارد که چگونه بین لایه های مجاور در شبکه ارتباطی برقرار می باشد. در این مثال پروتکل HTTP که در لایه ی بالایی لایه ی Transport یعنی لایه ی Application قرار دارد سرویس Error-recovery را از لایه ی Transport درخواست می کند. در نتیجه می توانیم اینگونه بیان کنیم هر لایه سرویس هایی را که در لایه ی بالاتر مورد نیاز می باشد ارائه می دهد. 
تصویر 5-2 همچنین اشاره به مبحثی تحت عنوان تعاملات با لایه ی مشابه (Same-layer interaction) دارد که به مفاهیمی اشاره دارد که چگونه دو لایه ی مشابه در دو کامپیوتر می توانند با یکدگیر ارتباط برقرار کنند. به عنوان مثال هنگامی که یک کامپیوتر در یک لایه ی خاص می خواهد با یک کامپیوتر دیگر در همان لایه ارتباط برقرار کند، دو کامپیوتر از هدر ها برای نگهداری اطلاعات مربوط به پروتکل های همان لایه که میخواهند ارتباط برقرار کنند استفاده می کنند.    
 
 به عنوان مثال در تصویر 5-2 آلیس شماره های 1,2, و 3 سه را بر روی پیام هایی که به سمت باب میخواهد ارسال کند تنظیم می کند بنابراین اگر یکی از پیام ها مثلا شماره ی 2 توسط باب دریافت نشود، باب می تواند متوجه این شود که پیام شماره ی 2 گم شده است. پس آلیس Sequence Number ها را به این دلیل ایجاد می کند که باب بتواند متوجه بشود که پیام هایی دریافت شده و چه پیام هایی دریافت نشده است. باب پیام ها را دریافت می کند و با استفاده از TCP متوجه می شود که SEQ شماره ی 2 دریافت نشده بنابراین با یک پیام TCP دوباره همان SEQ را از آلیس درخواست می کند. مشخص است که هم آلیس و هم باب در یک لایه ی مشابه یعنی Transport در تعامل می باشند که ما این ارتباط را تحت عنوان تعمالات با لایه ی مشابه (Same-layer interaction) می شناسیم.
 
User Datagram Protocol (UDP)
 
با پروتکل TCP یک پروتکل بسیار کارآمد و قوی می باشد اما مکانیزم هایی که در پروتکل TCP وجود دارند باعث شده اند تا پروتکل TCP به عنوان یک پروتکل کم سرعت شناخته شود. بنابراین برای کانکشن و سرویس هایی که نیازمند سرعت زیادی می باشند پروتکل TCP مناسب نیست از همین رو پروتکل دیگری تحت عنوان User Datagram Protocol (UDP) بوجود آمد. به عبارت ساده پروتکل UDP جایگزین پروتکل TCP برای سرویس هایی که نیازمند سرعت بالاتری می باشند است. این پروتکل نیز در لایه ی Transport فعالیت دارد.
هردو پروتکل TCP و UDP  برو روی پشته پروتکل IP اجرا می شوند از همین رو آنها را با نام TCP/IP و UDP/IP نیز می شناسیم. اما نکته ی قابل توجه این می باشد که این دو پروتکل تفاوت های اساسی با یکدگیر دارند.
 
در حالی  که TCP ارتباط میزبان به میزبان (Host to Host) را فراهم می کند ، UDP از ارتباط فرایند به فرایند (Process to Process) پشتیبانی می کند. TCP بسته های جداگانه را ارسال می کند و به عنوان یک پروتکل قابل اطمینان شناخته می شود. UDP پیامی به نام دیتاگرام می فرستد و به عنوان بهترین حالت ارتباطات در نظر گرفته می شود.
 
علاوه بر اینها در بخش قبل خواندید که پروتکل TCP از مکانیزم هایی همچون Error Control و Flow Control برای ارتباطات خود استفاده می کند. این درحالی می باشد که پروتکل UDP از هیچ یک از این مکانیزم ها استفاده نمی کند. پروتکل UDP به عنوان یک پروتکل Connectionless شناخته می شود به این معنی که پروتکل UDP نیازی به برقراری یک اتصال مجازی قبل از ارسال هرگونه دیتا ندارد اما در TCP دیدیم که ابتدا یک کانکشن با مقصد برقرار می شد و سپس دیتا ها بر روی آن کانکشن مجازی ارسال می شدند.
 
از آنجایی که پروتکل UDP برای ارسال دیتاها هیچگونه کانکشنی برقرار نمی کند و برخلاف پروتکل TCP از هیچ مکانیزم Error Control و یا Flow Control استفاده نمی کند تحت عنوان یک پروتکل غیرقابل اطمینان (Unreliable) شناخته می شود. چرا که اگر فرستنده دیتایی را ارسال کند و در مسیر تعدادی از بسته ها گم شوند و به گیرنده نرسند هیچگونه مکانیزمی وجود ندارد که گیرنده به فرستنده خبر دهد تعدادی از بسته ها را تحویل نگرفته و فرستنده دوباره باید آنها را بفرستد. بنابراین اگر بسته ای در مسیر گم بشود دوباره از سمت فرستنده ارسال نمی شود. این رفتار UDP باعث شده تا پروتکل UDP نسبت به پروتکل TCP بسیار سریعتر باشد. بنابراین برای سرویس هایی که به تاخیر حساس می باشند و نیاز به سرعت بیشتری دارند همچون Voice Over IP (VOIP) و یا Video Conference از پروتکل UDP استفاده می شود. 
 
لایه ی Network در مدل TCP/IP
 
در حالی که لایه ی Application شامل پروتکل های مختلفی می باشد در لایه ی Transport پروتکل های کمتری وجود دارد که دو تا از مهمترین پروتکل های آن TCP و UDP می باشند. در لایه ی Network تعداد بسیار کمی پروتکل وجود دارد که مهمترین و سردسته ی تمام پروتکل های موجود در لایه ی Network پروتکل Internet Protocol  و یا به اختصار IP می باشد. در واقع نام مدل TCP/IP از دو پروتکل TCP و IP که دو جز مهم برای ارتباطات می باشند ایجاد شده است.
IP سه ویژگی اصلی را در بر میگیرد:
 
    • آدرس دهی (Addressing)
    • مسیریابی (Routing)
    • انتخاب بهترین مسیر (Path determination)
 
این بخش با مقایسه ی نحوه ی آدرس دهی و مسیریابی در IP با شبکه ی پست شروع می شود. برای اینکه درک کاملی از پروتکل IP و نحوه ی آدرس دهی و مسیریابی به دست آورید به دقت این بخش را مطالعه کنید.
 
پروتکل IP در مقابل شبکه ی پست
 
تصور کنید شما دو نامه برای دو نفر از دوستانتان نوشته اید. یکی از دوستانتان که قرار است نامه ی اول به او برسد در کشور دیگری زندگی می کند و دوست دیگرتان که قرار است نامه ی دوم به آن برسد در قسمت دیگری از شهر خودتان زندگی می کند. شما آدرس ها را بر روی نامه ها مینویسید و سپس با استفاده از تمبر نامه ها را می بندید در نتیجه هر دو نامه آماده ی تحویل به شرکت پست می باشند. تفاوت خیلی زیادی وجود دارد که شما باید چگونه با نامه ها رفتار کنید و یا آنها را چگونه به شرکت پست تحویل دهید؟ قطعا خیر. بصورت معمول شما هر دو نامه را در صندوق پستی قرار می هید تا مامور شرکت پست آنها را برداشته و با خود به شرکت پست ببرد. در نتیجه برای شما هیچ تفاوتی بین نامه ای که قرار است به خارج از کشور برود با نامه ای که قرار است به قسمت دیگری از شهر خودتان برود ندارد. اما شرکت پست باید هر نامه را بصورت جداگانه بررسی کند و براساس آدرس نامه ها تصمیم بگیرد که نامه ها به کجا باید ارسال شوند تا تحویل گیرنده داده شوند. برای نامه ای که قرار است در قسمت دیگری از شهر تحویل داده شود احتمالا تنها کارمندان شرکت پست آن نامه را در یکی از ماشین های حمل نامه قرار می دهند.
برای نامه ای که قرار است به کشور دیگری برود شرکت پست نامه را به یک شرکت پست دیگر ارسال می کند و آن شرکت پست نیز به شرکتی دیگر، تا زمانی که نامه به کشور مورد نظر برسد. در هر شرکت پست باید تصمیم گرفته شود که نامه باید به کدام شرکت ارسال شود تا در نهایت آخرین شرکت که در کشور دیگری قرار دارد نامه را به مقصد تحویل دهد.
 
برای اینکه تمامی این کار ها انجام شوند شرکت پست مسیر های منظمی را برای  کامیون ها، هواپیما ها و کشتی هایی که قرار است نامه ها را در بین شرکت های مختلف پست جابجا کنند دارد. این سرویس باید بتواند نامه ها را تحویل گرفته و به سمت مقصد ارسال کند و همچنین باید به گونه ای باشد تا بتواند بهترین تصمیمات را در رابطه با ارسال نامه ها به مقاصد بگیرد. به تصویر 6-2 توجه کنید.
 
تصویر 6-2  نحوه ی ارسال نامه ها (مسیریابی) توسط شرکت پست
 
به نظر شما تفاوتی میان کسی که نامه ای را می نویسد و تحویل شرکت پست می دهد با کسی که در شرکت پست کار می کند وجود دارد؟ شخصی که نامه را ارسال می کند انتظار دارد که شرکت پست نامه را تحویل گرفته و به مقصد برساند. از این رو شخصی که فرستنده ی نامه می باشد هیچ اطلاعاتی در رابطه با جزئیات اینکه چگونه نامه به مقصد می رسد ندارد. در نتیجه شرکت پست هیچ نامه ای نمی نویسد بلکه نامه ها را از مشتریان دریافت می کند. سپس شرکت پست باید جزئیاتی را در رابطه با اینکه هر نامه به کجا باید ارسال شود و نحوه ی رسیدن به مقصد هر نامه را بداند.
 
 لایه های Application و Transport در مدل TCP/IP همانند شخصی که نامه را از طریق سرویس پستی ارسال می کند ، عمل می کنند. این لایه های بالایی بدون در نظر گرفتن اینکه Host های انتهایی در یک شبکه هستند یا بصورت کامل از هم جدا و در اینترنت قرار دارند به یک روش یکسان کار می کنند. برای ارسال پیام ، این لایه های بالایی یعنی Application و Transport از لایه زیر آنها یعنی لایه Network می خواهند تا پیام را تحویل دهد.
لایه های پایینی همانند شرکت پست عمل می کنند که باید پیام ها را به مقاصد درستی تحویل دهند. برای انجام این کار ، لایه های پایینی باید شبکه فیزیکی را بصورت اساسی درک کنند زیرا آنها باید چگونگی تحویل پیام ها را از یک میزبان به میزبان دیگر انتخاب کنند.
اما سوالی که پیش می آید این است که خب تمام اینها چه ربطی به شبکه دارد؟  لایه Network در مدل TCP/IP ، که براساس پروتکل IP تعریف شده است، بسیار شبیه به سرویس پستی عمل می کند. IP اینگونه بیان می کند که هر دستگاه در شبکه باید یک آدرس متفاوت از دستگاه های دیگر داشته باشد همانند آدرس هایی که بر روی نامه ها نوشته می شوند و به شرکت پست تحویل داده می شوند. هر نامه به یک مقصد خاص و منحصر به فرد همانند یک خانه و یا اپارتمان اشاره می کند. آدرس که IP ارائه می دهد تحت عنوان IP Address شناخته می شود. همچنین IP مفهومی تحت عنوان مسیریابی (Routing) را با استفاده از دستگاه هایی تحت عنوان روتر معرفی می کند که این روتر ها شبیه به شرکت های پست عمل می کنند و وظیفه ی آنها دریافت بسته ها و ارسال آنها به سمت روتر های دیگر و یا مقصد می باشد.
دقیقا همانند شبکه ی پست که نیازمند زیرساخت کاملا مناسبی می باشد همانند اطلاعات دقیق مسیر ها، کامیون ها، هواپیما ها و ... شبکه های اینترنتی نیز نیازمند ساختار کاملا مناسبی می باشند که تعریف و ایجاد این ساختار بر عهده ی لایه ی Network می باشد.
 

 توجهTCP/IP دو ورژن از پروتکل IP را تعریف می کند. IP ورژن 4 یا همان IPV4 و IP ورژن 6 یا همان IPV6. اکثر جهان همچنان از IPV4 استفاده ی بیشتری می کنند و این ورژن متداول تر می باشد. از همین رو در مثال های کتاب از IPV4 استفاده شده است اما در همین کتاب به IPV6 نیز پرداخته شده است.

 
ادامه ی مقاله
با تهیه ی اشتراک ویژه می توانید به تمامی مقالات و منابع آموزشی دسترسی داشته باشید.
با پرداخت روزانه هزار تومان به منابع زیر دسترسی خواهید داشت :
1.تمامی مقالات آموزشی
2. ورک بوک های آموزشی
3.منابع آموزشی به همراه ترفند های شبکه