متابعة النقاش من Caddy أمام Nginx الخاص بالتطبيق عبر Docker Compose:
بعد نقاشي السابق حول تشغيل Caddy أمام حاوية nginx الخاصة بـ Discourse لتوفير HTTP/3 وQUIC 0-RTT، كنت أبحث في سؤال منفصل لكنه مرتبط: ما إذا كان TCP متعدد المسارات (MPTCP) يمكن أن يحسّن استمرارية الاتصال للمستخدمين على iOS أثناء التنقل بين شبكات Wi-Fi والشبكات الخلوية.
كانت أعمالي السابقة تركز بشكل أساسي على أداء تحميل الصفحات الأولية. هذا السؤال مختلف: فأنا أستخدم أرشيف الدراسة الخاص بي على Discourse بانتظام أثناء التنقل بين الأنشطة، وقد تؤدي الاتصالات المقطوعة أو التخزين المؤقت (Buffering) إلى تأخير الوصول إلى معلومات مهمة.
لماذا أطرح هذا السؤال
في بعض المواقع، تكون شبكة Wi-Fi موثوقة بينما تكون الاستقبال الخلوي ضعيفًا؛ وفي أماكن أخرى، تكون الحالة عكسية.
لم يوفر التبديل العادي لشبكات iOS دائمًا الاستمرارية التي أحتاجها. أنا أستخدم بالفعل تقنيات منفصلة لربط/تحويل الشبكات (Network Bonding/Failover) لمرونة الاتصال، لكنني مهتم بفهم ما إذا كان يمكن تحقيق بعض من تلك الاستمرارية بشكل أصلي (Native) بين عميل iOS وخادم Discourse الخاص بي.
على وجه الخصوص، أهتم بتسليم الاتصال (Connection Handover) وتجنب الطلبات المتوقفة، بدلاً من تجميع نطاق عرض (Bandwidth) اتصالات متعددة بالضرورة.
ما وجدته حتى الآن
تذكر وثائق توافق Linux MPTCP أن Caddy الإصدار 2.10.0 وما بعده يدعم MPTCP افتراضيًا، شريطة توفر دعم نظام التشغيل.
تصف وثائق Apple الخاصة بـ MPTCP كيف يمكن للتطبيقات اختيار الانضمام إلى MPTCP من خلال URLSessionConfiguration.
ومع ذلك، وجدت أيضًا شرحًا في منتديات مطوري Apple يشير إلى أن WKWebView لا يعرض خيار إعداد MPTCP مكافئ.
هذا يتركني غير متأكد مما إذا كان DiscourseHub أو Safari أو PWA المثبتة على iOS يمكن أن تستفيد من MPTCP، خاصةً عندما يكون HTTP/3 فوق QUIC متاحًا أيضًا.
بيئة الخادم المؤكدة
تحققت من VPS الإنتاجي باستخدام أوامر للقراءة فقط، دون تعديل تكوينه.
-
الوكيل العكسي (Reverse Proxy): Caddy الإصدار 2.11.4، صورة Docker الرسمية
caddy:2.11.4 -
المضيف (Host): Ubuntu، نواة Linux
6.8.0-146-generic -
MPTCP على المضيف:
net.mptcp.enabled = 1 -
MPTCP داخل الحاوية:
/proc/sys/net/mptcp/enabled = 1 -
شبكة Docker:
caddy_default، السائقbridge، الخيارات{} -
بيئة Go:
GODEBUGغير مضبوط -
المنافذ المنشورة: TCP 80، TCP 443 و UDP 443، على IPv4 و IPv6
تبقى nginx الخاصة بـ Discourse خلف Caddy، حيث يوفر Caddy نقطة النهاية العامة لـ HTTPS و HTTP/3.
تقترح هذه الفحوصات أن الخادم يمتلك المتطلبات الأساسية لدعم MPTCP، على الرغم من أنني لم أتحقق من تفاوض MPTCP الفعلي عبر إعادة توجيه المنافذ المنشورة في Docker.
الأسئلة
-
DiscourseHub: هل يستخدم شبكته على iOS مكونات قادرة على طلب MPTCP، أم أن محتواه الرئيسي على الويب يتم التعامل معه عبر واجهات برمجة تطبيقات للشبكة لا تعرض هذه القدرة؟
-
Safari و PWA المثبتة: هل هناك أي فرق بين الوصول إلى Discourse عبر DiscourseHub أو Safari أو PWA المثبتة على iOS؟ هل يجب على العميل طلب MPTCP بشكل صريح، أم يمكن لأي من طرق الوصول هذه أن تستفيد بشكل شفاف؟
-
شبكة Docker: هل يمكن لتكوين الجسر/ترجمة عناوين الشبكة (Bridge/NAT) الحفاظ على تفاوض MPTCP الأولي وتدفقات الفرع الإضافية (Subflows)، أم قد يتسبب هذا في تراجع الاتصالات إلى TCP العادي؟
-
HTTP/3 مقابل MPTCP: بما أن HTTP/3 يستخدم QUIC فوق UDP بدلاً من TCP، هل يوفر هجرة اتصال QUIC (QUIC Connection Migration) استمرارية مقابلة عند التبديل بين الشبكات؟ هل هناك فرق عملي بين HTTP/2 فوق MPTCP و HTTP/3 فوق QUIC في هذه الحالة؟
-
الاستعادة من جانب Discourse: هل توجد آليات موجودة في Discourse أو عملاء iOS الخاصة به لاستعادة الطلبات المقطوعة عند تغير الشبكة الأساسية؟ هل هناك طريقة موصى بها لتحديد أي نقل (Transport) يستخدمه عميل iOS فعليًا؟
لست أقترح أن يتولى Discourse نفسه إدارة واجهات الشبكة المتعددة. أنا أحاول فهم أين تقع المسؤولية بين عميل iOS، وبروتوكول النقل، و Docker/Caddy و Discourse، وما إذا كانت هناك قدرات موجودة يمكنني الاستفادة منها.
سأكون ممتنًا لأي إرشادات أو تصحيحات لفهمي.
شكرًا!