ملخص تنفيذي

  • أوليفييه بونافنتورا هو أستاذ في UCLouvain وعميد كلية الهندسة، ويربط عمله توجيه الإنترنت وبروتوكولات النقل وتشغيل الكود والتعليم المفتوح والنشر التجاري.
  • كان مهندسًا أكاديميًا رئيسيًا وشارك في تأليف RFC لـ Multipath TCP، بينما جاءت هندسته وإدارة الازدحام والأمن وتطبيقاته من مجموعات متداخلة من الباحثين والمهندسين.
  • ساعدت UCLouvain في نقل MPTCP من المواصفات إلى كود Linux وأدلة النشر التي استخدمتها لاحقًا Apple ومشغلو الاتصالات وTessares ومجتمع Linux الرئيسي.
  • مساهمة بونافنتورا الدائمة هي طريقة لنشر البروتوكول: الحفاظ على الواجهات المفيدة، واختبار الافتراضات في الأنظمة العاملة، ومراجعة الإخفاقات، ونقل الصيانة إلى مؤسسات يمكنها الاستمرار.

كيف يمكن لاتصال واحد أن ينجو من فشل الشبكة

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

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

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

تم بناء MPTCP بواسطة شبكة، وليس مخترعًا واحدًا

قد يطلق سرد مبسط على بونافنتورا مخترع MPTCP ويرسم خطًا مستقيمًا من فكرة أكاديمية إلى استخدام تجاري. لا تدعم سجلات المعايير والتنفيذ هذه القصة. نشأ MPTCP من باحثين ومهندسين في UCLouvain وUniversity College London وجامعة بوليتكنيكا في بوخارست وCisco وApple وInternet Engineering Task Force ومجتمع Linux لاحقًا.

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

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

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

مسيرة تشكلت حول قابلية النشر

حصل بونافنتورا على شهادة الهندسة في علوم الكمبيوتر من جامعة لييج عام 1992. ثم عمل كمهندس أبحاث في مجموعة الشبكات التابعة لأندريه دانتين أثناء إكماله الدكتوراه. تناولت أطروحته عام 1999 كيف يمكن لنمط النقل غير المتزامن، أو ATM، أن يعمل تحت TCP/IP مع توفير الحد الأدنى المضمون من النطاق الترددي.

ينتمي الموضوع إلى نقاش رئيسي في التسعينيات. قدم ATM دوائر افتراضية هندسية وفئات خدمة، بينما تطورت كومة الإنترنت حول الحزم والتحكم في نقطة النهاية والتبني التدريجي. لم تكن المشكلة التقنية ببساطة ما إذا كان يمكن لـ ATM حمل حركة IP. بل كانت ما إذا كان يمكن إدخال قدرات شبكة جديدة دون التخلي عن التطبيقات والبروتوكولات والممارسات التشغيلية المستخدمة بالفعل.

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

من عام 1992 إلى 1997، عمل بونافنتورا كمهندس أبحاث في لييج. السجل العام لا يعيد بناء كل مسؤولية من تلك الفترة، لكن التسلسل يضع التنفيذ وتجارب الشبكة قبل مسيرته الأكاديمية التقليدية. ستواصل مجموعته لاحقًا الجمع بين الأوراق والكود والدروس والقياسات. قضى الفترة من 1997 إلى 1998 في Alcatel-Bell. المادة التي تمت مراجعتها لا تحدد مسمى وظيفي دقيق أو تحدد منتجات معينة، لذا لا ينبغي تزيين الفترة. ومع ذلك، فقد وضعته لفترة وجيزة داخل شركة اتصالات، حيث يفرض التوافق ودورات حياة المنتج ودعم العملاء قيودًا مختلفة عن تلك الخاصة بنموذج أولي للمختبر.

أصبح بونافنتورا أستاذًا مساعدًا في FUNDP، وهي الآن جامعة نامور، في عام 1998. انتقل إلى UCLouvain في عام 2002، وأصبح أستاذًا في عام 2006 وأستاذًا في عام 2011. عند حد البحث، عرّفته UCLouvain كأستاذ وعميد لكلية لوفان للهندسة.

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

