هل تعاني من بطء الانترنت؟ إليك الأسباب الخفية لهذه الظاهرة المزعجة

ففي العام 2010، كان مبرمج الكمبيوتر المتقاعد جيم غيتيز – يعمل اليوم في جوجل Google -، يرفع ملفاً ضخماً من حاسوبه المنزلي إلى خوادم العمل.

وقتها جاء أطفاله وأخبروه بأن اتصال الانترنت بطيء، حينها بدأ يفكّر في العلاقة بين ما يقوم به وبين سرعة الانترنت لدى أطفاله.

وبعد تجربة أوامر ping وعدة مستويات من التحميل على سرعة الانترنت لديه، تبيّن لغيتيز أن فترات الاستجابة تتأخر بمقدار 4 إلى 10 أضعاف عن الوقت المتوقع لها. وقد قام فيتيز بتسمية هذه الظاهرة باسم “اكتظاظ الذاكرة الوسيطة”، مستنتجاً أنّ قدراً كبيراً من حِزَم البيانات كان يُعاق في ذاكرة وسيطة أكبر من المعتاد.

ومنذ أن نشر غيتيز ملاحظاته هذه، قام باحثون من شركات عدّة، – مثل سيسكو وجوجل وبعض الجامعات البحثية الكبيرة وبعض المجموعات المتخصصة في مجال التقنية مثل “فريق مهام هندسة الانترنت” -، بفحص واختبار هذا “الاكتظاظ في الذاكرة الوسيطة”، وكتابة العديد من التقارير عنه.

وأجريت بعض الاختبارات البسيطة، ليستنتج بعدها أنه هذا الأمر حقيقيّ. إلا أن الشيء الغامض هو مدى تأثير اكتظاظ الذاكرة الوسيطة على التدفق الطبيعي لاتصال الانترنت.

ربما تتساءل الآن: من أكثر المتأثرين بهذه الظاهرة؟ الجواب بسيط. أي متصفح للانترنت أو محرّكات البحث. أي مستخدم لتطبيقات الوقت الفعليّ (مثل تطبيقات الفيديو والصوت).

على سبيل المثال، الموظفون الذين يعملون من المنزل، أثناء استخدام المواصلات، في الفنادق، أو عبر نقاط شبكات WiFi. وقد توصّل الباحثون إلى أن الفنادق ومقاهي WiFi هي من أكثر الأماكن عُرضَةً لأسوأ مظاهر اكتظاظ الذاكرة الوسيطة.

أي أنواع الحركة عبر الانترنت تتأثر بهذه الظاهرة؟

ستصاب بالتدهور أي حركة متدفّقة عبر الروابط التي تعتمد في طرفها الآخر على نطاق تردد عالٍ. وكذلك الأمر بالنسبة للتطبيقات التي تستخدم حِزَماً صغيرة من أمثلة “الصوت عبر الانترنت” VoIP، “نظام أسماء النطاقات” DNS، و”بروتوكول تحليل العناوين” ARP. والتأثير على اتصالات الصوت عبر الانترنت VoIP يكون في صورة فترات استجابة طويلة مع عدم انتظام في الإشارة الالكترونية.

كيف أمكن لهذه المشكلة الحقيقية التي تؤثر على طبيعة عمل الانترنت أن تخفى علينا طوال هذا الوقت؟

هناك 3 أسباب أساسيّة؛ أولاً: أن هذا الأمر مرتبط بكيفيّة عمل بروتوكول ضبط الإرسال، وكيفية إدارة الذاكرة الوسيطة للشبكات. وكلا الأمرين لم يتم توصل بعد إلى فهم معمّق لهما.

ثانياً: هناك اعتقاد سائد أن خفض الحِزم هو أمر سيء؛ إلا أن الحقيقة أن هذا الأمر ضروريّ من أجل عمل بروتوكول ضبط الإرسال بكفاءة.

ثالثاً: هنالك قناعة كبيرة أن السبيل إلى التغلّب على تدهور أداء الاتصال هو إضافة المزيد من سعة الاتصال (باندويدث).

إذاً، ما هو تحديداً “اكتظاظ الذاكرة الوسيطة”؟

