Eric Dumazet: الطوابير الخفية في Linux

باختصار

• لا يزال Dumazet قيّمًا على Linux في المكدس الشبكي العام وTCP والمقابس (sockets)، متقاسمًا صلاحيات المراجعة والدمج مع مختصين آخرين.
• حدّ TCP Small Queues من حجم البيانات التي يمكن لمقبس واحد تركها أسفل TCP، فقلّص التراكم المحلي دون أن يَعِد بإزالة كل الطوابير على طول المسار.
• جعل sch_fq وتوزيع الإرسال الداخلي فصلَ التدفقات والتحكمَ في توقيت الإرسال قابلَين للتطبيق عمليًا، فيما يحتفظ BBR بتأليف منفصل وتاريخ تطوير خاص به.
• يُظهر عمله اللاحق على الكاش كيف يتحول بضعة بايتات لكل مقبس إلى تكلفة على مستوى أسطول كامل من الخوادم؛ ولا تزال النتيجة معتمدة على الأنوية وبطاقات الشبكة والمشغلين.

قد يخسر الخادم الوقت حتى بعد أن يقرر TCP إرسال البيانات

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

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

إن أشهر أعمال Dumazet استهدفت هذه الفجوة تحديدًا. لم تكن أهمية TCP Small Queues في إزالة الطوابير، بل في تغيير القواعد: ما حجم البيانات التي يحق لمقبس واحد وضعها أسفل TCP، ومن يبني هذا الاحتياط، ومتى يستعيد المرسل حقه في استئناف الإرسال. تقع الآلية في عمق النواة، لكن أثرها تلمسه تطبيقات لن تعرف بوجودها أبدًا.

تاريخ النواة يُظهر صلاحيات Dumazet — وحدودها

أكثر المعلومات موثوقية عن عمل Dumazet يوفرها Linux نفسه: ملفMAINTAINERS، ونقاشات التصحيحات، والوثائق التقنية، والعروض التقديمية، وسنوات من المراجعة العلنية. وتُظهر هذه السجلات مشاركًا قديمًا تشمل مسؤولياته الحالية المكدس الشبكي العام وTCP والمقابس. كما تشير إلى عضويته في اللجنة الفنية الإدارية (Technical Steering Committee) لمؤسسة Netdev Foundation وانتمائه الحالي إلى Google عبر البريد الإلكتروني الخاص بالقيّم.

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

وهذا الحدّ بالذات يُبقي الملف على الأعمال التي يمكن التحقق منها مباشرة. يظهر Dumazet عبر الآليات والقرارات المتخذة في أثناء المراجعة والشروحات العلنية، لا عبر علامة شخصية لمدير تنفيذي. تتجلى أمام القارئ قصة مسؤولية تقنية: مهندس واحد يساعد Linux على استهلاك الموارد المحدودة بشكل أدق، ثم يتحقق مطورون آخرون من النتيجة ويعدّلونها ويختبرونها ويعتمدونها.

في تاريخ إغلاق البحث، ٤ أغسطس ٢٠٢٦، كانت سجلات Linux الحالية تضع Dumazet في عداد القيّمين على المكدس الشبكي العام وTCP والمقابس. وتمنح هذه التعيينات صلاحيات جوهرية: يستطيع القيّم أن يطلب إعادة تصميم واجهة، وأن يرفض تصحيحًا بتكلفة صيانة مستقبلية غير مقبولة، وأن يدمج تغييرًا معتمدًا، وأن يمثل النظام الفرعي في مساره نحو الفرع الرئيسي (mainline) لنواة Linux.

وتُظهر السجلات نفسها أن السلطة موزعة. فبين القيّمين على المكدس الشبكي العام يُذكر David S. Miller وJakub Kicinski وPaolo Abeni؛ وعن TCP يشارك Dumazet Neal Cardwell، في حين تمر التصحيحات المحددة عبر مراجعين ومختصين في المجال المعني. كما يتقاطع العمل على المقابس مع مسؤوليات قيّمين آخرين ومجتمع الشبكات الأوسع.

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

