پروتکل 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‬در‬‫شبکه های سیار‬" ‬ ، ‫۱۳۸۲‬‬‬‬

پروتکل TCP و نسخه های مختلف آن

مطالب مشابه :

مقایسه بین صفحات HTML و ASP

پیچیدگی نرم افزار

پروتکل TCP و نسخه های مختلف آن