الخلاصة

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

مقبس واحد بعد اختفاء Wi-Fi

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

يفصل RFC 8684 بين الاتصال ومساراته. يقابل اتصال MPTCP مقبس تطبيق واحدًا، لكنه قد يضم عدة تدفقات فرعية. يتصرف كل تدفق فرعي مثل TCP على مساره، بينما تحافظ طبقة الاتصال فوقها على الترتيب والموثوقية. لذلك لا يعني سقوط تدفق فرعي بالضرورة نهاية الاتصال كله.

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

المسار الجديد يحتاج إلى قبول

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

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

يعلن ADD_ADDR عنوانًا آخر ويسحب REMOVE_ADDR عنوانًا سابقًا. تساعد معرفات العناوين عندما يغير NAT ما يظهر في الترويسة. لكن الإعلان يقدم مرشحًا فقط؛ ولا يثبت قابلية الوصول أو الاستقلال أو السعر أو الأداء.

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

سجل واحد فوق عدة تدفقات TCP

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

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

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

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

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

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

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

الرجوع نتيجة يجب تسجيلها

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

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

المصادر