على نطاق أسطول الخوادم، يصبح احتساب المقابس اقتصادًا

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

في هذه البيئة اكتسب عمل Dumazet نتائج اقتصادية. وليس المقصود بعبارة «اقتصاد الخادم» مبلغًا معلنًا من الدولارات الموفرة؛ فهذا التقدير غير موجود. المقصود هو ترجمة الأعباء التقنية إلى نتائج على مستوى الأسطول: كم اتصالًا يتسع له مضيف واحد، وما حصة المعالج (CPU) المتبقية للتطبيق، وكم ذاكرة تحجزها الشبكة، وكم مرة يفوّت فيها الخدمة هدف زمن الاستجابة بسبب طوابير يخلقها الجهاز نفسه.

والأثر عادة غير مباشر. فالمشغل يختار نسخة النواة والتوزيعة وقاعدة جدولة الطوابير وخوارزمية التحكم بالازدحام وإعدادات واجهة الشبكة؛ ولا يدير Dumazet هذه القرارات. يتمثل إسهامه في تغيير الأساس المشترك الذي ينطلق منه المشغلون، بحيث يستطيع مضيف Linux العام احتساب موارد النقل بدقة أكبر.

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

لذلك، قد تؤدي المزايا الصحيحة أداءً سيئًا دون أن تنقض الوعد الأساسي للبروتوكول. فقد تمسك بقدر كبير جدًا من البيانات محليًا، أو تُطلق الحزم في انفجارات مدمرة، أو تخلق تنافسًا حول بنية مشتركة، أو تشغل الكاش بحقول نادرًا ما تُستخدم. ولا يظهر أي من هذا في التعريف المختصر «نقل موثوق».

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

أعاد TCP Small Queues التراكم المحلي إلى سيطرة TCP

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

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

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

سلسلة تصحيحات TCP Small Queues التي نشرها Dumazet في عام ٢٠١٢ أدخلت حدًّا على حجم البيانات التي يمكن لمقبس واحد إبقاءها في الطابور أسفل TCP. فعند استنفاد الحد المحلي كان المقبس يتوقف بدل مواصلة ملء qdisc والسائق. وعندما تُنهي الحزم معالجتها في الطبقات الأدنى، يسمح المكدس للمقبس بالإرسال من جديد.

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

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

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

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

وهذا التمييز يفسر لماذا يستخدم المكدس الشبكي في Linux عدة حلقات تحكم متداخلة. فالإقرارات البعيدة تُظهر التقدم على طول المسار كله، والإنهاءات المحلية تُظهر العمل أسفل طبقة النقل، وإحصاءات qdisc تُظهر التنافس في المجدول، وعدادات السائق وبطاقة الشبكة تُظهر سلوك العتاد. لا تكفي إشارة واحدة؛ وقد جعل TSQ الإنهاء المحلي مفيدًا لكبح الفائض.

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

قلّص TSQ طابورًا خفيًا واحدًا، لكنه لم يحل مشكلة المسار كله

سيكون من المريح وصف TCP Small Queues بأنه التصحيح الذي أزال تضخم المخازن المؤقتة (bufferbloat)، لكن الأدلة لا تسمح بذلك. يستهدف TSQ التراكم المحلي للمرسل أسفل TCP، في حين تبقى الطوابير في qdisc والسائق وواجهة الشبكة وشبكة الوصول والموجهات والمبدلات ونظام المستقبِل. وتواصل التدفقات الأخرى خلق تنافس، كما يمكن للمشغل اختيار إعدادات لا تطابق المسار الحقيقي جيدًا.

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

وهذا الحد مهم للتحليل التقني المسؤول. نادرًا ما يلغي التحسين في البنية التحتية المشكلة نفسها؛ بل في الغالب ينقل نقطة السيطرة، أو يقلل فشلًا معينًا، أو يجعل السلوك المتبقي قابلاً للمراقبة. ويحمل TSQ أهميته لأنه عالج تفاوتًا محددًا بين TCP والطوابير الأدنى، لا لأنه ألغى التخزين المؤقت.

