دلیل پنهان کاهش سرعت اینترنت و چگونگی رفع آن‌

جیم گتیز با بررسی پینگ‎ها و سطوح مختلفی از بارگذاری اتصال اینترنت به این نتیجه رسید که زمان بازگشت پاسخ درخواست از اینترنت اغلب بین چهار تا ده برابر از آن چه او انتظار داشت طولانی‎تر می‎شد. و این گونه بود که او پدیده‎ای به نام bufferbloat را معرفی كرد. نتیجه گیری او این بود که بسته‎های داده ضروری در بافرهایی گیر افتاده بودند که بیش از حد بزرگ شده بود.

مطلب پیشنهادی

بر اثر وقوع طوفان خورشیدی

احتمال قطع اینترنت کل جهان در سال ۲۰۲۰

از آن زمان گتیز مشاهدات خود را گردآوری و منتشر کرد. محققانی از شرکت‎هایی مثل سیسکو و گوگل، و همچنین گروه‎های تعیین استاندارد مثل IETF و محققان ارشد دانشگاهی شروع به تحقیق، آزمايش و نوشتن در مورد bufferbloat کردند. آنچه امروز مشخص است این است که پدیده bufferbloat واقعیت دارد، اما هنوز به طور کامل مشخص نشده است که میزان تاثیر آن روی گردش طبیعی ترافیک اینترنت تا چه اندازه است.

چه کسی بیشترین تاثیر را از این پدیده خواهد دید؟

هر کسی که مشغول وبگردی یا استفاده از موتورهای جستجو باشد، درگیر خواهد شد. همچنین کسانی که از اپلیکیشن‎های زنده نظير برنامه‎های صوتی و تصویری استفاده می‎کنند نیز تحت تاثیر قرار خواهند گرفت. یک مثال در این مورد کارمندانی هستند که در خانه، جاده، هتل یا هات اسپات‎های وای‎فای کارهای خود را انجام می‎دهند. تحقيقات نشان می‎دهد که هتل‎ها و مراکز ارائه خدمات وای‎فای بیشترین تاثیر منفی را از پدیده bufferbloat دریافت می‎کنند.

کدام نوع از ترافیک‎ها بیشترین تاثیر را از این پدیده خواهند گرفت؟

جریان ترافیک روی لینک‎هایی که مصرف پهنای باند زیادی دارند درگیر خواهند شد. کاربردهایی مثل VoIP ،DNS و ARP که از بسته‎های داده کوچک استفاده می‎کنند نیز می‎توانند دچار این مشکل شوند. تاثیر روی VoIP به صورت افزایش تاخیر و تغییر صدا ظاهر می‎شود. زمان پاسخ تبادلات DNS نیز ممکن است بین دو تا هشت برابر بیشتر از حالت عادی به طول بیانجامد.

چگونه مشکلی که می‎تواند تا این اندازه روی عملکرد اینترنت تاثیرگذار باشد این همه مدت مخفی نگه داشته شده است؟

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

Bufferbloat دقیقا چیست؟

به منظور کم کردن تعداد بسته‎های گم شده داده در اینترنت، اپراتورهای شبکه، توسعه دهندگان و مهندسان برای چندین بار متوالی اندازه بافرهای شبکه را افزایش داده‎اند. این کار با وجودی که زمان پاسخ‎گویی را افزایش می‎دهد اما تاثیر کمی‎ روی عملکرد کلی دارد. به تبع آن، بسته‎های کوچک ضروری مثل آنهایی که در VoIP ،DNS و TCP استفاده می‎شود ممکن است در بافرهای بسته‎های بزرگ‎تر مربوط به انتقال فایل و یا سایر نقل و انتقالات دسته‎ای دیگر مثل بیت ریت‎های تطبیقی ویدیو گرفتار شوند.

یک مشکل مفهومی‎ مرتبط با مدیریت بافر، آزمايشات، برگه‎های سفید و حتی راهنماهایی که اغلب بافرها را به عنوان بخش کوچکی از حافظه معرفی می‎کنند وجود دارد. خیلی از اوقات بافرها می‎توانند صدها یا حتی هزاران بسته را در لحظه نگهداری کنند. اینها تنها محدود به دستگاه‎های شبکه نمی‎شوند. آنها را می‎توان در پروتکل ایستگاه‎های کاری، درايور کارت شبکه و هر گذرگاهی در مسیر رسیدن به انتهای ایستگاه نیز مشاهده کرد.

صدمات bufferbloat در عملکرد TCP به چه شکل است؟

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

فرض کنید که از یک سرور FTP خواسته شده تا یک فایل حجیم را منتقل کند. TCP معمولا عملیات انتقال را با ارسال چهار سگمنت آغاز می‎کند و بعد در انتظار تایید تحویل آنها می‎ماند. سیاست معمول به این صورت است که بعد از هر سگمنت دریافت شده یک نشانه دریافت تاییدیه (ACK) نیز ارسال می‎شود. بعد از این که هر چهار سگمنت نشانه دریافت را ارسال کردند، گیرنده با ارسال هشت سگمنت نرخ سرعت ارسال را افزایش می‎دهد و در انتظار دریافت تاییدیه می‎ماند. بعد از تایید شدن این سگمنت‎ها به همین ترتیب نرخ ارسال به 16 و بالاتر افزایش میابد.

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