علمه عمل التوجيه تصميم الانتقال

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

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

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

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

حافظ MPTCP على التطبيق مع تغيير النقل تحته

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

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

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

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

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

سجل المعايير يستبعد قصة المخترع الوحيد

تجعل وثائق هندسة MPTCP ومعاييره التأليف الجماعي مرئيًا. كُتب RFC 6182، الذي حدد المبادئ التوجيهية الهندسية، من قبل Alan Ford و Costin Raiciu و Mark Handley و Sébastien Barré و Janardhan Iyengar. كُتب RFC 6824، مواصفة MPTCP الإصدار 0 التجريبية، من قبل Ford و Raiciu و Handley و Bonaventure. أضاف RFC 8684، مواصفة مسار المعايير اللاحقة، Christoph Paasch.

كان للمكونات الأخرى مؤلفون رئيسيون مختلفون. كُتب RFC 6356 حول التحكم المقرون في الازدحام من قبل Raiciu و Handley و Damon Wischik. وثق Michael Scharf و Ford اعتبارات واجهة التطبيق. شارك Marcelo Bagnulo ومساهمون لاحقون في تحليل الأمان.

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

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

نُشر RFC 6824 في يناير 2013 كمواصفة تجريبية. حدد MPTCP الإصدار 0 واستخدم خيار TCP من النوع 30. لم تكن كلمة "تجريبي" تعني عارضة. لقد أقرت بأن امتدادًا كبيرًا لبروتوكول منتشر بعمق يحتاج إلى أدلة من برمجيات وشبكات حقيقية قبل أن يُعامل كبنية تحتية مستقرة. جاءت هذه الأدلة من نوى البحث واختبار الصناديق الوسيطة وتجارب مراكز البيانات ونشر Apple وأنظمة المشغلين. وجد المجتمع مشاكل في المصافحة والأمان وإدارة المسارات والتشغيل لم يكن من الممكن كشفها بمراجعة المستندات وحدها.

جلب RFC 8041، الذي كتبه Bonaventure و Paasch و Gregory Detal، تجربة التشغيل هذه إلى سجل المعايير. غطى مراكز البيانات وروابط Wi-Fi والخلوية والوكلاء وتداخل الصناديق الوسيطة والتحكم في الازدحام والجدولة والبوابات المقيدة ومزارع الخوادم الموزعة الحمل. تعامل المستند مع السلوك المنشور كدليل قادر على تغيير البروتوكول. هذه خطوة مؤسسية مهمة. لا تظل المواصفة موثوقة لمجرد أنها نُشرت أولاً. عندما يتعارض الكود العامل بشكل متكرر مع افتراض، يجب أن يأخذ المعيار الشبكة الموجودة في الاعتبار.

نُشر RFC 8684 في مارس 2020، ملغيًا RFC 6824 وناقلاً MPTCP الإصدار 1 إلى مسار المعايير. نقح تبادلMP_CAPABLEوأوضح السلوك الذي تم تعلمه من خلال التنفيذ. الإصدار 1 غير متوافق على السلك مع الإصدار 0. خلق الانقطاع أعمال ترحيل، لكن الحفاظ على كل خيار تجريبي كان سيحمل تكاليفه الخاصة. يظهر تطوير MPTCP أن النضج يمكن أن يتطلب حدًا صريحًا للإصدار عندما تجعل الأدلة التشغيلية التصميم السابق صعب الدفاع عنه.

اتصال واحد، عدة تدفقات فرعية عادية لـ TCP

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

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