لا تصبح آلية النواة بنية تحتية مشتركة إلا بعد أن تعمل على أجهزة مختلفة جدًا. ويعتمد أثر TSQ على الحد المحلي وأحجام الحزم وسلوك qdisc وطوابير الجهاز وإزاحة التقسيم (segmentation offload) وطبيعة التدفقات. فخدمة تعتمد كثيرًا من الإرسالات التفاعلية القصيرة تحصل على نتيجة مختلفة عن مهمة ضخمة لنسخ البيانات.

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

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

sch_fqحوّل فصل التدفقات وتوقيت الإرسال إلى قواعد مجدول

في عام ٢٠١٣ نشر Dumazet عملًا حول مجدول الطوابير العادلة في Linux، المعروف باسمsch_fq. يحتفظ بحالة التدفقات الفردية ويستخدم بنية مرتّبة زمنيًا لإطلاق الحزم وفق لحظات إرسال مستهدفة. تستطيع التدفقات الجديدة الحصول على الخدمة بسرعة، بينما تنتظر التدفقات المثبتة المدارة بالإيقاع وقتها المحسوب.

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

وبالجمع بين فصل التدفقات والجدولة الزمنية، أنشأsch_fqسطح عمل لتوزيع الإرسال على الزمن (pacing). لم يسوِّ بين جميع التطبيقات ولم يزِل كل طابور، لكنه أعطى النواة سياسة تمنع تدفقًا واحدًا من الاستيلاء على الخدمة المحلية وتحوّل الطوابع الزمنية لطبقة النقل إلى قرارات فعلية بإطلاق الحزم.

من السهل قراءة كلمة «عادل» على نحو أوسع مما يسمح به التطبيق. فـsch_fqيفصل التدفقات ويخدمها وفق قواعده، لكن المعاملة المتساوية في طابور واحد لا تضمن أداءً متساويًا للتطبيقات. فأحجام الحزم وسعة المسار وقدرات المستقبِل وخوارزمية التحكم بالازدحام وإعدادات الإزاحة تواصل التأثير في النتيجة.

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

عمليًا، يمنح الجدولة العادلة (fair queueing) المضيف وسيلة أكثر صرامة لتوزيع الخدمة. فهي تقلل شكلًا من أشكال الهيمنة المحلية وتخلق ظروفًا يمكن فيها لتوزيع الإرسال أن يعمل. وما يزال على المشغل فهم الحمل وبقية المسار؛ فكلمة «fair» نفسها لا تحل صراع المصالح.

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

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

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

ولهذا فإن أحد أهم الحدود الإسنادية في ملف Dumazet يمر بين توزيع الإرسال الزمني والتحكم بالازدحام. التحكم بالازدحام يقرر مدى عدوانية استخدام التدفق للمسار؛ وتوزيع الإرسال يقرر متى يجب أن تخرج البيانات المسموح بها. الآليتان تتعاونان لكنهما ليستا خوارزمية واحدة، والإرسال الموزع بإتقان لن يصحح سرعة مفرطة اختارها نموذج ازدحام خاطئ.

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

يعتمد BBR على توزيع الإرسال الزمني لكنه يحمل تأليفًا خاصًا

كثيرًا ما يُذكر BBR إلى جانب Dumazet، لأن الخوارزمية تحتاج توزيع إرسال دقيقًا، ولأن تطويرها جرى في البيئة الهندسية لشركة Google حيث كان Dumazet مشاركًا بارزًا في Linux TCP. لكن هذا الارتباط لا يجعله المخترع المنفرد لـ BBR. فالخوارزمية لها مؤلفون مسمّون ونماذج وتاريخ إصدارات خاص بها.

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

ينبغي أن يُنسب إلى Dumazet الآليات التأسيسية للطوابير وتوزيع الإرسال الزمني، إضافة إلى إسهامه الأوسع في TCP. وهذا لا يحوّل كل خوارزمية تستخدم الواجهات التي ابتكرها إلى اختراع له. والحد الواضح يحفظ قيمة عمله وإسهام Neal Cardwell ومهندسي التحكم بالازدحام الآخرين معًا.

