پروتکل TCP و نسخه های مختلف آن
۲- TCP Tahoe:
TCP Tahoeکه به نسخه ۱ شبکه ( BNR1) BSDنیز مشهور است، بـه پیـاده سـازی اصـلی الگـوریتم کنترل ازدحام Jacobsonروی سیستم عامل BSDدر سال ۱۹۸۸ مربوط می شـود. ایـن روش مـشتمل بـر شروع آهسته ، پرهیز از ازدحام ، یک تخمین بهبود یافته از RTTو انتقال مجدد سریع است . [۱]
مشکلات ترافیکی که از ۱۹۸۶ روی اینترنت بروز کرد و باعث کاهش توان عملیاتی – در بعضی موارد– بـا ضریبی از هزار شد، موجب شد تا مکانیزم های جدیدی برای مقابله با آن ارائه شود. TCP Tahoeشاید اولین نسخه ای از TCPباشد که اکثر مکانیزم های کنترل ازدحام پیشرفته TCPرا در برمی گیـرد. هـدف از ایـن مکانیزم ها تضمین این است که اتصال TCPقادر باشد به موازنه برسد و پس از اینکه به موازنه رسید، اتصال باید از اصل (حفظ بسته ها) پیروی کند. این اصل می گوید که وقتی اتصالی به موازنه یا تعادل رسید، فقط زمانی می تواند یک بسته را روی شبکه منتقل کند که فیدبک بازگشتی که نشان دهنده خروج یک بسته دیگر از شبکه است را دریافت کرده باشد. اتصال با وارسی شبکه در مورد پهنای باند موجـود و همچنـین تنظـیم یک پنجره ازدحام فرستنده که به تازگی انجام شده باشد، به توازن می رسد. در ،TCP Tahoeپنجره ای که فرستنده بکار می برد، حد پایین پنجره گیرنده و همین پنجره ازدحام جدید است. عمده ترین بهبود در کارایی TCPاز مکانیزم انتقال مجدد سریع ناشی می شود. پس از دریافت سومین اعلام وصول تکراری انتقال مجدد آغاز می شود، بنابراین TCP Tahoeمجبـور نیـست زمـانی طـولانی بـرای منقضی شدن تایمر انتقال مجدد صبر کند.
تنها نقطه ضعف اصلی TCP Tahoeدر این است که به دنبال گم شدن هر بسته, شروع آهسته مکرراً ا راه اندازی می شود. فرایند شروع آهسته زمان زیادی لازم دارد تا نـرخ انتقـال TCPرا دوبـاره بـه حـال عـادی برگرداند، از اینرو TCP Tahoeدر اتصالهایی که حاصل ضرب پهنای باند در تـاخیر بـالایی داشـته باشـند، خوب اجرا نمی شود.
۳- TCP Reno :
TCP Renoدر سال ۱۹۹۰ روی سیستم عامل BSDپیاده سازی شد، بنابراین به نـسخه ۲ شـبکه BSDشناخته می شود ۲) .(BNRامروزه پر کاربردترین نسخه TCPهمین Renoمی باشد. TCP Renoبه Tahoe مکانیزم بازیابی سریع را اضافه می کند. بازیابی سریع اتصال را قادر می سازد تا به سرعت بخش گـم شـده را بازیابی کند
تفاوت اصلی میان Renoو Tahoeدر مرحله ای است که پس از هر انتقال مجدد سریع وارد آن می شوند. هم در Tahoeو هم ،Renoانتقال مجدد سریع پس از دریافت سه تا dupackآغاز می شود. ولی وقتی یـک ACKجدید یا جزئی می رسد، Tahoeپنجره ازدحام خود را به یک بخش کاهش می دهد. در نتیجه TCP Tahoeوارد فاز شروع آهسته می شود تا اینکه دوباره مقدار cwndبه ssthreshبرسد. اما در Renoزمانیکـهیک ACKجزئی یا جدید دریافت میشود، cwndبه مقدار ssthreshست می شود، و موجـب مـی شـود تـا سیستم بلافاصله وارد فاز پرهیز از ازدحام شود.
TCP Renoدر کنار بازیابی سریع، از گزینه های (پیشگویی سرآیند) و (اعـلام وصـول بـا تـاخیر) نیـز پشتیبانی می کند. پیشگویی سرآیند یک بهینه سازی برای موارد عادی است که بخش ها بصورت مرتب وارد می شوند، و گزینه اعلام وصول با تاخیر بجای اینکه هر بخش را جداگانه ACKنماید، صبر می کند تا آنها را در کنار بخش های دیگر اعلام وصول کند. مزیت اصلی TCP Renoبر Tahoeدر این است که زمان ورود داده جدید با dupackها را نگهـداری مـی کند و در هنگام کاهش نرخ انتقال TCPاز ورود به فاز شروع آهسته اجتناب می کند. این بهبودی بخصوصدر اتصال هایی که حاصل ضرب پهنای باند در تاخیر بالایی دارند، بسیار قابل توجه است زیرا در ایـن حالـت فاز شروع آهسته بسیار طولانی می شود.
۴- TCP New Reno :
مکانیزم های بازیابی و انتقال مجدد سریع در TCP Renoدر مواردی که فقط یک بسته در هر RTTگم می شود بسیار کارا و مؤثر است. ولی مشاهده شد که وقتی چند بسته در یـک رفـت و برگـشت حـذف مـی شوند، Renoخوب عمل نمی کند [۵]. در پیوندهای پر سرعت، هر ازدحام عادی نیز می تواند سبب شود تا چندین بخش حذف شوند. در این موارد انتقال مجدد و بازیابی سریع دیگر قادر نیستند بخشهای گم شده را بازیابی کنند و لذا مکانیزم شروع آهسته مکرر ًا فراخوانی می شود. شکل۴-۱ نشان می دهـد کـه وقتـی سـه بسته متوالی از یک پنجره گم می شود، فرستنده TCPدوبار دچار انتقال مجدد سریع می شود و سپس تایم اوت می دهد. در این لحظه، ssthreshبه یک هشتم پنجره ازدحام اصلی سـت مـی شـود. در نتیجـه، رشـد نمایی پس از زمان بسیار کوتاهی قطع شده و افزایش خطی با یک پنجره خیلـی کوچـک آغـاز مـی شـود.
بنابراین TCPدر یک نرخ بسیار پایین داده ها را انتقال می دهد و فاقد توان عملیاتی بالا می باشد.
[۶] TCP New Renoیک فاز بازیابی سریع جدید معرفی می کند, بدین ترتیب که وقتی انتقال مجدد سریع برای اولین بار آغاز می شود، فرستنده آخرین شماره ترتیب ارسالی (RECOVER)را نگاه می دارد.
بعد از این که اولین بسته اعلام وصول نشده پس از دریافت سه تا dupackمجدد اً منتقل شد، فرسـتنده الگـوریتم بازیابی سریع معمولی را دنبال کرده و بازاء هـر dupackدریـافتی یکـی بـه cwndاضـافه مـی کنـد. وقتـیفرستنده یک ACK برای بسته دوباره منتقل شده دریافت می کند، ابتدا بررسی می کند که آیا همـه بـستههای قبل از RECOVERاعلام وصول شده اند یا خیر. اگر اینطور بود، پس ACKیک ACKجدیـد اسـت.فرستنده از فاز انتقال مجدد سریع و بازیابی سریع خارج شده و cwndخود را به ssthreshست کرده و یـک افزایش خطی را شروع می کند (مرحله پرهیز از ازدحام).
از طرف دیگر ، اگر ACKیک ACKجزئی باشد، یعنی بخشی که رسیدن آن اعـلام وصـول شـده فقـطقسمتی از بخشهای قبل از RECOVERباشد، فرستنده بلافاصله بخش مورد نظر بعدی ‐کـه توسـط ACK مشخص شده– را انتقال مجدد مید هد این روال تا زمانیکه همه بخشهای قبل از اعلام وصول شوند ، ادامه می یابد. RECOVER
این تغییرات به New Renoاجازه می دهد تا گم شدن چند بسته را در تنها یک فاز بازیابی سریع هندل کند، در حالیکه Renoمجبور است تا چندین بار بازیابی سریع را فراخوانی کند. جلوگیری از فراخوانی چنـد باره بازیابی سریع دو اثر زیانبار را کاهش و تخفیف می دهد. اول اینکه ، فرستنده را از کوچک شدن بـسیارزیاد پنجره ازدحام محافظت می کند. دوم ، از وقفه هایی که TCP New Renoپس از مفقود شدن دو بسته در یک پنجره دچار آن می شود، می کاهد. در عین حال که New Reno قادر به هندل کردن چند بسته گم شده در یک پنجره می باشد، ولی در هر RTTحداکثر یک بسته را می تواند شناسایی و دوباره ارسال کند. ایـن ناکارآمـدی در جاهـایی کـه حاصـلضرب پهنای باند در تاخیر بالاست، بیشتر به چشم می خورد.
۵- TCP SACK :
در حال حاضر هر گیرنده TCPفقط آخرین بخشی را که با موفقیت و به صورت مرتب دریافت می شود، اعلام وصول می کند. در صورت رخ دادن هر خطایی ، فرستنده تنها می تواند اولین بخش مفقـود شـده را از روی اعلام وصولهای دریافتی تشخیص دهد. وضعیت تحویل بخشهای بعدی تا هنگامیکه اعلام وصول اولـینبسته دوباره ارسال شده دریافت نشود، برای فرستنده نامشخص است. بنابراین اگر در هر زمان رفت و برگشت چند خطا اتفاق بیفتد ، معمولا سبب انقضا زمان(timeout) در مبدا می شود.
گزینه TCP SACKکه در [۲] معرفی شده است, در واقع تامین راهی برای تهیـه اطلاعـات بیـشتر درمورد بسته های دریافت شده است. گزینه SACKیک فیلد اختیاری در سرآیند TCPاسـت. هرگـاه داده ای خارج از ترتیب دریافت شود، SACKفرستاده مـی شـود. همـه ACKهـای تکـراری دارای گزینـه هستند. گزینه شامل لیستی از بلاک های داده همجوار است که هم اکنون توسط گیرنده دریافت شـده انـد. هر بلاک داده نیز بوسیله شماره ترتیب اولین بایت در بلاک (لبه سمت چپ بلاک) و شماره ترتیب بایتی که بلافاصله بعد از آخرین بایت بلاک است، شناسایی می شود. به علت محدودیتی که در حداکثر اندازه سـرآیند TCPداریم، در هر بسته SACKحداکثر سه بلاک SACKمی توان تعریف کرد.
گیرنده ردپای همه بلاک های داده نامرتب دریافت شده را نگاه می دارد. وقتی SACKتولید مـی شـود، اولین بلاک ,SACKبلاک داده ای که جدیدترین بخش داده دریافت شـده را مـشخص مـی کنـد. ایـن امـر بخاطر آن است که گیرنده آخرین اطلاعات ممکن را برای فرستنده فراهم کند. پس از اولین بـلاک، SACK بقیه بلاکها به هر ترتیبی می توانند قرار گیرند، ولـی گیرنـده بایـد سـعی کنـد تـا حـد ممکـن بـلاک هـای متمایزتری را ضمیمه SACKنماید.
فرستنده جدولی دارد که همه بخش های ارسال شده اما ACKنشده را در آن نگاه می دارد. هـر بخـشی که فرستاده می شود به جدول اضافه می شود. زمانیکه فرستنده یک ACKبـا گزینـه SACKدریافـت مـی کند، همه بخشهایی که در بلاک های SACKمشخص شده اند به عنوان Sackedمارک می شـوند. و سـطر مربوط به هر بخش تا وقتی که آن بخش ACKشود، در جدول باقی می ماند. وقتی فرستنده سه تا dupack دریافت می کند ، اولین بسته اعلام وصول نشده را مجدد ًا انتقال می دهد . در طول مدت انتقال مجدد سریع ، هنگامیکه فرستنده بازاء هر dupack های موجود در بلاک های SACK را قبل از فرستادن هر بـسته جدیـد انتقـال مجـدد دهـد. هـر وقـت کـه فرستنده یک بخش را دوباره انتقال می دهد ، دریافتی یک بخش را ارسال می کند ، اول تـا آن بخش در جدول به عنوان انتقال مجدد شده مارک می شود .
اگر یک بخش انتقال مجدد شده گم شود، فرستنده تایم اوت داده و شروع آهسته را اجرا می کنـد. زمانیکـه تایم اوت رخ می دهد، فرستنده جدول SACKرا بازنشانی می کند. فرستنده برای ردگیری تعداد بسته هایی که در حال حاضر در حال انتقـال هـستند ، از مکـانیزم لولـهای جدیدی استفاده می کند. Sackمکانیزم انتقال مجدد سریع را درست مشابه با New Renoاجرا می کند. بـا شناسایی هر بسته گم شده به فاز انتقال مجدد سریع وارد می شود، و زمانیکه همه داده های معـوق مانـده از شروع فاز انتقال مجدد سریع با موفقیت اعلام وصول شدند از این مرحله خارج می شود.
SACKموقعیکه چندین بسته در یک پنجـره مفقـود مـی شـوند بهتـر از New Renoعمـل مـی کنـد. اطلاعات تفصیلی که بوسیله SACKفراهم می شود ، به فرستنده این اجازه را میدهد تا چند بسته گم شده را در یک RTTمجدداً انتقال دهد، در حالیکه New Renoباید در انتظار ACKاولین بـسته انتقـال مجـدد شده بماند تا مشخص شود که چه بسته های دیگری مفقود شده اند.
۶- TCP Vegas :
[۳] TCP Vegasیک دگرگونی اساسی در پیاده سـازیهای قـدیمی تـر TCPداده اسـت و در ویـرایش ۳٫۴ BSD Unixتعمیم داده شده است. این روش از سه تکنیـک بـه منظـور بهبـود تـوان عملیـاتی TCPو کاهش بسته های گم شده استفاده می کند. اول TCP Vegasبرای تخمین RTTبجای دانه هـای درشـت تـایمر TCPاز سـاعت سیـستم اسـتفاده می کند. تخمین دقیقتر RTTموجب می شود تا ازدحام زودتر تشخیص داده شود، بنابراین TCPمی تواند هر بسته را حتی قبل از دریافت سه تا dupackانتقال مجدد دهد.
دوم ، Vegasبا مقایسه توان عملیاتی اندازه گیری شده و توان عملیاتی مورد انتظـار کـه بوسـیله انـدازه پنجره محاسبه می شود, تغییرات توان عملیاتی را زیـر نظـر مـی گیـرد. الگـوریتم پرهیـز از ازدحـام از ایـن اطلاعات برای حفظ مقدار بهینه داده در شبکه استفاده می کند. بنابراین، از توان عملیاتی به عنوان شاخصی برای تخمین حالت پایدار استفاده می شود. و در آخراینکه Vegasالگوریتم شروع آهسته را با معرفی یک فـاز پنجـره ازدحـام ثابـت در هـر رفـت و برگشت تغییر داده است. پنجره ازدحام در فاصله بین هر دو رفت و برگشت به طور نمایی افزایش می یابـد ودر مدت زمان رفت و برگشت بسته ثابت می ماند. در مدت فاز ثابـت، الگـوریتم, تـوان عملیـاتی تخمینـی وبدست آمده را با هم مقایسه می کند. از اختلاف ایندو توان عملیاتی استفاده می شود تا TCPمشخص کنـدکه باید وارد مُد افزایشی یا مُد کاهشی شود. TCP Vegasزمان بیشتری لازم دارد تا وارد حالت پایدار شود ، ولی برآورد حالت پایدار دقیق تر و درست تر است.
۷- منابع :
۱- V. Jacobson. ”Congestion avoidance and control,” ACM Computer Communications Review, Proceedings of the Sigcomm ’۸۸ Symposium in Stanford, CA, vol. 18, no. 4, 1988, pp. 314-329.
2- M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, ”RFC 2018: TCP SelectiveAcknowledgement Options,” October 1996.
3- L. S. Brakmo, S. W. O'Malley, and L. L. Peterson. ”TCP Vegas: New techniques for congestion detection and avoidance,” In Proceedings, 1994 SIGCOMM Conference,London, UK, Aug. 31st – Sept. 1994, pp. 24-35.
4- Habibullah Jamal, Kiran Sultan , " Performance Analysis of TCP CongestionControl Algorithms" , INTERNATIONAL JOURNAL OF COMPUTERS AND COMMUNICATIONS ,2008
5- J. C. Hoe. ”Improving the start-up behavior of a congestion control scheme forTCP,” In Proceedings of the ACM SIGCOMM Conference on Applications,Technologies, Architectures, and Protocols for Computer Communications of ACM SIGCOMM Computer Communications Review New York, vol. 26, no. 4, pp. 270-
280, Aug. 1996, ACM Press.
6- S. Floyd. ”The New Reno Modification to TCP’s Fast Recovery Algorithm. RFC 2582,” Apr. 1999.
7- بهروز شاهرخ زاده، "بررسی و ارزیابی کارایی روشهای انتها-به-انتهای TCPدرشبکه های سیار" ، ۱۳۸۲
مطالب مشابه :
مقایسه بین صفحات HTML و ASP
موسسه آموزش عالی سفیر دانش ایلام. کمک به دانشجویان کامپیوتر دانشگاه سفیردانش ایلام هست
پیچیدگی نرم افزار
موسسه آموزش عالی سفیر دانش ایلام. کمک به دانشجویان کامپیوتر دانشگاه سفیردانش ایلام هست
پروتکل TCP و نسخه های مختلف آن
موسسه آموزش عالی سفیر دانش ایلام. کمک به دانشجویان کامپیوتر دانشگاه سفیردانش ایلام هست
برچسب :
سفیردانش ایلام