بمجرد وجود اتصال MPTCP، يمكن لنقطة النهاية إنشاء تدفق فرعي آخر باستخدامMP_JOIN. يحمل تبادل الانضمام رمزًا مميزًا يحدد الاتصال وآلية قائمة على HMAC مشتقة من مفاتيح الاتصال. يسمح لمسار آخر بالانضمام دون الكشف عن المفتاح الكامل أو جعل الإرفاق التعسفي سهلاً. لا يقرر البروتوكول متى يجب إنشاء تدفق فرعي إضافي. تعود هذه المسؤولية إلى مدير المسار وسياسة النشر. قد يضيف الهاتف الخدمة الخلوية فقط عندما تتدهور Wi-Fi. قد تنشط بوابة النفاذ الهجين المسارات الثابتة والمحمولة فورًا. قد يكتشف مضيف مركز البيانات عدة عناوين ومسارات.

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

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

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

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

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

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

شكل الإنترنت المثبت البروتوكول

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

وضعت ورقة NSDI لعام 2012 "How Hard Can It Be?" هذه المشكلة في مركز البحث. فحص Costin Raiciu و Christoph Paasch و Sébastien Barré و Alan Ford و Michio Honda و Fabien Duchêne و Olivier Bonaventure و Mark Handley سلوك الصناديق الوسيطة والمسارات غير المتكافئة وإعادة الترتيب وضغط المخزن المؤقت وقيود الخادم ونظام التشغيل الواقعية.

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

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

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

حول الكود العامل البحث إلى بنية تحتية

ينسب حساب المشروع التاريخي لـ UCLouvain إلى Sébastien Barré بدء سلالة تنفيذ Linux MPTCP الرئيسية حوالي عام 2009، بالاعتماد جزئيًا على أعمال سابقة متعلقة بـ shim6. قام Christoph Paasch و Gregory Detal و Fabien Duchêne والعديد من الآخرين بتوسيع الشجرة. دعمت التجارب والدروس والنشر المبكر.

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

اعترفت جائزة ACM SIGCOMM لأنظمة الشبكات لعام 2019 بتنفيذ Linux MPTCP وحددت Paasch و Barré و Detal كمطورين رئيسيين مع الاعتراف بمجتمع مساهمين أوسع. ظهورهم مهم لأن المشروع اعتمد على عدة أنواع من الخبرة. بناء المؤسسات لا يحل محل الفضل الهندسي؛ إنه يخلق الظروف التي يمكن فيها للمهندسين إنتاج عمل دائم.

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

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

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

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

أضاف العمل اللاحق مدير مسار netlink واستخدامًا متزامنًا لعدة تدفقات فرعية ومعالجة خارج الترتيب على مستوى الاتصال وتحكم فضاء المستخدم. أصبح Matthieu Baerts و Paolo Abeni و Mat Martineau ومساهمون رئيسيون آخرون مركزيين خلال هذه المرحلة. شارك مهندسو Tessares أيضًا، لكن النظام الفرعي لم يكن مجرد شجرة UCLouvain المنقولة سليمة. يظهر التقدم المأسسة في الممارسة. جاء التفاوض على البروتوكول أولاً. تلته واجهات السياسة والاستخدام الحقيقي متعدد المسارات. استمرت معالجة إعادة التعيين والتشخيص والاختبارات الذاتية في التطور. أصبحت Linux الرئيسية طبقة الصيانة المشتركة، بينما احتفظ صانعو الأجهزة والمشغلون بالتحكم المحلي في سياسة المسار.

تحدد سجلات Linux الحالية Matthieu Baerts و Mat Martineau بين مشرفي MPTCP. بونافنتورا ليس مشرفًا حاليًا لـ Linux MPTCP. التأثير التاريخي لا يخلق سلطة دمج حالية أو مسؤولية أمنية. هذا التعاقب يعزز حالة تأثيره. يصبح البروتوكول بنية تحتية عندما يمكنه الاستمرار دون الحاجة إلى قادته الأكاديميين الأصليين لقبول كل تصحيح أو تشخيص كل تراجع. السؤال المتبقي هو ما إذا كان المجتمع اللاحق لديه مشرفين واختبارات وتمويل كافٍ لاستدامة النظام الفرعي.

اعتمد النشر على سياسة المنتج واقتصاديات المشغلين