آليات الإزاحة (offload) قد تدمر التوقيت الذي صممه TCP

تتيح إزاحة تقسيم TCP (TCP Segmentation Offload – TSO) للنواة تسليم شريحة كبيرة إلى محول الشبكة، تُقسَّم بعد ذلك إلى حزم بحجم مناسب للإرسال على الخط. ويقلل هذا النهج تكلفة المعالج لكل حزمة، وهو ضروري للإنتاجية العالية في أنظمة كثيرة. وفي الوقت نفسه يضيف طبقة جديدة بين الجدولة البرمجية واللحظة المادية لخروج الحزم.

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

ويُظهر TSO لماذا يجب تقييم كل تحسين بوصفه جزءًا من مسار الإرسال الكامل. الإزاحة تقلل تكاليف المعالج، وTSQ يحد من التراكم المحلي، وsch_fqيوزع التدفقات، وتوزيع الإرسال يدير الزمن؛ ومن دون تنسيق تلغي طبقة ما مكاسب الأخرى. وتتوجه أعمال Dumazet مرارًا إلى هذه المفاصل تحديدًا، ولا تنظر إلى النقل بوصفه خوارزمية مغلقة.

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

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

في عام ٢٠١٧ قدّم Dumazet عملًا حول توزيع الإرسال الداخلي في TCP. وعزز التغيير قدرة طبقة النقل على إبقاء الإرسال متوافقًا مع حالة السرعة والمؤقتات الخاصة بها، مما قلل الاعتماد على وجود قاعدة جدولة طوابير محددة في الإعداد المتوقع.

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

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

يحتفظ Linux بعدة قواعد لجدولة الطوابير لأن الأحمال والأهداف مختلفة. فـsch_fqمهم خصوصًا لتوزيع الإرسال، بينما تتولى قواعد qdisc الأخرى الإدارة الفاعلة للطوابير أو تشكيل الحركة (shaping) أو الفئات الهرمية أو مجرد خدمة الجهاز. وsch_fqليس مطابقًا لـ FQ-CoDel، وإن كانت كلتا النظامين تستخدمان أفكار فصل التدفقات.

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

المشغل الذي يعدّ qdisc إعدادًا افتراضيًا خفيًا يفوت جزءًا مهمًا من سلوك التطبيق. عمل Dumazet يخلق إمكانية توزيع الإرسال، لكن التنفيذ هو من يقرر ما إذا كانت ستُستغل بكفاءة. والفجوة بين آلية الـ upstream وإعدادات الـ downstream من الأسباب الرئيسية التي تجعل وعدًا عامًا بالأداء مستحيلًا.

بضعة بايتات وسطر كاش واحد يتحولان إلى تكاليف على أسطول الخوادم

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

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

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

يعمل المعالج مع سطور الكاش، لا مع حقول مفردة من كود المصدر. إذا تقاسمت البيانات كثير التحديث سطرًا مع حقول نادرة الاستخدام، ينتقل السطر بأكمله عبر التسلسل الهرمي. وإذا غيّر معالجان قيمتين مختلفتين في السطر نفسه، فسيظلان يولّدان حركة تماسك (coherency traffic)؛ فقد تتبين أن بنية C مكتظة مكلفة في حركتها.

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

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

في عام ٢٠٢٤ قدّم Dumazet عملًا حول إعادة تنظيم شبه آلية لبنى البيانات. وخلافًا لإدخال آلية نقل مسماة، يبدأ هذا الإجراء بالتنميط (profiling): أي الحقول ساخنة، وأي سطور الكاش تتنقل، وأي البنى تهيمن على الذاكرة، وأين يخلق الترتيب تكاليف قابلة للإزالة.

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

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

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

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

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

المعالجة الدفعية عند الاستقبال تعيد المفاضلة نفسها في الكفاءة

