دانلود رایگان ترجمه مقاله پروتکل های لایه حمل و نقل (آی تریپل ای 2019)

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

پژوهش در این عرصه حل این مسئله را با تکنیک‌های مدیریت صف فعال (AQM) محلی یا جریان انتها به انتها و کنترل ازدحام برای پروتکل‌های انتقال هدف قرار می دهد.
مسئله، در حالی که تشخیص آن سخت نیست، بدون یک هزینه سربار قابل توجه به سختی حل می شود [36]. پروتکل کنترل ازدحام در نقطه انتهایی ممکن است متفاوت باشد، و AQM را پیچیده تر کند؛ این اطلاعات اغلب برای روترها هم در دسترس نیستند، به همین دلیل روترها هم ممکن است قادر به پیش بینی دور انداختن بسته‌ها در شرایط ازدحام نباشند، و همین الگوریتم‌ها را به شدت پیچیده تر میکند و نسبت به تنظیم پارامترها حساس تر میکند.
AQM یک ایده تازه نیست: تکنیک‌های بیشماری پیشنهاد شدند، مانند دور انداختن زود هنگام تصادفی (RED)، و ما به خواننده پیشنهاد می کنیم که برای کسب اطلاعات بیشتر در مورد این موضوع به [36][37] مراجعه کند. با توجه به این پروپوزال‌های بسیار، آن‌ها با پذیرش محدودی مواجه شده اند، که تا حدی با توجه به مسائل ذکر گفته شده بالا در تنظیم پارامترها و هزینه محاسباتی الگوریتم‌ها بوده است [35]. اخیرا، روش‌های جدید و آسان تری برای تنظیم و استقرار الگوهای AQM، مانند مدیریت تاخیر کنترل شده (CoDel)، در محصولات تجاری متعدد پذیرفته شده است. CoDel یک الگوریتم AQM است که تاخیر بافرینگ را با مانیتورینگ تاخیر صف D در یک بازه ( معمولا 100ms) و گم شدن بسته‌ها در زمانی که حداقل مقدار D بزرگتر از 5ms ثانیه است، محدود می کند. با این وجود همانطور که در بخش D قسمت 3 بحث می کنیم، مشابه Bufferbloat به دامنه‌های بی سیم مربوط است.

.Bمسئله Incast
مراکز داده نواحی محدودی هستند که شامل سرورها و سیسم‌های نظارت کننده فعالیت‌های سرور، ترافیک و عملکرد وب هستند. تبادل داده بین سرورها معمولا بر اساس APIهای مبتنی بر پروتکل انتقال ابرمتن (HTTP) است، که از TCP به عنوان پر کاربردترین پروتکل انتقال در مراکز داده استفاده می شود. برخی از فعالیت ها، مانند مهاجرت‌های ماشین مجازی، نیز حجم بالایی از ترافیک را بین سرورها ایجاد میکند. بنابراین، لینک‌ها در مراکز داده معمولا پهنای باند بالا و تاخیر کمی دارند، در عین حال که سوئیچ‌ها بافرهای کوچکی دارند، برخلاف آنچه که در لینک‌های دسترسی، که در بخش قبل گفته شد، رخ می دهد.
فریم ورک‌های رایانش ابری به صورت گسترده در مراکز داده بزرگ قرار دادند و بارهای ترافیک بسیار بالایی را تولید می کند. برای مثال، MapReduce (که از الگوی طراحی تجمعی/بخش بندی استفاده می کند) [40] یا PageRank (استفاده شده برای جستجوی وب) [41] اغلب شامل الگوهای ترافیک چند به یک هستند، که در آن‌ها کارگران متعدد داده‌هایی را همزمان به یک گره تجمعی واحد ارسال میکنند، که در شکل 1 نشان داده شده است. در این سناریوی چند به یک، اگر همه جریان‌های incast متعدد از یک سوئیچ عبور کنند، بافر آن ممکن است کافی نباشد، و به ازدحام منجر شود. مکانیزم بازیابی بسته‌های گم شده TCP کمتر به درد می خورد، و با تایم اوت‌های متعدد مواجه می شود و باعث تنزل توان عملیاتی و تاخیرهای طولانی می شود [42].
تلاش‌های بسیاری برای تحلیل و حل این مسئله، که مسئله Incast گفته می شود، و عملکرد شبکه و تجربه کاربر را تضعیف می کند، صورت گرفته است [43]. تحلیل تخمین دقیق توان عملیاتی را می توانید در [42] و [44] ببینید. راه حل‌ها ممکن است به چهار گروه ذکر شده در [42] دسته بندی شوند: (1) تنظیم پارامترهای سیستم، مانند غیرفعال کردن شروع آهسته برای اجتناب از انباشتگی و سرریز ناگهانی بافر که باعث تایم اوت انتقال‌های مجدد می شود؛ (2) ارتقای طراحی الگوریتم سمت کاربر و داخلی شبکه، برای کاهش هدر رفت پهنای باند، حداقل سازی تایم اوت‌های انتقال مجدد و کاهش تعداد بسته‌های گم شده، و بهبود بازیابی سریع بسته‌های گم شده [39]؛ جایگزینی الگوریتم‌های کنترل ازدحام مبتنی بر گم شدن بسته با پیاده سازی‌های بهتر که اندازه پنجره ازدحام را برطبق تاخیر اندازه گرفته شده از RTTها تنظیم می کنند؛ مانندVegas؛ و (4) طراحی الگوریتم‌های کاملا جدید برای این محیط خاص، مانند Data Center TCP (DCTCP) [45]، که از اعلان ازدحام صریح (ECN) برای ارائه متدهای کنترلی مبتنی بر پنجره، یا IATCP [46]، یک رویکرد مبتنی بر نرخ استفاده می کند که مجموع تعداد بسته‌های تزریق شده برای برآورده کردن محصول تاخیر پهنای باند (BDP) شبکه را محاسبه می کند [42].