Bufferbloat چگونه روی این فرآيند تاثیر می‎گذارد؟

یک اتصال بین یک لینک پر سرعت و یک لینک کم سرعت را در نظر بگیرید. در چنین مواردی است که اهمیت وجود بافر مشخص می‎شود. برای مثال، فرض کنید ما یک مسیر محلی یک گیگابیت در ثانیه مثل کابل یا مودم DSL در اختیار داریم. حالا تصور کنید این مودم به یک خدمات دهنده اینترنت (ISP) متصل شده است که نرخ دانلود 10 مگابيت در ثانیه و آپلود 2 مگابیت در ثانیه را فراهم می‎کند. سرور FTP بافر ارسال شده به اتصال پر سرعت را خیلی سریع‎تر از نرخ خروج لینک کندتر پر می‎کند.

حالا اگر این بافر بزرگ باشد دو اتفاق ممکن است رخ دهد: اول، اگر بافر پر شود، آخرین بسته رسیده از بین می‎رود. به این اتفاق tail drop گفته می‎شود. نشانه تاییدیه که این از بین رفتن بسته را به ارسال کننده اطلاع می‎دهد تا زمان رسیدن بسته بعدی ارسال نخواهد شد و در چنین شرایطی عملا این پیام غیر قابل استفاده خواهد بود. گذر این فرآيند از بین یک بافر بزرگ زمان قابل ملاحظه‎ای را تلف می‎کند. آزمايشات انجام گرفته روی بیت ریت‎های تطبیقی ویدیو نشان می‎دهد که قبل از این که ایستگاه بتواند سگمنت از بین رفته را دوباره ارسال کند نزدیک به 200 سگمنت باید تحویل داده شود. همچنین اگر در زمان انتشار ویدیو چندین رشته جریان در حال عبور باشد، این صف ممکن است از صف ارسال جلو بزند. با وجود بسته‎های ترمیمی‎ در این صف یک حالت پایدار به وجود می‎آید. اگر این مقدار به اندازه‎ای نباشد که بتواند بافر را سر ریز کند، هیچ بسته‎ای از بین نمی‎رود و کنترل تراکم TCP نیز اتفاق نخواهد افتاد. اما زمان تاخیر برای تمام کاربران این بافر افزایش پیدا خواهد کرد.

مدیریت بافرها

برای مدتی عقیده بر این بود که باید صف درخواست‎های شبکه را مدیریت کرد. برای اولويت دادن به یک ترافیک خاص می‎توان بیت‎های IP layer diffserv را به گونه‎ای تنظیم کرد تا به انواع خاصی از ترافیک مثل کنترل شبکه یا VoIP ارجهیت بالاتری داده شود. آنها این کار را با قرار دادن این ترافیک‎های اولويت‎دار در صف‎های جداگانه انجام می‎دادند. اما انجام این کار از bufferbloat جلوگیری نمی‎کند. بعضی از صف‎هایی که ترافیک بدون اولويت در آن قرار دارد همچنان با مشکل بزرگ شدن بیش از حد مواجه هستند. اینها اغلب شامل سگمنت‎های TCP خیلی بزرگ هستند. بنابراین ما همچنان با مشکل تاثیر منفی مکانیسم تراکم TCP مواجه هستیم.

در سال 2012، کتی نیکولز و ون جیکوبسن یک تکنیک به نام CoDel یا Controlling Queue Delay را معرفی کردند. این شیوه با ردگیری زمانی که یک بسته در صف قرار دارد این صف را مدیریت می‎کند، چرا که مدت زمان اشغال یک صف مسئله بسیار مهمی‎ است. دو پارامتر فاصله و آستانه از اهمیت بسیار بالایی برخوردار هستند. اگر تاخیر فاصله بین بسته‎ها طولانی‎تر از مقصد باشد، بسته‎ها به طور تصادفی شروع به از بین رفتن می‎کنند. توجه داشته باشید که این تکنیک به اندازه صف‎ها و tail-drop وابسته نیست. نتایج آزمايشات انجام گرفته نشان می‎دهد که در حالت کلی وضعیت تاخیر در پاسخ‎دهی در این شیوه بهتر از تکنیک RED م(Random Early Discard) رفتار می‎کند و نتایج کلی به مراتب بهتر است. این موضوع در زمان استفاده از لینک‎های بی‎سیم بیشتر دیده می‎شود.