حولت Apple MPTCP إلى بنية تحتية استهلاكية مرئية. تشرح مواد الدعم الخاصة بها أن iPhone أو iPad يمكنه استخدام Wi-Fi كاتصال أساسي والخدمة الخلوية كنسخة احتياطية. Siri هو أشهر مثال. إذا أصبحت Wi-Fi غير متاحة أو غير مستجيبة، يمكن للتطبيق الاستمرار عبر الخلوي دون إنشاء جلسة منطقية جديدة تمامًا.

نُصح مسؤولو الشبكات بالسماح بخيار TCP 30 وتوقع تراجع TCP العادي عندما لا يتمكن الخيار من المرور. أظهر النشر أن MPTCP يمكن أن يوفر مرونة على نطاق المستهلك. لم يكن هذا يعني أن كل تطبيق iOS جمع بين Wi-Fi والنطاق الترددي الخلوي. كتبت Apple تنفيذها الخاص وشغلت جانب الخادم واختارت سياسة المنتج. أثر بونافنتورا على البحث والمعايير الأولية لكنه لم يكتب مكدس الشبكات الداخلي لـ Apple.

فحص باحثو UCLouvain لاحقًا سلوك التسليم في Apple وأبلغوا عن وصول تطبيق أوسع في iOS 11. لم يكن الانتقال فوريًا حرفيًا، ولا تزال سياسة نقطة النهاية تؤثر على النتيجة. يمكن للاتصال النجاة من تغيير المسار مع تجربة تأخير أو إعادة ترتيب أو انخفاض في الإنتاجية.

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

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

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

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

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

تضيف الأجهزة المحمولة قيدًا آخر: للمسارات تكاليف مالية وتكاليف طاقة. يمكن أن يستهلك إبقاء الراديو الخلوي نشطًا طاقة البطارية، ويمكن أن تكلف حركة المرور عبر شبكة محدودة البيانات المستخدم أو المشغل. قد تكون Wi-Fi سريعة لكنها غير مستقرة؛ قد تكون الخلوية موثوقة لكنها مكلفة. يساعد هذا في تفسير لماذا أكد استخدام Apple الموثق على النسخ الاحتياطي بدلاً من التجميع الدائم. يمكن للبروتوكول حمل حركة المرور عبر عدة شبكات، لكنه لا يستطيع تحديد ما يرغب المستخدم في دفعه أو أي مقايضة بطارية مقبولة.

نقلت Tessares MPTCP عبر الحدود التجارية

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

لم تجعل الخدمة كل تطبيق أسرع. اعتمدت بشكل أساسي على حركة TCP وتكامل البوابة وسعة الوكيل ومعالجة الشبكات الخاصة الافتراضية و UDP والبروتوكولات الأخرى. لذلك كان المنتج التجاري أكثر بكثير من RFC. تضمن البرمجيات ومعدات مباني العملاء وموارد الراديو والمراقبة والدعم التشغيلي.

يحدد إعلان مستثمر Tessares كشركة منبثقة عن UCLouvain تأسست في مارس 2015 من قبل Olivier Bonaventure و Gregory Detal و Sébastien Barré و Denis Périquet و Sopartec. جمعت المجموعة بين العمل الأكاديمي والعمل في المعايير وخبرة التنفيذ والقيادة التجارية ونقل التكنولوجيا من الجامعة.

لا يمكن أن تصبح المواصفة منتج مشغل بدون بوابات وتكامل ومبيعات ودعم ومسؤولية عن الأنظمة المنشورة. لذلك يجب وصف بونافنتورا كمؤسس مشارك، وليس تلقائيًا كرئيس تنفيذي حالي للشركة أو مساهم مسيطر أو مشغل يومي. حددت إعلانات المشغلين العامة Denis Périquet كرئيس تنفيذي، بينما تظل ملكية المؤسسين ومسؤوليات الإدارة الحالية غير معلنة في السجل المقدم.