في محاولة لتقليل فقدان الحِزم المنقولة عبر الانترنت، يقوم مزوّدو الخدمة والمطورون ومهندسو الكمبيوتر بزيادة أعداد الذاكرة الوسيطة للشبكات عدة أضعاف. وهذا يؤدي بدوره إلى طول فترة الاستجابة، إلا أنه قليل التأثير على سرعة وإنتاجية الاتصال.

وبالتالي، فإن الحِزم الصغيرة الموجودة في VoIP وDNS وTCP يمكنها أن تقع في الذاكرة الوسيطة المتواجدة خلف الحِزم الأكبر، من نواقل الملفات والنواقل الضخمة الأخرى، مثل فيديوهات النقل التكيّفي adaptive bitrate video.

وهذه مشكلة تتعلق بإدارة الذاكرة الوسيطة؛ فالاختبارات و”الأوراق البيضاء”، وحتى التعليمات، عادةً ما تصف الذاكرة الوسيطة بأنها أجزاء صغيرة من الذاكرة. ومن المعتاد أيضاً أن هذه الذاكرة الوسيطة يمكنها أن توقف مئات أو آلاف حِزَم البيانات في أيّة لحظة.

وهذه الذاكرة الوسيطة لا تتواجد فقط في أجهزة الشبكات، وإنما أيضاً في مشغّل بطاقة الشبكات، مجموعة بروتوكولات محطّة الوصول، وأيّ ممر يصل بين محطات الوصول هذه.

ما تأثير “اكتظاظ الذاكرة الوسيطة” على عمل بروتوكول ضبط الإرسال؟

الغالبية العظمي من حركات المرور الشبكيّة التي نستخدمها تقوم بتوظيف بروتوكول ضبط الإرسال TCP كبروتوكول النقل. وفهمنا لطبيعة عمل هذه البروتوكول يوضح لنا لماذا يعتبر اكتظاظ الذاكرة الوسيطة مشكلة بالأصل. فعند نشأة اتصال عبر TCP يكون هناك تعارف ثلاثيّ الأبعاد، ينسّق من خلاله البروتوكول المرسِل والمستقبِل ضوابط التبادل، بما في ذلك أرقام التسلسل الأوليّ.

دعنا نفكر أن أن أحد خوادم بروتوكول نقل الملفات FTP يطلب نقل ملف كبير الحجم. عادةً ما سيبدأ بروتوكول ضبط الإرسال TCP عملية الإرسال عبر 4 قطاعات، منتظراً تأكيد التسليم. وسياسية التأكيد المتّبَعة تتم عبر إرسال “تأكيد” مرَّةً في كل قطاعَين. وعند تأكيد تسليم القطاعات الأربع، فإن المستقبِل يزيد من سرعة الإرسال، إذ يقوم بإرسال 8 قطاعات، منتظراً تأكيد استلامها أيضاً. ثم يزيد المعدّل إلى 16 قطاعاً، وهكذا.

ويُشار إلى هذه المرحلة من التوصيل بـ “البداية البطيئة”. والفكرة وراء هذه العمليّة، هي تشبيع الروابط بين حِزم البيانات. لكن في مرحلة تسمّى “عتبة البداية البطيئة”، يقوم المرسل بزيادة معدل الإرسال بشكل أبطأ، عبر إضافة قطاع واحد في كل دورة بدلاً من مضاعفة المعدّل كما ذكرنا سابقاً.

وبالرغم من هذا، فهناك لحظة حرجة يصبح فيها الاتصال مُتخماً بسبب امتلاء الذاكرة الوسيطة. حينها تُفقَد حِزمة بيانات أو أكثر.

حين يكتشف المرسِل حدوث هذا، فإنه يقوم بتقليص معدل الإرسال إلى النصف، ويعيد الشروع في “بداية بطيئة”. وفي نهاية المطاف، فإن معدّل عمل بروتوكول ضبط الإرسال TCP يتواءم مع سعة الدائرة المتاحة. هذه الخطوات مجتمعة تعرف باسم “خوارزمية التحكّم في ازدحام TCP”.

إذاً كيف ينشأ اكتظاظ الذاكرة الوسيطة؟