رغم أن أوضح الآليات في هذه القصة تخص الإرسال، فإن إسهام Dumazet الأوسع يشمل المقابس ومسار الاستقبال. تحتاج الحزم الواردة إلى استطلاع (polling)، وتخصيص ذاكرة لها، وتصنيفها، ووضعها في طوابير المقابس، وتسليمها بين المعالجات. وعند معدلات الحزم العالية ينشأ التنافس حول الطوابير المشتركة ومعالجة التراكم وحالة المقبس.

قلّل Linux مرارًا عدد الأقفال، وجمّع العمل في دفعات، وأعاد توزيع المعالجة بين الأنوية. والمنطق الاقتصادي هو نفسه في TSQ وتوزيع الإرسال: على النظام أن ينفق القدر الكافي من التنسيق للصحة والإنصاف، لا حتى تبتلع العمليات المساندة موارد التطبيقات.

لا يوجد سجل إسهامات كامل. يسجل Git تأليف التصحيحات المدمجة، لكنه يعكس بشكل أسوأ المراجعات وإعادة الصياغة أو القرارات المرفوضة، لذلك فإن الآليات القابلة للتحقق أوثق من قائمة كاملة متخيلة. وقيمة Dumazet في النهج المنسجم تجاه الإرسال والاستقبال والمقابس والذاكرة، لا في امتلاك كل تحسين في هذه المجالات.

تظل المعالجة الدفعية (batching) من أقدم تقنيات الأنظمة عالية الأداء. معالجة عدة حزم أو إنهاءات معًا توزع التكلفة الثابتة للأقفال واستدعاءات الدوال وحركة الكاش على مجموعة، ويستخدم Linux هذا النهج في السائقين واستطلاع NAPI والإزاحة وإدارة الطوابير.

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

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

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

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

المراجعة العلنية تحوّل الملاحظات الإنتاجية إلى بنية Linux مشتركة

يبدأ تحسين الأداء بادعاء: هذا التغيير يقلل زمن الاستجابة أو يوفّر الذاكرة أو يرفع الإنتاجية. ولأن يصبح جزءًا من بنية Linux، يجب أن يصمد أمام المراجعة العلنية. يسأل مطورون آخرون: هل القياسات مقنعة؟ هل الواجهة عامة بما يكفي؟ هل تتعطل بنية نادرة؟ ومن سيصون السلوك الجديد بعد مؤلفه الأول؟

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

هذا الإجراء أبطأ من تصحيح خاص بأسطول واحد، لكنه أطول عمرًا. إنه يفرض التعبير عن حاجة مؤسسية خاصة بوصفها آلية نواة عامة. وجزء من صلاحيات Dumazet يتمثل في تقييم هذا التحويل: هل يعمل التحسين الآن؟ وهل الواجهة عامة بما يكفي؟ وهل يستطيع Linux دعمها على أجهزة وتطبيقات وفروع إصدارات مستقبلية؟

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

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

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

تشد إحصاءات المساهمات بموضوعية ظاهرية: يمكن عدّ الالتزامات (commits) المسجلة باسم مؤلف ما أو الأسطر المعدلة أو التصحيحات المدمجة. لكنها لا ترصد أهم جملة في النقاش — «هذه الواجهة سيتعذر صيانتها، أعد تصميمها» — وتعكس بشكل سيئ الاختبار وحل التعارضات والتنازل عن كود كان سيخلق تكاليف طويلة الأمد.

لا يمكن اختزال تأثير القيّم في جدول ترتيب. دمج التصحيح يثبت المسؤولية عن الدمج لا تأليف الفكرة الأصلية؛ ورفض تغيير قد يحمي مستخدمين أكثر من كتابة كود جديد. وقد تختفي مساعدة مطور آخر على إعادة بناء واجهة تقريبًا من حقل Author، رغم أن تلك المساعدة هي التي حددت متانة النتيجة.

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

وتُخضع التغييرات الشبكية لفحوصات البناء، واختبارات النواة الذاتية (selftests)، وKUnit، وsyzbot، ومختبرات السائقين، وعمليات النشر لدى التوزيعات والمشغلين. وتلتقط هذه الأنظمة انتكاسات يغفل عنها البشر، بما فيها أخطاء سلوك البروتوكول والذاكرة والمسارات النادرة وتفاعلات الأجهزة الافتراضية. غير أن فضاء الاختبار هائل: يعمل Linux على أبنية وبطاقات شبكة كثيرة، وبأنواع مختلفة من الإزاحة وqdisc وأدوات التحكم بالازدحام والتطبيقات.

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

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

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

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

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