.Cتاخیر و بلاکینگ Head of Line
HoL پدیده ای است که زمانی رخ میدهد که دو جریان داده مستقل یا بیشتر یک ارتباط TCP را به اشتراک گذارند، برای مثال با ترافیک وب بر روی TCP؛ چرا که این پروتکل انتقال داده ای که دریافت میکند را به عنوان یک جریان مستمر واحد از بایت‌ها تفسیر می کند، و نیازمند تحویل ترتیبی است، با گم شدن یا تاخیر یک بسته برای هر جریانی، باعث تاخیر قابل توجه می شود. HoL در هر پروتکلی که نیازمند تحویل ترتیبی است یک مسله شناخته شده است، و راه حل‌های آشکار آن بازکردن یک ارتباط برای هر جریان داده ای است که از سربار قابل توجه در راه اندازی ارتباطی و بازیابی خطا رنج می برد. علاوه بر این، با این گزینه، کنترل ازدحام کمتر پایدار است، چرا که هر ارتباط به صورت مستقلی اجرا می شود.
ترافیک وب یک مثال از مسئله HoL است: معمولا، صفحات وب شامل اشیای متعددی هستند، مانند متن، تصویر، رسانه و اسکریپت‌های ثالث؛ زمانی که یک کلاینت یک صفحه را از سرور درخواست می کند، هریک از این اشیا با یک درخواست HTTP GET واحد دانلود می شوند، اما نیازی نیست که در همان لحظه نمایش داده شوند. HTTP/1.1 مالتی پلکسینگ را اجازه نمیدهد، لذا کلاینت مجبور است که برای هر شی یک ارتباط TCP باز کند، که مسائل گفته شده در بالا پیش می آید. نسخه 2 پروتکل، که در سال 2015 تحت عنوان RFC 7540 معرفی شد، قرار بود که این مسئله را با استفاده از یک ارتباط TCP واحد برای مدیریت همه درخواست ها، با کاهش زمان بارگذاری صفحه حل کند. به هر حال، این مزیت با HoL در شبکه‌هایی که بسته‌ها گم می شدند لغو شد: با توجه به اینکه همه بسته‌ها برای جریان‌های HTTP 2.0 متعدد در طول زمان بر یک ارتباط TCP مالتی پلکس می شوند، که نیازمند تحویل ترتیبی است، سپس گم شدن یک بسته باعث توقف همه جریان‌ها می شود، نه فقط جریان مربوط به بسته، که در شکل 2 نیز نشان داده شده است. برای مثال، سنجش‌هایی در شبکه‌های سلولی نشان میدهد که HTTP/2 مزیت عملکردی قابل توجهی نسبت به HTTP/1.1 ندارد [19].
در اصل، تحویل ترتیبی برای قابلیت اعتماد ضروری نیست، اما پروتکل‌های انتقال مانند TCP نیازمند هردوی آن‌ها هستند، اگر چه پروپوزالی برای بسط TCP برای اجازه دادن انتقال بدون ترتیب برای سرویس‌های چند رسانه ای برای اجتناب از مسئله HoL وجود دارد، این به صورت گسترده پذیرفته نشده است. شکل 2 نشان می دهد که پروتکل‌ها از جریان‌های داده متعدد مانند SCTP یا QUIC حمایت می کنند، که در بخش 3 تشریح شده است، و می توان بر مسئله HoL به دلیل اینکه هیچ خط واحدی برای مسدود سازی وجود ندارد غلبه کند: هر جریان، بافر خود را دارد و تحویل ترتیبی در هر جریان تضمین می شود [58].
سناریوهای چند مسیره مورد دیگری است که در آن TCP به شدت از مسئله HoL رنج می برد؛ که این مسئله را به صورت دقیق در بخش 5 تشریح می کند.