قدمت Proximus أول دليل مشغل مسمى. وصفت برنامجًا تجريبيًا لمدة تسعة أشهر في Frasnes-Lez-Anvaing جمع بين DSL و 4G/LTE للعملاء الريفيين. أبلغ المشغل عن رضا مرتفع وزيادات في السرعة تصل إلى 20 ميغابت في الثانية لبعض المشاركين، وقال إن النظام مؤهل لاختبار أوسع مع مستخدمين حقيقيين ونشر وطني محتمل. كانت هذه ادعاءات من مشغل مشارك بدلاً من تدقيق أداء مستقل. ومع ذلك، أثبت البرنامج التجريبي أكثر من معيار مختبري. قامت Proximus بتثبيت النظام في بيئات العملاء، ونسقت شبكتي نفاذ، واختبرت ما إذا كانت الخدمة الناتجة يمكن دعمها.

أعلن إعلان عام 2018 عن جولة تمويل بقيمة 3 ملايين يورو شملت Proximus و VIVES II و SRIW. سمى Proximus و KPN و Telia كعملاء وقال إن ما يقرب من 15,000 أسرة في بلجيكا وهولندا وليتوانيا استفادت من تقنية Tessares. أعلن إعلان عام 2021 عن جولة بقيمة 3.5 مليون يورو بقيادة صندوق مجلس الابتكار الأوروبي و Sagemcom، بمشاركة مستثمرين حاليين. تحدد الأرقام التمويل وعلاقات العملاء في تلك التواريخ. لا توفر الإيرادات الحالية أو الربحية أو التقييم أو الاحتفاظ بالعملاء أو قاعدة التثبيت الحالية.

أعلنت BT عن Hybrid Speed Boost للشركات الصغيرة في عام 2022 وقالت إن المنتج استخدم تقنية Tessares MPTCP. وصف المشغل مزيجًا من النطاق العريض النحاسي وشبكة EE للجيل الرابع وأبلغ عن تحسن متوسط في التحميل. كما جعلت مستندات الدعم الخاصة به القيود واضحة بشكل غير عادي. طُبقت التعزيز على حركة الويب عبر TCP ولم يسرع حركة ألعاب UDP النموذجية. يمكن أن يحد سلوك الشبكة الخاصة الافتراضية أيضًا من الفائدة. لم يصبح رابطا النفاذ أنبوبًا عالميًا واحدًا لكل حزمة.

قالت مواد عامة من Wavenet و Digital Wallonia لاحقًا إن Wavenet قامت بصيانة أو دعم حل النفاذ الهجين من Tessares منذ عام 2024 وخدمت أنظمة MPTCP المستخدمة من قبل مشغلين أوروبيين كبار. ظلت Tessares مدرجة ككيان قانوني بلجيكي نشط عند حد البحث.

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

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

استمرت الطريقة بعد MPTCP

وسع عمل بونافنتورا في التعليم النهج نفسه خارج بروتوكول واحد. كتبComputer Networking: Principles, Protocols and Practice، الذي صدر لأول مرة في عام 2011 وتم تنقيحه لاحقًا. كان الكتاب مرخصًا بشكل مفتوح ومتاحًا للمدرسين والطلاب للفحص والتكييف وإعادة التوزيع. يشير سجله العام أيضًا إلى جائزة مؤسسة Saylor لعام 2012 عن عمل الكتاب المفتوح. تعامل الكتاب مع الشبكات كشيء يمكن للقراء فحصه من خلال البروتوكولات والكود والسلوك الفعلي بدلاً من مجموعة من الطبقات المثالية. سمح النشر المفتوح أيضًا بتغيير المادة مع تغير الأنظمة.

عمل بونافنتورا كمدير تعليم ACM SIGCOMM من 2010 إلى 2016 وتولى لاحقًا مناصب تحريرية وقيادية أكاديمية. أصدرت مجموعته مواد تنفيذ ودروس وبيئات افتراضية وتجارب. واصل برنامج تعليمي لـ SIGCOMM في عام 2020 العمل العملي حول النقل متعدد المسارات.

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

