شخص واحد يرفع ملفاً كبيراً، فتتقطع مكالمة الفيديو، ويبطؤ نظام الفواتير، ويشكو الجميع من «ضعف النت». لكن السرعة لم تتغير. ما تغير هو زمن الانتظار داخل الأجهزة، وهذه الظاهرة اسمها bufferbloat.
الخبر الجيد أن RouterOS v7 يوفر أدوات قوية لعلاجها، مثل fq-codel وCAKE. والخبر الأصدق أن هذه الأدوات لا تفيد في كل مكان، وقد جربنا ذلك بأنفسنا.
ما هو bufferbloat؟
عند امتلاء الخط، تتكدس الحزم في مخزن مؤقت عند أضيق نقطة. فيطول الطابور، وتنتظر كل حزمة دورها، حتى حزمة صغيرة لمكالمة. ولا تخسر الحزمة، بل تتأخر، وهذا سبب الغرابة: ping ممتاز في الهدوء، وسيئ وقت التحميل.
العلاج هو أن تنقل الطابور من جهاز لا تتحكم فيه إلى راوترك. فتضبط السرعة قليلاً تحت سعة الخط، فيبقى الطابور عندك، وتديره بخوارزمية ذكية.
قس قبل أن تعدّل
القياس بسيط. أرسل ping متواصلاً إلى هدف ثابت، مثل طرف النفق 10.66.66.1، ثم شغّل تحميلاً كبيراً، ثم رفعاً كبيراً، وقارن:
/ping 10.66.66.1 count=30إن زاد الزمن بوضوح تحت الحمل وعاد في الهدوء، فهذه علامة bufferbloat. وللمقارنة، سجلنا زمن وصول نحو 6ms عبر النفق محلياً على أحد سيرفراتنا، وهو رقم يخص ذلك المسار لا مسارك. أما إن بقي الزمن مرتفعاً حتى في الهدوء، فالعلة مختلفة، وغالباً في المسار أو الخط.
| نوع الطابور | الفكرة | متى تختاره |
|---|---|---|
| FIFO | من يصل أولاً يخرج أولاً | الافتراضي البسيط، ولا يعالج المشكلة |
| fq-codel | عزل التدفقات وضبط التأخير | حل خفيف نسبياً وفعال كثيراً |
| CAKE | عدالة بين الأجهزة والتدفقات مع خيارات واسعة | حين تريد إعداداً شاملاً ويتحمله المعالج |
تطبيق CAKE خطوة بخطوة
لنفترض خطاً بسرعة 100 ميجابت تنزيلاً و20 ميجابت رفعاً، وهذه أرقام توضيحية لا قياس. اضبط الحد عند نحو 90% من السعة التي قستها فعلياً، ثم عدّل بالتجربة:
/queue type add name=cake-default kind=cake cake-bandwidth=0 cake-nat=yes
/queue simple add name=internet-cake target=192.168.88.0/24 \
max-limit=18M/90M queue=cake-default/cake-defaultفي max-limit الرقم الأول للرفع والثاني للتنزيل. ونترك cake-bandwidth=0 لأن الطابور البسيط هو الذي يحدد السرعة، فلو ضبطتهما معاً لمر الترافيك عبر مشكّلين. وقيمة cake-nat=yes مفيدة حين يطبق الراوتر NAT، فتميز CAKE الأجهزة الداخلية.
وإن أردت البديل الأخف، فاستبدل النوع، وأبقِ الطابور نفسه:
/queue type add name=fq-default kind=fq-codel
/queue simple set internet-cake queue=fq-default/fq-defaultالفخ الذي يبطل كل شيء: FastTrack
هنا يقع كثيرون. الترافيك المسرّع عبر FastTrack يتجاوز الطوابير البسيطة، فلا يعمل ما ضبطته رغم صحة الإعداد.
/ip firewall filter disable [find action=fasttrack-connection]
/queue simple print statsتعطيل FastTrack يزيد الحمل على المعالج، فراقبه بالأمر /tool profile تحت الحمل. ولو بلغ المعالج حدوده فستسوء النتيجة، وعندها خفف الإعداد إلى fq-codel أو خفّض السرعة المستهدفة. والبديل أن تربط Queue Tree بواجهة مباشرة، لأن التوثيق يذكر أنها تعالج ترافيك FastTrack.
ماذا يحدث داخل نفق WireGuard؟
بعد التشفير يبدو ترافيك النفق كله تدفق UDP واحداً في نظر طابور WAN. فلا يستطيع CAKE هناك أن يفرق بين المكالمة والتحميل. ولهذا طبّق الطابور قبل التشفير، على شبكة LAN كما في المثال، فيرى التدفقات الحقيقية.
ويجب أن تخصم من الحد ما تضيفه ترويسة النفق. فالحزمة تكبر بعد التغليف، فاترك هامشاً أوسع قليلاً حين يعبر معظم ترافيكك النفق.
ماذا وجدنا في اختبارنا؟
لأن الموضوع يُبالغ فيه كثيراً، إليك تجربتنا كما هي. اختبرنا على أحد سيرفراتنا shaper بـcake عند 465Mbps على 3 جولات متناوبة. النتيجة: لا فرق واضح، فلم نعتمده.
هذا لا يعني أن CAKE بلا فائدة. فمكانه الطبيعي عند الخط المزدحم، حيث يتكون طابور حقيقي، كراوتر مكتب على خط ضيق. أما حيث لا يوجد اختناق فعلي بالنمط نفسه، فلن تحصل على مكسب. الدرس أن تضيف الأداة بعد أن تثبت الحاجة إليها.
وهناك نقطة مرتبطة بـBBR. ففي قياس Ookla عبر TCP على منفذ بحد policer، ارتفع الرفع من 154-177Mbps إلى 365-444Mbps بعده. لكن BBR يخص TCP، وWireGuard يعمل على UDP، فهو لا يسرّع النفق مباشرة.
وانتبه إلى قراءة الرسوم. فلوحات المراقبة في Proxmox تعرض متوسطات، فقد يظهر 60MB/s لمدة 10 ثوانٍ كقيمة أقل بكثير. ولهذا لا تحكم على طابورك من الرسم وحده، بل من قياس مباشر.
قائمة تحقق سريعة
- قس زمن الوصول في الهدوء وتحت الحمل، في الاتجاهين.
- اضبط الحد تحت السعة الفعلية، لا المعلنة.
- طبّق الطابور قبل التشفير إن كان عندك نفق.
- عطّل FastTrack للترافيك الذي تريد تشكيله.
- راقب المعالج، فالعلاج المكلف قد يصبح مشكلة جديدة.
- أعد القياس، واحتفظ بالتغيير إن أثبت فائدته.
وتذكر أن القرب ليس كل شيء. فخط منظم مع سيرفر قوي يعطي تجربة أفضل من سيرفر قريب مرهق، لأن الطوابير تتكون عند أي نقطة ضعيفة في الطريق.
كيف تضبط الحد عملياً؟
لا تبحث عن الرقم الكامل من أول محاولة. ابدأ بحد منخفض، وستجد أن زمن الوصول يتحسن بوضوح إن كانت المشكلة حقيقية. ثم ارفع الحد تدريجياً، وأعد القياس بعد كل تغيير، وتوقف حين يبدأ الزمن بالارتفاع تحت الحمل.
ولا تنس أن سعة خطوط المشتركين قد تتغير خلال اليوم. فالخط الذي يعطي سعته كاملة صباحاً قد يتراجع مساءً في وقت الذروة. لهذا قس في أسوأ الأوقات، لا في أفضلها. فالحد المضبوط على أفضل حالة لن يحميك حين تزدحم الشبكة، لأن الطابور سيعود إلى جهاز خارج سيطرتك.
وتتيح CAKE أيضاً خيار cake-autorate-ingress لتقدير السعة من أزمنة وصول الحزم. لكن التوثيق ينبه إلى أنه يضبط مشكّل CAKE الداخلي لا max-limit، فلا تفعّله مع طابور بسيط يتولى تحديد السرعة، واختبره على خطك الفعلي قبل الاعتماد عليه.
وابدأ بسيطاً. الإعداد الافتراضي مع cake-nat=yes يكفي أغلب المكاتب. أما التصنيف المتقدم مثل cake-diffserv=diffserv4 فلا ينفع إلا إذا كانت علامات DSCP موثوقة في شبكتك. وإن لم تكن كذلك، فأنت تضيف تعقيداً لا فائدة منه.
حدود القياس: اختبار cake أعلاه أُجري على سيرفر، لا على MikroTik. ولم نقس سرعة أي جهاز MikroTik مع CAKE، فلا نعطي رقماً لذلك. جرّب على جهازك، وعند أوقات الضغط الفعلية عندك.
الخلاصة
قس أولاً، ثم انقل الطابور إلى راوترك، وعالج FastTrack، واختر الأداة التي يتحملها جهازك. وإن لم تجد فرقاً، فلا تُبقِ التعقيد بلا سبب.
وعلى طرف السيرفر، يهمك أن يكون المسار نظيفاً والموارد كافية. وسيرفرات مرام تساعدك على هذا بخيارات تناسب حجم ترافيكك. وتتوفر لدينا خيارات منافذ بسرعات أعلى تصل إلى 100 جيجابت حسب التوفر والموقع، ونؤكد التفاصيل قبل الطلب.