.Dعملکرد در کانال‌های بی سیم
عملکرد TCP در کانال‌های بیسیم از زمان معرفی سرویس‌های بی سیم تجاری در دهه 1990 بررسی شده است [59]. الگوهای کنترل ازدحام سنتی معمولا به گم شدن بسته ها، که فرض میکنند ناشی از ازدحام است، با کاهش نرخ ارسال واکنش نشان می دهند. در لینک‌های بی سیم، بسته‌ها ممکن است به دلیل کاهش کیفیت کانال گم شوند. بنابراین، انتزاع ارتباطات کلی ضعیف است، و عملکرد انتها به انتها تضعیف میشود. راه حل‌های متداول شامل ارائه مکانیزم‌های انتقال مجدد و حفاظت در لینک‌های بی سیم [60] (حتی با افزایش نوسانات تاخیر)، و پروکسی‌های ارتقای عملکرد درون شبکه است. چندین تکنیک در طول سال‌ها برای تکنولوژی‌های متفاوت پیشنهاد شده است مانند LTE [62]، و WiFi [63]. خوانندگان را به برای بحث‌های گسترده در مورد عملکرد TCP در لینک‌های بی سیم به [63][64] ارجاع می دهیم.
اخیرا، پذیرش فرکانس های mmWave برای نسل بعد شبکه‌های سلولی علاقه ای نسبت به عملکرد TCP در لینک‌های بی سیم بوجود آورده است. به خصوص، در این رسانه بی سیم نوسانات کانال بسیار بیشتر از فرکانس‌های زیر 6GHz است، که با توجه به حساسیت نسبت به مسدود سازی موارد معمولی، و جهت گیری ارتباطات است. این محدودیت‌ها بر طرح لایه‌های پایینی پشته پروتکل تاثیری ندارد، اما بر عملکرد لایه انتقال، که در [66][67] بحث شده است تاثیر می گذارد. حلقه کنترل TCP براستی برای واکنش مناسب به پویایی کیفیت کانال خیلی آهسته است و نرخ داده ای را ارائه میدهد که بر لینک‌های mmWave تاثیر می گذارد. برای مثال، حتی اگر Bufferbloat در شبکه‌های سلول زیر 6GHz ارائه شوند، این جدید در mmWaves مخرب تر است، جایی که بافرهای بزرگ برای حفاظت از تغییرات زمانی و ناگهانی ظرفیت لینک نیاز است، با توجه به انتقال خط دید (LOS) به غیرخط دید (NLOS). علاوه بر این، این نشان میدهد که TCP استفاده زیربهینه ای از نرخ داده mmWave بسیار بالا دارد، چرا که زمان زیادی می برد که بعد از گم شدن بسته یا در آغاز ارتباط به ظرفیت کامل دست یابد. از آنجایی که این مسئله در منطق کنترل ازدحام ذاتی است، هر پروتکلی که کنترل ازدحام را اجرا می کند نیازمند کار کارآمدی در یک سناریوی بی سیم است.

3. پروتکل‌های انتقال اخیر
در این بخش، بر تشریح سه پروتکل انتقال به تازگی پیشنهاد شده تمرکز میکنیم: QUIC, SCTP and DCCP. به طور خاص، ویژگی‌های اصلی هر پروتکل را تشریح میکنیم، و با توجه به TCP نوآوری‌های آن را مطرح می کنیم. جدول 1 مشخصه‌های اصلی این پروتکل‌ها را، همراه با اسناد IEFT مرتبط و برخی از جزییات اجرایی آن‌ها خلاصه میکند. بحث بر مکانیزم‌های کنترل ازدحام می تواند توسط این پروتکل‌ها استفاده شود و بسط‌های چند مسیره اخیر در زیر بخش بعدی ارائه شده است.
جدول 1: خلاصه ای از ویژگی‌های اصلی پروتکل‌های انتقال اخیر که در این مقاله بررسی شده اند (SCTP, QUIC and DCCP). ما همچنین یک بررسی بر پروتکل‌های TCP و UDP قبلی به عنوان مقایسه آورده ایم.