توصیه بعدی برای کاهش تاثیر پدیده bufferbloat توسط دیو تات، اریک دومازت، جیم گتیز و چند نفر دیگر مطرح شده است. نام این شیوه fq-codel است و هدف از آن ایجاد یک تاثیر یکنواخت‎تر در جریان‎های عبوری از طریق صف‎ها است. حتی کتی نیکولز و ون جیکوبسن نیز تاثیرات مثبت استفاده از fq-codel را تایید کرده‎اند. این شیوه به طور پیش فرض صف‎ها را به زیر شاخه‎های 1024 تقسیم می‎کند. سپس به طور تصادفی به هر جریان جدید یک صف جداگانه اختصاص می‎دهد. داخل هر زیر شاخه از Codel برای کمک به کنترل تراکم TCP استفاده می‎شود.

Codel و fq-codel چه کاری انجام می‎دهند؟

اول، این دو تکنیک وظیفه نظارت بر انجام صحیح عملیات کنترل تراکم TCP را بر عهده دارند. دوم، با ترکیب بسته‎های موجود در صف‎ها، باعث می‎شوند تا بسته‎های کوچک ضروری مثل پاسخ‎های DNS و نشانه‎های TCP در دام صف‎های طولانی گرفتار نشوند. به عبارت ديگر، با استفاده از این شیوه نحوه برخورد با بسته‎های بزرگ و کوچک با تساوی بیشتری انجام خواهد شد. تحقيقات زیادی نشان داده است که مزایای استفاده از fq-codel به مراتب بیشتر است. fq-codel تنها در آخرین توزیع‎های لینوکس به کار گرفته شده است.

آینده به چه سمتی پیش خواهد رفت؟

متاسفانه آگاهی از وجود پدیده bufferbloat هنوز فراگير نشده است. ما به اپراتورهای شبکه و کاربران بیشتری نیاز داریم تا از آزمون‎های در دسترسی مثل ICSI Netylyzr و www.DSLReports/speedtest/ استفاده کنند. بعد از انجام این آزمايشات در صورتی که به میزان قابل ملاحظه‎ای از مشکلات bufferbloat برخورد کردید، می‎توانید از چندین روش جایگزین استفاده کنید:

1- دسترسی سخت‌افزار خود را به دستگاه‎هایی که از یک توزیع جدید لینوکس مجهز به fq-codel استفاده می‎کنند تغییر دهید. اطمینان حاصل کنید که این قابلیت فعال باشد.

2- یک دستگاه بین کامپیوتر و روتری که قابلیت fq-codel در آن فعال است قرار دهید. این کار باعث محدود شدن استفاده از بافرهای حجیم روتر می‎شود.

3- اگر تمام موارد مطرح شده با شکست مواجه شد، روی لینک‎های آپلود و دانلود محدودیت نرخ تبادل به میزان کمی‎ کمتر از نرخ ظرفیت آنها اعمال کنید. این کار کمک می‎کند تا از تشکیل بافرهای حجیم جلوگیری شود. انجام این کار اگرچه ممکن است در بارهای کاری سبک به میزان اندکی‎ توان عملیاتی را کاهش دهد، اما به شکل قابل ملاحظه‎ای وضعیت جریان‎های ضروری مثل تاییدیه‎های DNS ، ARP و TCP را بهبود مي‎بخشد.

در حال حاضر چندین فروشنده تجهيزات شبکه مشتاق برای کاستن از اثرات مخرب bufferbloat وجود دارد. سیسکو طی یک همکاری مشترک با کامکست، یک تکنیک مدیریت صف به نام  PIEو(Proportional Integral controller Enhanced) را توسعه داده است.

Time-Warner Cable نیز گام‎های مثبتی را در جهت کم کردن اثرات bufferbloat برداشته است. Actiontec که یک تامین کننده عمده برای شاهراه‎های محلی Verizon و Centurylink است، تحقيقاتی زیادی در مورد bufferbloat کرده است. آنها مدعی هستند پیشرفت‎های زیادی در راه کم کردن تاثیرات این پدیده داشته‎اند. اما برخی از فروشندگان دیگر نیز هستند که به نظر می‎رسد اطلاع چندانی از bufferbloat ندارند. این وضعیتی است که باید هر چه زودتر تغییر کند. بسیار حیاتی است که یک درک همه جانبه از این موضوع شکل گیرد که نتیجه کلی به ویژه در فعالیت‎هایی مثل وبگردی، مهمترین عامل ضرر و زیان نیست. بلکه اصلی‎ترین عامل تاخیر در تبادل است.

پاسخ‎های دریافتی از فرامین HTTP GET اغلب به شکل حجم انبوهی از انتقالات فایل‎های کوچک انجام می‎شود که در آن فرآیند شروع کند به ندرت اتفاق می‎افتد. بنابراین تاخیر در برقراری و خاتمه session ها به یک تاثیر مخرب قابل توجه در مدت برقراری این sessionها تبدیل می‎شود. همچنین یک بازدید معمولی از یک وب‎سایت معروف می‎تواند دائما بین 10 تا 25 پرسش و پاسخ DNS را به همراه داشته باشد که اگر به واسطه bufferbloat سرعت آن کم شود این کندی کاملا به چشم خواهد آمد.