صلاحيات القيّم موزعة وممولة ومقيدة بالإجراء العلني

يوزع ملفMAINTAINERSالحالي المسؤولية بين Dumazet وNeal Cardwell وغيرهما من القيّمين والمراجعين الشبكيين. وهذه ليست إجراءات شكلية: التقسيم يقلل خطر توقف النظام الفرعي بغياب شخص واحد، ويدخل تخصصات مختلفة في قرارات تمس التحكم بالازدحام والمقابس والسائقين والاختبار.

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

والاستمرارية داخلة أصلًا في معنى Dumazet بالنسبة إلى المشروع. على البنية الناضجة أن تحفظ ذاكرته التقنية دون أن تجعل كل قرار مستقبلي يمر عبره. فالشكل المستدام للقيادة يوزع المعرفة والاختبارات والصلاحيات دون كسر تماسك النظام الفرعي.

تعمل Netdev Foundation تحت إشراف Linux Foundation وتدعم الاختبار والأدوات والسفر والبحوث. ويشارك Dumazet في لجنتها الفنية الإدارية (Technical Steering Committee)، ولذلك يمكنه التأثير في احتياجات المجتمع التي تحظى بالتمويل والمشاريع التي تنال الموارد.

وهذا الدور منفصل عن قرارات قبول تصحيحات Linux. منحة المؤسسة لا تضمن الدمج، ومقعد القيّم في TSC لا يحول الجهة الممولة إلى مجلس منتجات مغلق. فالكود يظل خاضعًا لمراجعة netdev وملكية النظام الفرعي وعملية mainline.

والتقسيم يحمي الجانبين. الصيانة العميقة تتطلب وقتًا مدفوعًا ومعدات وتكاملًا مستمرًا (continuous integration)؛ والتظاهر بعدم وجود اقتصاد يعني إخفاء تكلفة البنية التحتية المشتركة. وعلى التمويل في المقابل أن يوسع القدرة الهندسية العلنية لا أن يشتري استثناءات من القواعد العامة؛ فالمال يتيح إنجاز العمل، لكن شرعية upstream ما تزال وليدة الأدلة التقنية القابلة للتحقق.

وتستخدم سجلات القيّمين الحالية عنوان Google لـ Dumazet. وهذا يؤكد الانتماء، لكنه ليس وصفًا كاملًا للمنصب، ولا يصح استنتاج اللقب المؤسسي أو شروط التوظيف بأمان من عنوان واحد.

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

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

المشغلون يقررون ما إذا كانت تحسينات upstream ستصل إلى المستخدمين

يوفر Linux في فرع mainline آليات لا بيئة تشغيل موحدة. تختار التوزيعات فروع الإصدار والنقل الرجعي، ويختار مشغلو السحابات الأنوية وqdisc، وقد يظل مصنعو الأجهزة (appliances) على نسخ قديمة، ويحدد موردو بطاقات الشبكة الإمكانيات العتادية، وتولّد فرق التطبيقات حركة قد تستفيد من تغيير أو لا تلمسه أصلًا.

ومن الصعب إحصاء التبني: لا يوجد مسح حديث موثوق لإعدادات TSQ أو لانتشارsch_fqفي كل البيئات. فالآلية قد توجد في النواة وتبقى معطلة في إعداد واحد، أو تعمل افتراضيًا بحيث لا يعرف المستخدمون اسمها أصلًا.

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

تتجاوز DPDK وVPP والمكدسات المتخصصة في فضاء المستخدم جزءًا من مسار النواة العام سعيًا وراء معدلات حزم عالية جدًا أو سيطرة أكثر إحكامًا. وهي مهمة للموجهات وأنظمة التداول ومنصات بيانات الاتصالات ومهام ضيقة أخرى، لكنها غالبًا تتطلب أنوية مخصصة وصفحات ضخمة (huge pages) وربط أجهزة ونموذج تشغيل منفصل.

