رابطان صاعدان ونفق واحد: التبديل عند الفشل أم الموازنة أم الربط
التبديل عند الفشل، والموازنة لكل تدفق، وتجميع التدفق الواحد ثلاثة وعود مختلفة. المساران الافتراضيان يمنحانك الأول، وليس الآخرين.
يمكن أن يجعل خطّا إنترنت شبكة VPN أكثر توفّراً، ويمكن أن يجعلها أسرع لبعض أحمال العمل، لكن الآلية هي التي تحدد أي الأمرين يحدث. الموجّه الذي يحمل مسارين افتراضيين ليس مربوطاً، والنفق الذي يحمل آلاف الاتصالات الداخلية يبقى تدفقاً خارجياً واحداً. تسمية الوعد أولاً هي الفرق بين تصميم وخيبة أمل مكلفة. يفصل الجدول أدناه بين الخيارات بحسب ما يحتاجه كل منها في الطرف البعيد وبحسب ما يفعله فقدان رابط بعملية نقل.
ثلاثة وعود، وواحد فقط يحتاج إلى شريك
يُبقي التبديل عند فشل الرابط مساراً متاحاً عندما يختفي الرابط المفضّل. توزّع موازنة تجزئة التدفقات التدفقات المستقلة على الرابطين الصاعدين. ويسمح تجميع التدفق الواحد لعملية نقل واحدة باستخدام الرابطين في الوقت نفسه. هذه منتجات مختلفة بمتطلبات مختلفة، وآخرها وحده يحتاج إلى تعاون من شيء خارج الموجّه.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
لا شيء في ذلك الجدول يبرّر شراء خط ثانٍ. ما يفعله هو منع تقييم تصميم تبديل عند الفشل كأنه ربط.
لماذا يبدو النفق للموجّه كتدفق واحد
يُجزّئ الموجّه الموازن للحمل عناوين المصدر والوجهة مع المنافذ، ثم يرسل التدفق كله إلى حيث تشير التجزئة. والنفق VPN هو أحد تلك التدفقات من منظور الموجّه، مهما كان يعمل داخله. لا تصل الاتصالات الداخلية أبداً إلى قرار التجزئة، لأن الترويسة الخارجية حدّدت المسار سلفاً. ولهذا يمكن لرابط صاعد ثانٍ أن يضاعف السعة الإجمالية لكثير من المستخدمين وألّا يغيّر شيئاً في عملية نقل كبيرة لمستخدم واحد.
يمكن أن يمنحك نفقان منفصلان مرشّحين اثنين، لكنهما ما زالا يحتاجان إلى سياسة مقصودة توزّع حركة المرور وتُبقي الردود على المسار الذي حمل الطلب. والتوجيه غير المتماثل هو النتيجة المعتادة لتخطّي تلك الخطوة. وأدنى ما يلزم هو سياسة تسمّي التدفق والرابط المفضّل ورابط الاحتياط.
لا يعبر ربط Ethernet مزوّدين غير مرتبطين، لأن الطرف البعيد يجب أن يشارك في بروتوكول التجميع. وربط عبر مزوّدي خدمة إنترنت اثنين مشروع بحثي ما لم يوجد طرف متعاون.
ما يحتاجه TCP متعدد المسارات في الطرفين
تشرح وثائق Linux الخاصة بـ Multipath TCP عدة تدفقات فرعية تنتمي إلى اتصال واحد. دعم النواة في طرف واحد لا يغيّر شيئاً بحد ذاته، لأن النظير يجب أن يقبل تلك التدفقات الفرعية أيضاً. والوكيل في الطرف البعيد هو الترتيب الشائع الآخر، ويصبح مكوّناً له سعته وتوفّره اللذان يجب التخطيط لهما. والمنطق نفسه يستبعد حلاً سهلاً لـ WireGuard، الذي يستخدم UDP: فـ MPTCP ينمّي تدفقات TCP الفرعية ولا يستطيع تجميع ذلك النفق دون شيء آخر في التصميم.
تحقّق من تفعيل ميزة النواة قبل التصميم عليها، لأن توزيعات كثيرة تشحنها معطّلة. هذه الأوامر الثلاثة تجيب عن ذلك في دقيقة.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showاختر من حمل العمل، لا من الكتيّب
إذا كان حمل العمل جلسات مستقلة كثيرة، فيمكن لموازنة تجزئة التدفقات أن تضيف سعة دون تعاون من الطرف البعيد. وإذا كان عملية نقل واحدة كبيرة، فلن يفيد إلا تصميم تجميع، وذلك التصميم يحتاج نظيراً متعاوناً. وإذا كان الشرط هو استمرار العمل عند موت رابط، فالتبديل عند الفشل هو الجواب، وإنتاجية عملية نقل واحدة غير ذات صلة.
اكتب الشرط في جملة واحدة فيها فعل: نسخة احتياطية واحدة تنتهي بضعف السرعة، أو رابط ساقط لا ينهي جلسة. والأهداف الغامضة تنتج تصاميم لا يستطيع أحد قبولها أو رفضها. ثم قرّر ما يُسمح للطرف البعيد أن يكون، لأن الخيار الأرخص هو غالباً الذي لا يتطلب شيئاً جديداً هناك. وهذا القيد يُسقط معظم ادعاءات الكتيّب قبل الاجتماع الأول.
أبقِ الوعود الثلاثة منفصلة في وثيقة المتطلبات. والتصميم الذي يدّعي الثلاثة عادةً يسلّم واحداً ويفترض الآخرين بهدوء. والقسم التالي يختبر أيّها يُسلَّم فعلاً.
اختبر عملية نقل واحدة وكثيرة، ثم اسحب رابطاً
قارن عملية نقل مستمرة واحدة بعدة عمليات نقل متوازية إلى الوجهة نفسها، وسجّل الفقد والتأخير والاستخدام لكل رابط. والكسب الذي يظهر مع الجلسات المتوازية وحدها يشير إلى توزيع التدفقات، لا إلى تجميع التدفق الواحد. اختبر فقدان رابط صاعد واحد على حدة، لأن السعة أثناء عمل الرابطين لا تقول شيئاً عن التبديل عند الفشل لجلسة قائمة. والتقط المسار والمقبس وعدّادات إعادة الإرسال قبل كل اختبار وبعده.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5حين تظل عملية النقل الواحدة تستخدم رابطاً صاعداً واحداً، فالتصميم يفعل بالضبط ما تدل عليه تجزئة التدفقات. وحين تتوزّع عمليات النقل المتوازية على الرابطين، فالموازنة تعمل والتجميع لا يعمل. سجّل أيّ الوعود الثلاثة يحققه التصميم فعلاً، وتبدأ محادثة السعة التالية من دليل لا من ادعاء بائع.