لنتخيّل اتصالاً بين رابطين مختلفي السرعة، أحدهما بطيء والآخر سريع. هذا الاتصال تكون فيه الذاكرة الوسيطة الشبكيّة فائقة الأهمية. ومن أمثلة هذا النوع من الاتصال ذلك الذي يكون بين طرف بسرعة 1 غيغابايت/ثانية وطرف ذو اتصال كابلي أو مودم. وربما يتصل المودم بمزوّد خدمة متباين الأداء بين تحميل ورفع الملفات (10 و2 ميغابايت على الترتيب).

خوادم بروتوكول نقل الملفات ستقوم بتعبئة الذاكرة الوسيطة المرتبط بالاتصال الفائق بسرعة أكبر من معدل انبثاق البيانات إلى الاتصال البطيء.

وهذا المعدل الذي تصله تأكيدات تسليم النقل هو الذي يحدد معدلَ النقلِ المتاحَ للمُرسِل.

لكن لو كانت الذاكرة الوسيطة أكبر، فقد يحدث شيئان؛ أولهما، إذا امتلأت الذاكرة الوسيطة فإن آخر حِزمة بيانات سيتم إغفالها، وهو ما يسمّى “إسقاط الذيل” tail drop. تأكيد الاستلام الذي يخبر المرسِل بهذا الإسقاط لن يتم إرساله إلا عندما تصل الحِزمة التالية ويتأكّد أنها غير صالحة. وقد يمرّ وقت طويل حتى تمرّ عبر ذاكرة وسيطة كبيرة، فبعض التجارب التي أجريت على “فيديو معدل النقل التكيّفي” تشير إلى أن ما يقارب 200 قطاع يتم توصيلها قبل أن تقوم محطة الإرسال بإعادة نقل القطاعات المُهمَلة.

وكذلك، فلو كانت هناك عدة تدفقات في الصف الواحد، فإنه قد يتحوّل إلى صفّ عالِق. ومعنى هذا أنه قد يصل إلى حالة من الثبات، بحيث يكون هناك عدد ثابت تقريباً من حِزم البيانات في الصف. لو كان هذا العدد غير كافٍ لملء الذاكرة الوسيطة، فإن حِزم البيانات تسقط وتتراجع خوارزمية التحكم في ازدحام TCP. إلا أن الأبحاث تشير إلى أن فترات الاستجابة قد زادت عند كافة مستخدمي الذاكرة الوسيطة.

إدراة الذاكرة الوسيطة

لفترة من الزمن، أدرك الجميع أن الصفوف الشبكيّة يجب أن تتم إدارتها. ولإضافة أولوية إلى بعض الحركات المرورية عبر الانترنت، فمن الممكن ضبط أجزاء الخدمات المميزة في طبقة بروتوكول الانترنت IP layer DiffServ bits لتقوم بإعطاء أفضلية لأنواع محددة من الحركة المرورية، من عيّنة التحكّم الشبكي أو “الاتصال الصوتي عبر الانترنت” VoIP. ومع ضبط هذه الأجزاء، فإنها عادة ما تنجز مهمتها عبر فصل هذه الحركات ذات الأولويّة ونقلها إلى صفوف خاصة.

لكن هذا لا يقضي على الاكتظاظ في الذاكرة الوسيطة. إذ إن بعض هذه الصفوف التي تضم الحركات المرورية غير ذات الأولوية تظل تعاني من إشكاليّة كونها كبيرة الحجم. وعادة ما تحوي هذه الصفوف الكثير من قطاعات TCP الضخمة. ولذلك فإننا لا زلنا نعاني من نفس مشكلة التأثير السلبي على آلية معالجة ازدحام TCP.

العديد من تقنيات “إدارة الصفوف النشطة” AQM تضم الكشف العشوائي المبكّر RED والكشف العشوائي المبكّر الموزون Weighted RED. وقد جرى تصميم هذه التقنيات من أجل نبذ الحِزم حين تصل الذاكرة الوسيطة إلى مستويات حرجة قبل امتلائها تماماً. ولكن هذه التقنيات لا زالت منقوصة، وقد ثبتت صعوبة تهيئة الكشف العشوائي المبكّر RED. وبالتالي فإن طريقتي الكشف هاتَين لا يجري توظيفهما على نطاق واسع. وقد كانت الحاجة تستدعي وجود طريقة آلية، وليس طريقة تحتاج إلى ضبط وتهيئة.

