البث مع Webship: معدل نقل عالٍ دون التضحية بالدقة

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

Webship يتعامل مع تلك المتطلبات كمشكلة نقل واحدة عبر HTTP/1.1، HTTP/2، HTTP/3، التسليم المباشر للملفات، البروكسي المعكوس، و WebTransport. المسار السريع مفيد فقط عندما يحافظ على التأطير، الإلغاء، الملاحق، فحص الأمان، والذاكرة المحدودة.

سعة البث المقاسة 100 ميغابايت

تم قياس قدرة تشغيل Webship 1.3.1 على ديبيان من خلال متوسط معدل نقل الحمولة مع تثبيت ثابت بحجم 100 ميجابايت. كل عينة مقبولة تطلبت جسم استجابة بحجم 99,943,778 بايت بالضبط وخلو من أخطاء العميل والبروتوكول والوكلاء، وأخطاء الصفحة الرئيسية الكبرى، و HTTP/3 فقدان الحزم.

| وضع Webship | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | التسليم المباشر للملفات | 4,194.8 ميبي/ث | 3,574.3 ميبي/ث | 2,096.9 ميبي/ث | | وكيل عكسي مع إنهاء TLS | 3,585.7 ميبي/ث | 3,355.0 ميبي/ث | 1,938.6 ميبي/ث | | الوكيل العكسي مع تمرير TLS | 2,783.2 ميبي/ثانية | 2,135.0 ميبي/ثانية | 1,748.5 ميبي/ثانية |

في المقارنة المسجلة، حقق Webship أعلى المتوسطات المباشرة وTLS-المنهية لكل بروتوكول تم قياسه. تشمل المصفوفة الكاملة Nginx، Lighttpd، Caddy، HAProxy، Envoy، Pingora، وBun على [صفحة المعايير](/benchmarks).

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

ثنائي واحد، ثلاث استراتيجيات نقل

الاستجابة الكبيرة لا تستفيد من نفس السياسة التي يستفيد منها مستند HTML صغير. Webship يحافظ على مسار الطلب العادي محافظًا ويعزز فقط الاستجابة الجماعية المثبتة.

HTTP/1.1: انتقالات أقل حول الملف

على لينكس، Webship يحتفظ برأس الاستجابة وبيانات الملف داخل فترة كورك TCP بأفضل جهد. بمجرد أن تتأهل استجابة TLS الكبيرة لمسار الدُفعات، يمكن لتسليم الملف المباشر أن ينتقل من سجلات Rustls إلى TLS kernel أحادي الاتجاه المفحوص واستخدام sendfile دون نسخ الحمولة عبر مخزن مؤقت للتطبيق.

يبدأ الاتصال لا يزال في TLS في مساحة المستخدم. تظل الاستجابات الصغيرة هناك. Webship يطلب الانتقال إلى kTLS فقط بعد أن يثبت جسم الاستجابة الذي لا يقل عن 1 ميبيبايت أن الاتصال ينقل بيانات ضخمة.

HTTP/2: التجميع دون كسر التحكم في التدفق

التعدد المتعدد HTTP/2 يجعل التخزين المؤقت غير المنضبط مكلفًا. Webship يجمع عمليات الكتابة مع الاحتفاظ بحدود التحكم في تدفق الاتصال والتدفق. بالنسبة للبث عالي التزامن، يمكن لمخزن كتابة TLS بحجم 128 كيلوبايت أن يحتوي على إطارين DATA بحجم 64 كيلوبايت لكل منهما، بينما يظل ميزانية الإرسال للاتصال صريحة ومحدودة.

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

HTTP/3: تنظيم مرور QUIC بدلًا من kTLS

HTTP/3 لا يستخدم أبدًا مسار TCP kTLS. Webship يطبق تنظيم حركة QUIC الواعي بالنقل، وتجزيء الحزم المحدودة، وDPLPMTUD، والدفعات الدقيقة المدفوعة بالمؤقت لكل مفاعل. يمكن للاستجابات الكبيرة لـ HTTP/3 والجلسات المقبولة لـ WebTransport اختيار BBR دون تغيير سياسة CUBIC المستخدمة في حركة المرور العادية.

تأهيل الاستقرار المركز HTTP/3 استخدم سبع عينات مقبولة. قدم البث المنتهي بـ TLS متوسطًا يبلغ 1,938.6 ميبيبايت/ثانية مع معامل تباين 2.12%. بينما قدم تمرير TLS متوسطًا يبلغ 1,748.5 ميبيبايت/ثانية مع معامل تباين 1.65%. لم تسجل أي من السلاسل أي أخطاء في تكامل الجسم أو العميل أو البروتوكول أو فقدان الحزم.

التسليم المباشر أم الوكيل العكسي؟