A . یک ارتباط اینترنتی UDP سریع (QUIC)
QUIC یک مکانیزم انتقال لایه کاربرد یا اپلیکیشن است [69] که توسط گوگل در سال 2013 معرفی شده و در حال حاضر برای استانداردسازی توسط IEFT در نظر گرفته شده است. QUIC در کرنل اجرا نمی شود، اما به عنوان یک کتابخانه فضای کاربر یا در خود اپلیکیشن اجرا می شود، و بر UDP به عنوان پروتکل انتقال اصلی تکیه می کند. انگیزه‌های اصلی مربوط به معرفی QUIC در [70] بحث شده است. در حالی که گزینه‌های متعددی برای TCP در لایه انتقال پیشنهاد شده اند، پذیرش آن‌ها خیلی گسترده نیست، با توجه به موارد استخراج شده ناشی شده از جعبه‌های میانی در شبکه ای که بسته‌ها از پروتکل‌های مجهول را دور می اندازد، برای مثال پروتکل‌هایی که از TCP و یا UDP متفاوت هستند. QUIC بسته‌های خود را در دیتاگرام‌های UDP کپسوله میکند، بنابراین از بیشتر ناسازگاری‌ها با جعبه‌های میانی اجتناب میکند. دوم، همانطور که در بخش 1 گفتیم، TCP در کرنل اجرا می شود، و هر تغییر یا الگوریتم کنترل ازدحام جدید نیازمند یک به روز رسانی سیستم عامل است، که همیشه امکان پذیر نیست. سرانجام، از نظر طراحی پروتکل، QUIC حل مسئله HoL TCP را که در بخش II-C تشریح شد را هدف قرار میدهد، و تاخیر دست تکان دادن در آغاز ارتباط را کاهش می دهد.

QUIC از (1) برخی از ویژگی‌های TCP، شامل مکانیزم تایید، کنترل ازدحام، و بازیابی بسته‌های گم شده، (2) مذاکرات کلیدی TLS 1.3 که نیازمند ارتباطات رمز شده است، و (3) ویژگی‌هایی HTTP/2، مانند چند جریانی تشکیل شده است [58]. شکل 3 تفاوت‌هایی را در پشته پروتکلی برای یک ترکیب HTTP/2 و TCP و HTTP/2 و QUIC نشان می دهد. ترکیب این عناصر به QUIC اجازه میدهد که چند عرصه کلیدی را بهینه سازی کند. برای مثال، یکپارچه سازی دست تکان دادن‌های مربوط به انتقال و رمزنگاری در همان پیام کاهش زمان را برای دست تکان دادن اولیه ممکن میسازد. علاوه بر این، رمزگذاری هدر بسته بررسی و ردیابی هدر بسته را برای جعبه‌های میانی مشکل می کند. علاوه بر این، این بازیابی بسته‌های گم شده TCP را با تمایز قائل شدن در ACKها بین بسته‌های گم شده و خارج از ترتیب بهبود می بخشد. یک ارتباط واحد از چند جریان مستقل تشکیل شده است ( که می تواند به جریان‌های HTTP/2 نگاشت یابد) لذا گم شدن یک بسته از یک جریان واحد دیگر را مسدود نمیکند، که مسئله HoL را به صورت موثری کاهش میدهد. سرانجام، شناسه‌های اضافی برای برچسب گذاری یک ارتباط معرفی شدند، که می توانند حتی در مورد تغییرات در آدرس پروتکل اینترنت (IP) حفظ شوند.
1) ایجاد ارتباط: ایجاد ارتباط یکی از نوآوری‌های اصلی معرفی شده در QUIC است، به خصوص با گزینه 0-RTT. TCP حداقل به یک RTT برای دست تکان دادن در زمان استفاده از TLS 1.3، یک یا دو RTT اضافی برای دست تکان دادن رمزنگاری در زمان استفاده از نسخه 1.2 قبلی تر احتیاج دارد.