کنترل ازدحام در پروتکل قرارداد هدایت انتقال
پروتکل کنترل انتقال (TCP) از یک الگوریتم جلوگیری از ازدحام شبکه استفاده میکند که شامل جنبههای مختلفی از یک طرح AIMD یا افزایش افزایشی / کاهش چند برابر (additive increase/multiplicative decrease)، همراه با سایر طرحها از جمله شروع آهسته و پنجرهٔ ازدحام، برای رسیدن به جلوگیری از ازدحام است. الگوریتم جلوگیری از ازدحام TCP اساس اصلی کنترل ازدحام در اینترنت است. طبق اصل انتها به انتها ، کنترل ازدحامتا حد زیادی تابعی از میزبان اینترنت است، نه خود شبکه. چندین تغییرات و نسخه از الگوریتم پیادهسازی شده در پشتههای پروتکل سیستم عاملهای رایانههایی که به اینترنت متصل هستند، وجود دارد.
عملیات
[ویرایش]برای جلوگیری از فروپاشی ازدحام، پروتکل TCP از یک استراتژی کنترل ازدحام چند وجهی استفاده میکند. برای هر اتصال، TCP یک پنجره ازدحام را نگه میدارد که تعداد کل بستههای تأیید نشده را که ممکن است به صورت انتها به انتها انتقال یابند را محدود میکند. این تا حدودی مشابه پنجره کشویی TCP است که برای کنترل جریان استفاده میشود. TCP از مکانیسمی به نام شروع کند برای افزایش پنجره ازدحام پس از برقراری اتصال یا پس از پایان زمان اتصال استفاده میکند. این کار با یک پنجره شروع میشود که اندازه کوچک آن چند برابر اندازهٔ حداکثر اندازهٔ قطعه (MSS) است. اگرچه نرخ اولیه کم است، اما سرعت افزایش بسیار سریع است. برای هر بسته تأیید شده، پنجره تراکم با نرخ یک MSS افزایش مییابد به طوری که پنجره تراکم بهطور مؤثر برای هر بار سفر چرخشی (RTT) دو برابر میشود.
هنگامی که پنجره ازدحام از آستانه شروع کند تجاوز کند (ssthresh)، الگوریتم وارد یک حالت جدید میشود، به نام اجتناب از ازدحام. در حالت اجتناب از ازدحام، تا زمانی که ACKهای غیر تکراری دریافت میشوند، پنجره تراکم بهطور افزایشی با یک MSS در هر زمان چرخشی افزایش مییابد.
پنجره ازدحام
[ویرایش]در TCP، پنجره ازدحام یکی از عواملی است که تعداد بایتهای ارسال شده در هر زمان را تعیین میکند. پنجره ازدحام توسط فرستنده نگهداری میشود و وسیله ای برای جلوگیری از بارگیری بیش از حد بین فرستنده و گیرنده با ترافیک بیش از حد است. این نباید با پنجره کشویی نگه داشته شده توسط گیرنده که برای جلوگیری از اضافه بار گیرنده وجود دارد اشتباه گرفته شود. پنجره ازدحام با تخمین میزان ازدحام بر روی پیوند محاسبه میشود.
هنگامی که یک اتصال تنظیم میشود، پنجره تراکم، مقداری که بهطور مستقل در هر میزبان نگهداری میشود، بر روی تعداد زیادی از MSS مجاز در آن اتصال تنظیم میشود. واریانس بیشتر در پنجره تراکم با رویکرد AIMD دیکته میشود. این بدان معناست که اگر همه بخشها دریافت شده و تأییدیهها به موقع به فرستنده برسند، مقداری ثابت به اندازه پنجره اضافه میشود. هنگامی که پنجره به ssthresh رسید، پنجره ازدحام به صورت خطی با نرخ ۱ / (پنجره ازدحام) قطعه در هر تأیید جدید دریافت میشود. پنجره تا زمان وقوع زمان توقف رشد میکند. در زمان توقف:
- پنجره ازدحام به 1 MSS تنظیم مجدد میشود.
- ssthresh قبل از اتمام زمان، به اندازهٔ نیمی از پنجره ازدحام تنظیم شدهاست.
- شروع کند آغاز میشود.
مدیر سیستم ممکن است حداکثر حد اندازه پنجره را تنظیم کند، یا ثابت اضافه شده در هنگام افزایش افزودنی را به عنوان بخشی از تنظیم TCP تنظیم کند.
همچنین جریان داده از طریق اتصال TCP با استفاده از پنجره دریافتی که توسط گیرنده منتشر میشود ، کنترل میشود. با مقایسه پنجره ازدحام خود با پنجره دریافت، یک فرستنده میتواند تعیین کند چه مقدار داده میتواند در هر زمان معین ارسال کند.
شروع کند
[ویرایش]شروع کند بخشی از استراتژی کنترل ازدحام است که توسط TCP در رابطه با سایر الگوریتمها به کار میرود تا از ارسال دادههای بیشتر از آنچه شبکه قادر به ارسال است، استفاده کند، یعنی از ایجاد تراکم شبکه جلوگیری کند. این الگوریتم توسط RFC 5681 مشخص شدهاست.
اگرچه از این استراتژی به عنوان شروع کند یاد میشود، رشد پنجره ازدحام آن کاملاً متحاوزانه است، متحاوزانه تر از مرحله جلوگیری ازدحام است. قبل از اینکه شروع کند در TCP معرفی شود، مرحله اول جلوگیری از پیش ازدحام حتی سریعتر انجام میشد.
شروع کند در ابتدا با اندازه پنجره تراکم (CWND) از ۱، ۲، ۴ یا 10 MSS شروع میشود. مقدار اندازه پنجره ازدحام با هر یک از تأییدهای دریافت شده (ACK) افزایش مییابد، بهطور مؤثر اندازه پنجره را در هر زمان چرخشی دو برابر میکند. نرخ انتقال با الگوریتم شروع کند افزایش مییابد تا اینکه یا گم شدن تشخیص داده شود، یا پنجره منتشر شدهٔ گیرنده (rwnd) عامل محدود کننده شود، یا ssthresh به دست آید. اگر یک گم شدن رخ دهد، TCP فرض میکند که به دلیل ازدحام شبکه است و برای کاهش بار ارائه شده در شبکه گامهایی میبرد. این اندازهگیریها به الگوریتم جلوگیری از ازدحام TCP دقیق استفاده شده بستگی دارد.
پس از رسیدن به ssthresh پروتکل TCP از الگوریتم شروع کند به الگوریتم رشد خطی (اجتناب از ازدحام) تغییر میکند. در این مرحله، برای هر زمان تأخیر چرخشی (RTT)، پنجره یک قطعه افزایش مییابد.
شروع کندچنین فرض میکند که قطعههای تأیید نشده به دلیل تراکم شبکه هستند. در حالی که این یک فرض قابل قبول برای بسیاری از شبکهها است، قطعهها ممکن است به دلایل دیگر از جمله کیفیت انتقال لایه پیوند داده ضعیف از بین بروند؛ بنابراین، شروع کند میتواند در مواقع دزیافت ضعیف مانند شبکههای بیسیم عملکرد ضعیف داشته باشد.
پروتکل شروع کند همچنین برای اتصالات کوتاه مدت عملکرد بدی دارد. مرورگرهای قدیمی بسیاری از اتصالات کوتاه مدت متوالی را به سرور وب ایجاد میکنند، و اتصال برای هر فایل درخواست شده را باز و بسته میکنند. این بیشتر اتصالات را در حالت شروع کند نگه داشته و منجر به زمان پاسخگویی ضعیف میشود. برای جلوگیری از این مشکل، مرورگرهای مدرن یا چندین اتصال همزمان را باز میکنند یا از یک اتصال مجدد برای کلیه پروندههای درخواست شده از یک سرور وب خاص استفاده میکنند. با این حال، اتصالات برای چندین سرور شخص ثالث که توسط وب سایتها برای پیادهسازی تبلیغات وب، اشتراک گذاری ویژگیهای خدمات شبکههای اجتماعی و پیشخوان اسکریپتهای آنالیز وب استفاده میشوند، قابل استفاده مجدد نیستند.
منابع
[ویرایش]- Kurose, James; Ross, Keith (2008). Computer Networking: A Top-Down Approach (4th ed.). Addison Wesley. ISBN 978-0-13-607967-5.
- Kurose, James; Ross, Keith (2012). Computer Networking: A Top-Down Approach (6th ed.). Pearson. ISBN 978-0-13-285620-1.
- Abbasloo, Soheil; Xu, Yang; Chao, H. Jonathon; Shi, Hang; Kozat, Ulas C.; Ye, Yinghua (2019). "Toward Optimal Performance with Network Assisted {TCP} at Mobile Edge". Renton, WA: USENIX Association.
{{cite journal}}
: Cite journal requires|journal=
(help); Unknown parameter|book-title=
ignored (help) - Afanasyev, A.; N. Tilley; P. Reiher; L. Kleinrock (2010). "Host-to-host congestion control for TCP" (PDF). IEEE Communications Surveys and Tutorials. 12 (3): 304–342. CiteSeerX 10.1.1.228.3080. doi:10.1109/SURV.2010.042710.00114.
- Jacobson, Van; Karels, Michael J. (November 1988). "Congestion avoidance and control" (PDF). ACM SIGCOMM Computer Communication Review. 18 (4): 314–329. doi:10.1145/52325.52356.