انتقل بحثه اللاحق من بروتوكول واحد متعدد المسارات نحو أنظمة نقل أكثر قابلية للبرمجة. يعمل QUIC فوق UDP وينفذ الكثير من سلوك النقل الخاص به في فضاء المستخدم، مع دمج التشفير عبر TLS. يوفر طريقًا مختلفًا حول افتراضات النواة والصندوق الوسيط المتحجرة مقارنة باستراتيجية خيار TCP لدى MPTCP.

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

استكشفت الأبحاث حول مكدسات النقل القابلة للتوسيع في Linux و TCP المدرك للمسار الممكن بـ eBPF كيف يمكن أن يتغير سلوك النقل دون إضافة واجهة نواة ثابتة لكل آلية مستقبلية. يمكن أن تدعم بيئة تنفيذ مقيدة ومنطق مثبت محليًا التجريب بينما تحدد الطبقة المشتركة حدود الأمان وقابلية التشغيل البيني.

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

طبق مشروع xBGP تفكيرًا مشابهًا على التوجيه. اقترح آلية محايدة للبائع لتوسيع تنفيذات BGP من خلال eBPF وواجهات موثقة، بما في ذلك العمل مع مكدسات التوجيه المفتوحة مثل FRRouting و BIRD. نظرت أبحاث أخرى في النقل الآمن لـ BGP مع الحفاظ على نماذج التشغيل المألوفة الموجهة لـ TCP.

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

غطت منشورات UCLouvain الحديثة أيضًا اختيار عائلة عناوين IPv4/IPv6 التكيفي و switched-homing و Flexicast QUIC. يسعى Flexicast إلى الجمع بين كفاءة الإرسال المتعدد والتراجع إلى الإرسال الفردي عبر نقل مشفر، بينما يفحص switched-homing كيف تتغير الأنظمة بين مسارات النفاذ وفقًا للسياسة والأداء.

بقيت هذه المشاريع في مراحل بحثية مختلفة. تظهر أن عمل بونافنتورا في عامي 2025 و 2026 لم يكن مجرد دفاع بأثر رجعي عن MPTCP. استمر في فحص كيفية نشر قدرة الشبكة عندما تكون المسارات ودعم البروتوكول والسلطة مقسمة بين أطراف مختلفة.

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

حدود MPTCP تحدد إنجازه الحقيقي

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

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

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

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

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

للسجل العام حدود أيضًا. يدعم أدوار بونافنتورا الأكاديمية وتأليف RFC وقيادة البحث والكتاب المفتوح والمشاركة في تأسيس Tessares والبحث الحالي. لا يثبت تاريخ ميلاد موثوق أو ثروة شخصية أو تعويضات أو حصة المؤسس أو جدول رسملة كامل لـ Tessares أو الأداء المالي الحالي للشركة. كما لا يمكنه تحديد حصته الشخصية من تنفيذ Apple أو نتيجة تجارية لأي مشغل. يجب أن تظل هذه الفجوات مفتوحة. السجل التقني والمؤسسي كبير بما فيه الكفاية دون إسناد نتائج الفريق لشخص واحد.

إرثه هو الأنبوب

لم يخترع بونافنتورا MPTCP بمفرده. لم يكتب وثيقة هندسته أو RFC التحكم في الازدحام أو تنفيذ Apple أو النظام الفرعي الحالي في Linux الرئيسية. لا ينبغي وصفه كرئيس تنفيذي حالي لـ Tessares بدون دليل.

مساهمته أكثر ديمومة مما توحي به تلك الادعاءات. شارك في تأليف المواصفات التجريبية ومواصفات مسار المعايير، وقاد مجموعة أنتجت برمجيات وأبحاث نشر مهمة، وساعد في جلب أدلة التشغيل إلى عملية المعايير، وشارك في تأسيس شركة نقلت البروتوكول إلى منتجات الاتصالات، وبنى موارد تعليمية ساعدت في تدريب المهندسين اللاحقين. استمر النمط في عمله على QUIC والنقل الممكن بـ eBPF وآليات تمديد BGP. سأل كل مشروع كيف يمكن لسلوك شبكة جديد النجاة من التطبيقات والمعدات والحوافز والحدود المؤسسية القائمة.

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

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