استخدم التسليم المباشر عندما يكون Webship هو مالك شجرة الملفات المنتشرة. فهو يزيل النقلة الأصلية ويمكّن من أكثر مسار للملفات الثابتة كفاءة.

يبدو الموقع متعدد البروتوكولات البسيط هكذا:

listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"

[[sites]]
domain = "media.example.com"
root = "/srv/media"

[sites.protocols]
h1 = true
h2 = true
h3 = true

[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"

استخدم إنهاء TLS عبر البروكسي العكسي عندما يجب على Webship التوجيه حسب المسار، تطبيق فحص WAF أو API Shield، فرض حدود على الجسم، إضافة رؤوس إعادة التوجيه، أو مراقبة حقول HTTP:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]

اضبط tls_termination = false عندما يجب أن يحتفظ المصدر بالنصوص العادية للتطبيق ومفاتيح الجلسة النشطة. لا يمكن للتمرير المباشر فحص حقول HTTP المشفرة. لذلك يقوم التمرير عبر TCP بالتوجيه حسب SNI في ClientHello، بينما يتطلب التمرير عبر HTTP/3 مصدر UDP مشترك واحد.

اضبط البث الجماعي صراحة

للبث عبر TLS عالي التزامن HTTP/2، يقوم Webship بتوثيق إعدادات مرتبطة بالعملية التالية:

[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"

يوفر جدول ميزانية الاتصال أعلاه 128 كيب من الائتمان لـ 256 تدفقًا نشطًا. اعتبره قرارًا متعلقًا بالسعة، وليس افتراضيًا عامًا. قس الذاكرة والكمون ومعدل النقل لديك حسب التزامن المتوقع قبل زيادته.

على نظام لينوكس، قم بتحميل وحدات نواة TLS وBBR واسمح لحساب الخدمة Webship باختيار BBR. يفشل Webship قبل الربط عندما تكون القدرة المطلوبة في النواة غير متوفرة، لذلك لا يمكن للنشر أن يدعي المسار المحسن بشكل صامت أثناء التشغيل بدونها. تحتفظ أنظمة التشغيل الأخرى بالمسارات المحمولة Rustls ومسارات التحكم في الازدحام الموثقة لمنصتها.

WebTransport هو شكل بث مختلف

WebTransport يجمع بين التدفقات الموثوقة والبيانات غير الموثوقة عبر جلسة آمنة. لا يستخدم TCP kTLS. يقوم نقطة التشخيص المحدودة في Webship بالتحقق من الأصول وفرض حدود الجلسة والتدفق والكبسولة والبيانات والبايت وزمن الخمول.

في تشغيل السعة 1.3.1، وصل النقل المباشر WebTransport إلى 1,018.1 ميبيبايت/ثانية للبثوث الموثوقة و1,038.9 ميبيبايت/ثانية للحزم. وصل تمرير TLS إلى 548.6 ميبيبايت/ثانية و629.7 ميبيبايت/ثانية على التوالي. كلا الوضعين اجتازا جميع العينات الخمس بدون أي عينات مرفوضة، أو حزم مفقودة، أو أعطال كبرى للعميل.

فضل HTTP/3 للعملاء الجدد لـ WebTransport. مسار HTTP/2 موجود للتوافق مع إعدادات المسودات المنتهية الأقدم.

ما الذي يجب التحقق منه قبل حركة المرور في الإنتاج

1. اختبر أحجام الوسائط أو القطع الأثرية الدقيقة التي ستقدمها، وليس مجرد استجابة صناعية صغيرة.
2. تحقق من طول الاستجابة ومُلخص المحتوى على العميل.
3. إلغاء التمرين، طلبات النطاق، القراء البطيئون، وسلوك نصف الإغلاق للأصل.
4. قم بقياس معدل النقل المستمر جنبًا إلى جنب مع وحدة المعالجة المركزية والذاكرة وأخطاء المقبس وإعادة الإرسال وزمن الانتقال النهائي.
5. تحقق من أوضاع الاتصال المباشر، وإنهاء TLS، والتمرير الممرّ؛ فهي لديها حدود أمان وتوجيه مختلفة.
6. احتفظ بالأدوات مغلقة لحركة الإنتاج العادية، ثم قم بتمكين التشخيص المقيد عمداً عند التحقيق.
7. أعد فحص kTLS وBBR في لينكس بعد تغييرات النواة أو الحاوية أو صندوق الرمل systemd.

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

اقرأ الوثائق الكاملة لـ [Webship 1.3.1](/docs/1.3.1)، وتفقد [منهجية القياس ومصفوفة المنافسين](/benchmarks)، أو قم بتنزيل إصدار موقع من [التنزيلات](/downloads).