هل يدعم ديسكورس بالفعل بروتوكول http3؟
أعلم أن هذه مشكلة شبكة في المقام الأول، ولكن إذا قمت بتشغيل ديسكورس على DigitalOcean، على سبيل المثال، فيجب أن تكون حاوية Docker التي يعمل فيها ديسكورس قادرة على دعم http3
لا أعرف، ولكن كيف سيساعد http3 Discourse؟
ليس في الوقت الحالي
إعجابَين (2)
من الناحية الفنية، HTTP3 هو مجرد إصدار آخر من بروتوكول HTTP. لذلك، إذا أراد شخص ما تقديم نسخة Discourse الخاصة به عبر HTTP3 اليوم، فيمكنه القيام بذلك عن طريق وضع وكيل عكسي HTTP منفصل يدعم HTTP3 أمام نسخة Discourse الخاصة بك. هذا ممكن دون تغيير صورة Docker الخاصة بـ Discourse.
أنا أخمن هنا بعض الشيء، لذا كن حذرًا، ولكن يبدو أن صورة Docker تستخدم Nginx كوكيل عكسي لـ Discourse داخليًا. أرى أن Nginx يدعم HTTP3 أصليًا، ولكنه يعتبر التنفيذ تجريبيًا في الوقت الحالي. ربما لهذا السبب لم يتم تنفيذ دعم HTTP3 في صورة Docker في الوقت الحالي؟
إعجابَين (2)
نعم، إنها ميزة تجريبية، ولكن من الاختبارات على مواقع أخرى، يمكنك أن ترى أنها مستقرة بما يكفي للمشاريع التي تختار مسار http3 اليوم.
هل هناك أي مسؤول عن Docker لـ Discourse سأستضيفه، إذا كان بإمكانه إضافة دعم http3 كميزة اختيارية، للمشاريع المهتمة به؟
مقال لطيف للغاية يمكنك من خلاله الحصول على فكرة عن فوائد Discouse هنا What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
لدي فهم عام لـ HTTP/3 وأعرف كيف ولماذا هو مفيد مع WordPress/LAMP، لكنني لا أفهم لماذا سيحدث فرقًا مع Discourse.
يقلل Http3 من زمن الاستجابة عند إنشاء اتصال بين الخادم والعميل بما يصل إلى 150 مللي ثانية. بالإضافة إلى ذلك، فإنه يوفر موارد الخادم، حيث أن إنشاء اتصال HTTP أكثر اقتصادا.\n\nلذلك سيحصل المستخدم على تجربة مجتمعية أفضل وسيكون لدى مشغل الخادم عبء أقل. فوز-فوز
ليس في الوقت الحالي، للأسف.
لقد احتفظت بفرع من حاويتنا جاهزًا لـ HTTP/3 منذ (يتحقق من الملاحظات) 2019، والذي يمكنك التحقق منه على GitHub - discourse/discourse_docker at http3.
السبب في أننا لم نقم بطرحه على نطاق واسع هو مجموعة من المشاكل في النظام البيئي العام:
-
تباطأت تطوير Nginx بشكل كبير، وهم لا يواكبون تقنيات الويب الجديدة بعد الآن، مثل HTTP/3 أو التلميحات المبكرة.
-
كانت بنية Nginx المعيارية تعني أنه يمكننا إضافته عبر وحدة نمطية، وفرعي يستخدم وحدة Nginx الخاصة بـ Cloudflare، quiche، لذلك. لكن Cloudflare ابتعدت أيضًا عن nginx، ولم تُعتبر هذه الوحدة النمطية جاهزة للإنتاج أبدًا.
-
نظرت في الانتقال إلى خادم ويب أكثر حداثة، مثل Caddy، لكن التغييرات مثل هذه صعبة للغاية عندما تصدر برامج مستضافة ذاتيًا سيقوم الأشخاص بتخصيصها.
-
سيكون الانتقال إلى HAProxy أسهل، لكننا نستخدم nginx لتقديم الملفات الثابتة، وهو ما لن يفعله HAProxy.
-
حقيقة أن القائمين على صيانة OpenSSL قد قاموا بشكل أساسي بـ تخريب QUIC وأوقفوا تقدم النظام البيئي بأكمله لمدة عقد من الزمان.
كل ما سبق، بالإضافة إلى جميع المشاكل المتأصلة في الانتقال من TCP إلى UDP الذي يعد جزءًا من هذا، يعني أن هذا التغيير كان محفوفًا بالمخاطر للغاية بالنسبة لنا.
وهو أمر محزن للغاية، نظرًا لأنه في متوسط الأسرة خلال السنوات الأربع الماضية، كان معظم حركة المرور بالفعل HTTP/3، حيث هاجر كل لاعب كبير إليه منذ سنوات، مثل YouTube و Amazon و Shopify و Instagram و Twitch.tv، إلخ. هذا يزيد من الفجوة بين التكنولوجيا الكبيرة والمواقع الصغيرة، ومن المؤسف أننا لم نتمكن من أن نكون من أوائل المتبنين هنا، كما كنا مع SPDY و HTTP/2 و Brotli.
نظرًا لكل ذلك، إذا كنت تريد حلاً سهلاً بنقرة واحدة لهذه الفوضى بأكملها، يمكنك استخدام Cloudflare أمام مثيل Discourse الخاص بك.
12 إعجابًا
يؤلمني سماع ذلك. لدي بعض الأفكار لاستكشافها. هل يمكننا مناقشتها؟
- سأفكر في تثبيت وحدة نمطية في Nginx، مثل تلك التي تسمح بـ http3
- سأكتب إلى مجتمع Discourse الذي تدعمه Caddy وأسألهم عما إذا كان بإمكانهم مساعدتك في الانتقال إلى Caddy، فقد تكون شراكة مفيدة للطرفين
QUIC is not supported - Help - Caddy Community
إعجاب واحد (1)
الطريقة الأنظف لبنائه، والتي لديها القدرة على أن تصبح شيئًا نشحنه في النهاية، ستكون إضافة قالب جديد يكون بديلاً لـ web.ssl.template.yml، ولنسميه web.ssl2.template.yml.
في هذا القالب، بدلاً من تعديل nginx، يبدأ خادم ويب بديل، لنقل Caddy، والذي يتعامل مع كل حركة المرور ويوجهها إلى nginx. سيسمح هذا بالكثير من التجريب، والقدرة على اختبار خوادم ويب متعددة، ويمكن أن يتطور إلى شيء يمكننا جعله افتراضيًا للتثبيتات الجديدة.
4 إعجابات
يبدو رائعًا. أود المشاركة في الاختبار. ما هي الخطوات التالية؟
إعجابَين (2)
القيام بالعمل :ابتسامة:
5 إعجابات
هناك نهج آخر يتمثل في إضافة وكيل عكسي HTTP مخصص إلى صورة Docker للتعامل مع حركة مرور HTTP3 فقط. على سبيل المثال، يمكنك تضمين Envoy Proxy - الذي يدعم الدخول HTTP3 - وتكوينه للاستماع فقط على المنفذ 443/udp لحركة مرور h3، وتحويل جميع طلبات h3 الواردة إلى h2 أو h1.1 وإعادة توجيهها إلى مثيل Nginx.
لكنه يعتبر حلاً مؤقتًا إلى حد ما، لذا لن أقول إنها فكرة جيدة.
إعجابَين (2)
مهما كانت الطريقة التي تقرر بها، أعتقد أن http3 خطوة جيدة وستساعد النظام البيئي بأكمله. أنا أتطلع إلى الخطوات التالية.
[إفصاح: أنا مدير مجتمع مؤسسة OpenSSL اعتبارًا من يناير.]
كما اتضح، من المقرر إصدار OpenSSL 3.5 في أبريل مع دعم خادم QUIC. هناك أيضًا عرض توضيحي لخادم HTTP3 يستخدم واجهة برمجة تطبيقات QUIC الخاصة بـ OpenSSL مع nghttp3.
(نظرًا لأنه تم طرح مسألة الحوكمة في هذا الرابط، يجب أن أشير إلى أن OpenSSL اعتمد هيكل حوكمة جديد العام الماضي. أنا متفائل بحذر وأعتقد أنه ساعد في إخراج QUIC أخيرًا.)
يبدو أن nginx سيتبنى واجهة برمجة تطبيقات QUIC الخاصة بـ OpenSSL. لا يوجد مؤشر على الجدول الزمني حتى الآن.
4 إعجابات