في العام 2012، قامت كلٌّ من كاتي نيكولس وفان جاكوبسن بالترويج لتقنية تدعى CoDel أو “التحكم في تأخر الصفوف”. وقد كان بإمكان هذه الطريقة إدارة الصف/الرتل بتتبع الوقت الذي تكون خلاله حزمة البيانات داخل الصف، إذ أن هذا الوقت يعتبر أهم مسألة في الأمر.

وهناك مؤشران على قدر من الأهمية: المجال والعتبة. لو تأخّر قدرٌ من الحِزم يساوي قيمة المجال، فإن تلك الحِزم تتساقط بشكل عشوائي. علينا أن نتذكر أن هذه التقنية لا تعتمد على حجم الصفوف أو الأرتال، وكذلك لا علاقة لها بـ”إسقاط الذيل”.

ومع اختبار الإجراءات، تم التوصل إلى سلوك استجابة أفضل من الكشف العشوائي المبكّر RED، مع نتائج أفضل بكثير. وقد كان هذا الأمر أوضح مع الروابط اللاسلكية. وقد كانت هذه التقنية أسهل في دمجها مع أجهزة وعتاد الحواسيب.

التوصية الأخرى من أجل التغلب على اكتظاظ الذاكرة الوسيطة يقدّمها ديف تاهت وايريك دومازيت وجيم غيتيز وآخرون. وقد أطلقوا عليها اسم “التأخير المحكوم والمصفوف بإنصاف” fq_CoDel، وغرضها تقديم تأثير موحّد للتدفقات المتعددة عبر الرتل. حتى كاتي نيكولس وفان جاكوبسن قاما بالترويج لاستخدام fq_CoDel.

وتقسّم هذه الطريقة الرتل افتراضيّاً إلى 1024 رتلاً فرعيّاً sub-queues. مِن ثَمّ تقوم بالتوزيع العشوائي لكل دفقة جديدة على صفّ منفصل. ومع كلّ صف أو رتل فرعيّ، يجري تطبيق تقنية CoDel من أجل إدارة ازدحام TCP. وتقوم سياسات السحب (حذف العنصر من الرتل de-queue) على أساس “عجز التخصيص الدوري” Deficit Round Robin, DDR.

ماذا يفعل “التأخير المحكوم” CoDel وذاك “التأخير المحكوم والمصفوف بإنصاف” fq_CoDel؟

أولاً، يقومان بالتأكد من أن التحكّم في ازدحام TCP تعمل كما ينبغي. ثانياً، عبر مزج الحِزم في صفوف، فإن الحِزم الصغيرة فائقة الأهمية مثل استجابات DNS وتأكيدات TCP لا تنحشر في صفوف كبيرة. وبمعنى آخر، يتم إلى حدٍّ ما مساواة التعامل مع الحِزم الكبيرة والصغيرة.

ويشير عدد كبير من الأبحاث إلى كثير من الفوائد لاستخدام fq-codel. وفي الواقع فإن fq-codel يأتي في الإصدارات الأخيرة من أنظمة تشغيل لينوكس.

الوِجهة إلى أين؟

مع الأسف، فإن الوعي بمشاكل اكتظاظ الذاكرة الوسيطة ليس بالانتشار الواسع. ونحن بحاجة إلى أن يقوم مشغّلو الشبكات والمستخدمون بإجراء الاختبارات المتاحة فعليّاً مثل ICSI Netylyzr وكذلك الاختبار الموجود على هذا الرابط http://www.DSLReports/speedtest. وإذا اكتشفت اكتظاظاً بالغاً في الذاكرة الوسيطة، فإن أمامك عدة خيارات:

تغيير أجهزة الاتصال إلى أجهزة تستخدم توزيعة لينوكس حديثة تحتوي على fq_CoDel. عليك التأكّد من أن هذه الخاصية تعمل.