أما Linux TCP فيخدم نطاقًا مختلفًا من التنوع. فهو مدمج مع المقابس الاعتيادية وآليات الأمان ومساحات الأسماء (namespaces) وأنظمة الملفات والمراقبة (observability) وسائقين وتطبيقات كثيرة. ومهمته أن يبقى فعالًا بما يكفي كي لا تضطر معظم الأحمال إلى مغادرة هذه البيئة المشتركة.

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

المكدس الشبكي قيّم ليس بسرعة الحزم فحسب. عليه أن يدعم واجهات برمجة المقابس (socket API) المألوفة وتحديثات الأمان والتوجيه ومساحات الأسماء والمراقبة وأجهزة كثيرة وعملية تطوير مستقرة. الأداء الذي يتطلب جزيرة تشغيلية منفصلة قد يكون مبررًا أحيانًا، لكنه يحمل تكلفته الخاصة.

وميزة Linux في التكامل. يستخدم التطبيق مقبسًا قياسيًا ويرث سنوات من العمل في الطوابير وتوزيع الإرسال والاستجابة للازدحام واحتساب الذاكرة؛ ولا يحتاج المطور إلى فهم TSQ لكي تحدّ الآلية من التراكم المحلي المفرط.

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

المضيف الأسرع لا يعني بعد شبكة أسرع

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

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

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

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

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

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

الاستمرارية جزء من البنية التقنية

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

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

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

قد ينقل توزيع الإرسال العتادي الطابور التالي إلى ما دون النواة

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

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

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

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

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

عمل Dumazet الصادر في ٢٠٢٤ يشير إلى هذه المرحلة الناضجة من البنية التحتية. فالمكدس غير مكتمل؛ بل يُنقَّح وفق التكلفة المادية للموارد التي تتبدى أكثر كلما نمت كثافة الاتصالات. فينتقل السؤال الاقتصادي من «أي بروتوكول جديد سيفوز؟» إلى «كم تستهلك كل وصلة موجودة أصلًا من الجهاز بصمت؟».

إرث Dumazet: الانضباط في التعامل مع الموارد المحدودة

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

والأدلة تؤيد موقفًا وسطًا أدق. فقد أدخل Dumazet TCP Small Queues، وكتب العمل التأسيسي حول الجدولة العادلة (fair queueing)، وطوّر توزيع الإرسال الداخلي في TCP، وعرض علنًا تحسين بنى البيانات الموجه نحو الكاش. وفي الوقت نفسه يتحمل المسؤولية الحالية عن المكدس الشبكي العام وTCP والمقابس داخل نظام صيانة موزع.

وقيمته في الصلة بين هذين الدورين. لقد ساعد Linux على معاملة الحزم والمقابس بوصفها مطالب بموارد محدودة: الوقت والذاكرة والطوابير وقرب المعالج. تُراجع النتائج ويضبطها آخرون بشكل جماعي، لكنها تبدأ بقرارات هندسية محددة؛ وقد لا يعرف المشغلون اسم المؤلف، وإن كانت الخوادم ترث الانضباط الذي غرسته هذه القرارات في المكدس المشترك.

تتبّع التأليف أسهل من تتبّع الأثر. فالتصحيح له رسالة والتزام (commit)، بينما انخفاض خطر الأعطال وكثافة الخوادم الأعلى أو زمن الاستجابة الأقل يتفرق عبر إعدادات لا تُحصى. قد لا يبقى من المراجعة إلا سلسلة أعيدت صياغتها، ولا يترك الواجهة المرفوضة أي مقياس منتج. وهذا ليس تبريرًا للمبالغة في الثناء، بل وصف للسلسلة التي تمر بها قيمة البنية التحتية: التصميم، ثم المراجعة، ثم الدمج، ثم التشغيل. ويكون سجل Dumazet أكثر إقناعًا حيث تكون هذه السلسلة مرئية، وأضعف حيث يلزم اقتصاد مغلق لأسطول معين.