در سال ۲۰۱۰ یک برنامه‌نویس کهنه‌کار کامپیوتر به نام جیم گتیز که کاشف علت کاهش سرعت اینترنت است و در حال حاضر نیز در گوگل مشغول کار است، در خانه نصب فایل بزرگ به سرور محل کار خود بود. در همین حین فرزندانش به اتاق کار آمدند و از سرعت پایین اینترنت شکایت کردند.

تعجب این بود که چگونه کار آپلود او می‌تواند روی سرعت دانلود کودکانش تاثیر داشته باشد، به همین دلیل است که شروع به بررسی کرد و نتیجه تحقیقات او به کشف پدیده مخرب و ناشناخته ‏ای به نام bufferbloat تبدیل شد.

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

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

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

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

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

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

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

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

بعد از این هر چهار سگمنت نشان می دهد که ارسال می کند، گیرنده با ارسال هشت سگمنت نرخ سرعت ارسال را می دهد و در انتظار دریافت می کند. بعد از تایید این سگمنت‌ها به همین ترتیب با نرخ ارسال به ۱۶ و بالاتر میابد.

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

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

این مطلب رو هم بخونید: روش های عیب یابی مودم ADSL

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

حالا اگر این بافر بزرگ باشد ممکن است رخ دهد: اول، اگر بافر شود، آخرین بسته شده از بین می‌رود. به این اتفاق tail drop گفته می شود. نشانه ای است که این از بین رفتن بسته را به ارسال کننده اطلاع می دهد تا زمان بسته شدن بعدی ارسال شود و در چنین شرایطی عملی این پیام غیر قابل استفاده خواهد بود.

گذر این روند از بین یک بافر بزرگ زمان قابل مشاهده را تلف می‌کند. آزمایشات انجام شده روی بیت ریت‌های تطبیقی ​​ویدیو نشان می‌دهد که قبل از این که سگمنت از بین برود دوباره ارسال کند به ۲۰۰ سگمنت باید تحویل داده شود. همچنین اگر در زمان انتشار ویدیوی چندین رشته جریان در حال عبور باشد، این صف ممکن است از صفحه ارسال جلو بزند. با وجود بسته های ترمیمی در این صف یک حالت پایدار به وجود می‌آید. اگر این مقدار به اندازه‌ای نباشد که بافر را سر کند، هیچ بسته‌ای از بین نمی‌رود و کنترل تراکم TCP نیز نخواهد افتاد.

اما زمان زمان برای تمام کاربران این بافر افزایش پیدا خواهد کرد.

برای مدتی عقیده بر این بود که باید درخواست‌های شبکه را مدیریت کرد. برای اولویت دادن به یک ترافیک خاص می‌توان بیت‌های IP لایه diffserv را به گونه‌ای تنظیم کرد تا به انواع خاصیت از ترافیک مثل کنترل شبکه یا VoIP ارجهیت بالاتری داده است. آنها این کار را با قرار دادن این ترافیک، اولویت‌های دار در صف‌های انجام شده می‌دادند.

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

در سال ۲۰۱۲، کتی نیکولز و ون جیکوبسن یک تکنیک به نام CoDel یا Controlling Queue Delay را معرفی کردند. این شیوه با ردگیری زمانی که یک بسته در صف قرار دارد این صف را مدیریت می کند و به این ترتیب سرعت اینترنت از بین خواهد رفت، چرا که مدت زمان اشغال یک صف بسیار مهم است.

دو فاصله و آستانه از بسیار زیاد هستند. اگر فاصله‌ای بین بسته‌ها از مقصد باشد، بسته‌شده‌ها به طور تصادفی شروع به بین رفتن می‌کنند. توجه داشته باشید که این تکنیک به اندازه صفات و tail-drop وابسته نیست.

آزمایشات انجام شده نشان می دهد که در حالت وضعیت تغییر در پاسخ دهی در این روش بهتر از تکنیک RED م(Random Early Discard) رفتار می کند و نتایج کلی به مراتب بهتر است. این موضوع در زمان استفاده از لینک‌های بی‌سیم بیشتر دیده می‌شود.

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

این شیوه به طور پیش فرض صفها را به زیر شاخه ۱۰۲۴ تقسیم می کند. سپس به طور تصادفی به هر جریان جدید یک صف اختصاصی می‌دهد. داخل هر زیر شاخه از Codel برای کمک به کنترل تراکم TCP استفاده می‌شود.

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

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

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

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

۳- اگر تمام موارد ذکر شده با شکست مواجه شد، روی لینک‌های موجود و دانلود نرخ تبادل به میزان کمی کمتر از میزان عملکرد آنها انجام می‌شود. این کار کمک می کند تا از تشکیل بافرهای حجیم جلوگیری شود. انجام این کار بسیار سبک ممکن است به میزان اندکی توان عملیاتی را کاهش دهد، اما به شکل قابل ملاحظه‌ای در وضعیت جریان‌های مورد تایید مثلیه‌های DNS، ARP و TCP را بهبود می‌بخشد.

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

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

اما برخی از فروشندگان دیگر نیز هستند که به نظر می‌رسد بیشتر از bufferbloat ندارند. این وضعیت است که باید هر چه زودتر تغییر کند. بسیار حیاتی است که یک برداشت همه جانبه از این شکل می گیرد که نتیجه کلی به فعالیت هایی مثل وبگردی، عامل اصلی ضرر و زیان نیست. اما اصلی ترین عامل تغییر در تبادل است.

پاسخ‌های دریافتی از فرامین HTTP GET به شکل حجم آنبوهی از انتقال فایل‌های کوچک انجام می‌شود که در فرآیند شروع به کار می‌افتد. تا حدودی در نشست و برخاسته‌ها به یک تأثیر مخرب توجه می‌شود که مدتی باعث ایجاد این جلسه شود و سرعت اینترنت را کاهش دهد.

اگر دوست داشتی امتیاز دادن یادت نره!