قم بوضع جهاز بين حاسوبك والراوتر الذي به خاصية fq_CoDel. سيكون من شأن هذا أن يقلّل من الضغط على الذاكرات الوسيطة كبيرة الحجم في الراوتر.

لو لم تفلح هذه الطرق، يمكنك حينها أن تحدد من معدّل الرفع والتحميل، بما يجعلهما دون القدرة المقرَّرة مسبقاً. سيساعدك هذا على القضاء على كثير من الأعطال في الذاكرة الوسيطة. ربما يكون مقابل هذا تباطؤ في الإنتاجية، إلا أنه سيحسّن بشكل كبير من الدفقات الهامة من أمثلة DNS, ARP وتأكيدات TCP.

هناك العديد من المحاسبين/المورّدين المهتمين جدّاً بالتخفيف من حدّة اكتظاظ الذاكرة الوسيطة. فتقوم سيسكو، بالتعاون مع كومكاست، بتبنّي تقنية إدارة أرتال تُدعَى “الموجّه النسبيّ التكاملي المحسّن” PIE, Proportional Integral controller Enhanced، والذي قامت بتطوير رونج بان، مهندسة الأبحاث في شركة سيسكو.

وتبدو شركة “تيم وارنر كابل” Time-Warner Cable على دراية وخبرة كبيرة بالأمر وعلى استعداد لأن تخطو خطوات هامة في مجال تخفيف اكتظاظ الذاكرة الوسيطة. وقامت عدة شركات أخرى بدراسة هذه الظاهرة، منها أكشن تك، فيريزون، وسنشري لنك؛ وقد ذكروا أنهم يخطون في مجال التخفيف من آثارها السلبية. كذلك تقوم شركة راكيس للاتصالات اللاسلكية Ruckess Wireless بالتعاون مع جونيبر Juniper بتكريس الكثير من جهودها لتحسين الذاكرة الوسيطة ذات العلاقة بروابط الوصول.

إلّا أن بعض المحاسبين/المورّدين الذين سؤلوا عن الأمر لم يكونوا على علم بظاهرة “اكتظاظ الذاكرة الوسيطة”. وقال آخرون، مثل كوكس كابل، إن الأمر يعتمد على مصنّعي عتاد الحواسيب والسليكون. مع الأسف، فإن أكبر مصنّعي معدات اختبار الشبكات ليسوا على دراية بالظاهرة كذلك.

هذا الوضع بحاجة إلى تغيير؛ إذ إنه من الضروري أن ندرك أن الإنتاجية الكليّة ليست هي أهم العوامل الضارة، خاصة عند تصفّح الانترنت. وإنما العامل الأهم هو تأخر الاستجابة.

تكون الاستجابات المصحوبة بأوامر “طلبات العرض في برتوكول عرض النص الفائق” (HTTP GET) عادةً عبارة عن نواقل متقطّعة وقصيرة للملفات short bursty file transfers، حيث لا تبدأ عملية “البداية البطيئة” إلا بعد إنهائها. ولذا، فإن التأجيل في إنشاء وإنهاء الجلسة يصبح ذا تأثير كبير على مدة الجلسة. أيضاً فإن زيارة عادية لموقع شهير يمكنها أن تحوي عادةً ما بين 10 إلى 25 استعلام DNS لكل تبادل استجابة يسبق أوامر GET. لو كانت هذه الاستعلامات أبطأ بثلاثة أضعاف (ما بين 30 إلى 75) وكان مردّ هذا إلى اكتظاظ في الذاكرة الوسيطة، فيمكنك ملاحظة هذا بالطبع.

نهايةً، فإنه ينصح بشدة أن يقوم مشغّلو الشبكات بدراسة الأبحاث الكثيرة المتوافرة عن ظاهرة اكتظاظ الذاكرة الوسيطة. وكذلك فإننا بحاجة إلى اختبار اكتظاظ الذاكرة الوسيطة في الاتصالات الشبكية الهامة، مثل الاتصالات اللاسلكيّة ونقاط الوصول النقّالة. حينها ربما يحتاج القارئ البيانات الناتجة عن هذه الفحوص من أجل نقاشها مع مزوّدي الانترنت أو مورّدي نقاط الوصول اللاسلكيّة الذين يتعاقد معهم.