پخش جریانی با Webship: توان عملیاتی بالا بدون معامله کردن درستی

عملکرد پخش جریانی تنها مربوط به پخش‌کننده ویدئو نیست. آثار نرم‌افزاری، وزن‌های مدل، پشتیبان‌ها، کتابخانه‌های صوتی و صادرات بزرگ API همگی به همان اصول اولیه وابسته هستند: حرکت سریع بایت‌ها، حفظ دقیق داده‌ها، رعایت بازفشار و توقف تمیز وقتی یک مشتری قطع می‌شود.

Webship این الزامات را به عنوان یک مشکل حمل و نقل واحد در سراسر HTTP/1.1، HTTP/2، HTTP/3، تحویل مستقیم فایل، پروکسی معکوس، و WebTransport در نظر می‌گیرد. مسیر سریع تنها زمانی مفید است که قاب‌بندی، لغو، تریلرها، بازرسی امنیتی و حافظه محدود را حفظ کند.

ظرفیت پخش ۱۰۰ مگابایت اندازه‌گیری شده

ظرفیت Webship 1.3.1 دبیان با استفاده از یک ثابت 100 مگابایتی، متوسط توان پردازش بار اندازه‌گیری شد. هر نمونه پذیرفته‌شده نیاز به بدنه پاسخ دقیقاً 99,943,778 بایتی و صفر خطا در کلاینت، پروتکل، پراکسی، خطای بزرگ صفحه و HTTP/3 در از دست رفتن بسته داشت.

| حالت Webship | TLS HTTP/1.1 | TLS HTTP/2 | TLS HTTP/3 | | --- | ---: | ---: | ---: | | تحویل مستقیم فایل | ۴،۱۹۴.۸ مای‌بایت/ثانیه | ۳،۵۷۴.۳ مای‌بایت/ثانیه | ۲،۰۹۶.۹ مای‌بایت/ثانیه | | پراکسی معکوس با خاتمه TLS | ۳٬۵۸۵.۷ مگابایت/ثانیه | ۳٬۳۵۵.۰ مگابایت/ثانیه | ۱٬۹۳۸.۶ مگابایت/ثانیه | | پراکسی معکوس با عبور TLS | ۲٬۷۸۳٫۲ مای‌بایت/ثانیه | ۲٬۱۳۵٫۰ مای‌بایت/ثانیه | ۱٬۷۴۸٫۵ مای‌بایت/ثانیه |

در مقایسه ثبت‌شده، Webship بالاترین مقدار میانه مستقیم و پایان‌یافته با TLS را برای هر پروتکل اندازه‌گیری شده تولید کرد. ماتریس کامل شامل Nginx، Lighttpd، Caddy، HAProxy، Envoy، Pingora و Bun در [صفحه بنچمارک](/benchmarks) است.

این اعداد ظرفیت روی میزبان معیار را اندازه‌گیری می‌کنند. آن‌ها تضمینی برای مسیر دلخواه اینترنتی نیستند. تأخیر ذخیره‌سازی، پهنای باند شبکه، زمان رفت و برگشت، از دست رفتن بسته‌ها، سیاست TLS، همزمانی و رفتار منبع همچنان سرعت واقعی تحویل را تعیین می‌کنند.

یک باینری، سه استراتژی حمل و نقل

یک پاسخ بزرگ از همان سیاستی که برای یک سند HTML کوچک استفاده می‌شود، بهره‌مند نمی‌شود. Webship مسیر درخواست معمولی را محافظه‌کار نگه می‌دارد و تنها یک پاسخ حجمی اثبات‌شده را ترویج می‌دهد.

HTTP/1.1: انتقال‌های کمتر در اطراف فایل

در لینوکس، Webship سر پاسخ و محتوای فایل را در یک بازه TCP cork با بهترین تلاش نگه می‌دارد. هنگامی که یک پاسخ بزرگ TLS برای مسیر جمعی واجد شرایط شود، تحویل مستقیم فایل می‌تواند از رکوردهای Rustls به TLS کرنل یک‌طرفه نظارت‌شده منتقل شود و از sendfile بدون کپی کردن محتوای فایل از طریق بافر برنامه استفاده کند.

ارتباط هنوز در TLS فضای کاربر آغاز می‌شود. پاسخ‌های کوچک همچنان در آنجا باقی می‌مانند. Webship تنها پس از آنکه بدنه پاسخ حداقل ۱ میبی داده ثابت کند که اتصال در حال انتقال داده حجیم است، درخواست انتقال kTLS را می‌دهد.

HTTP/2: دسته‌بندی بدون شکستن کنترل جریان

چندپخشی HTTP/2 باعث می‌شود بافرینگ غیرکنترلی پرهزینه باشد. Webship نوشتن‌ها را به‌صورت دسته‌ای انجام می‌دهد در حالی که محدودیت‌های جریان و کنترل اتصال را حفظ می‌کند. برای پخش با هم‌زمانی بالا، یک بافر نوشتن TLS به اندازه ۱۲۸ کیلوبایت می‌تواند دو فریم DATA با اندازه ۶۴ کیلوبایت را در خود نگه دارد، در حالی که بودجه ارسال اتصال به‌طور صریح و محدود باقی می‌ماند.

یک چارچوب بدنه بالادستی که از قبل آماده است می‌تواند بدون دورزدن فریمینگ هایپر، تریلرها، لغو، بازرسی یا پس‌فشار پیش‌بارگذاری شود. این باعث کاهش یک دور برنامه‌ریز قابل اجتناب می‌شود در حالی که قرارداد پروتکل را دست‌نخورده نگه می‌دارد.

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"

هنگامی که Webship باید بر اساس مسیر مسیریابی شود، بررسی‌های WAF یا API Shield را اعمال کند، محدودیت‌های بدنه را اعمال کند، هدرهای هدایت را اضافه کند یا فیلدهای HTTP را مشاهده کند، از خاتمه TLS پراکسی معکوس استفاده کنید:

[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"

بودجه اتصال فوق ۱۲۸ کیلوبایت اعتبار برای ۲۵۶ جریان فعال فراهم می‌کند. آن را به عنوان یک تصمیم ظرفیت در نظر بگیرید، نه به عنوان یک پیش‌فرض جهانی. قبل از افزایش آن، حافظه، تاخیر و توان عملیاتی را با همزمانی مورد انتظار خود اندازه‌گیری کنید.

در لینوکس، ماژول‌های هسته 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. توان عملی مداوم را همراه با CPU، حافظه، خطاهای سوکت، بازانتقال‌ها و تاخیر انتهایی اندازه‌گیری کنید.
5. حالت‌های مستقیم، پایان‌یافته با TLS و عبوری را به طور جداگانه تأیید کنید؛ آن‌ها مرزهای امنیتی و مسیر‌یابی متفاوتی دارند.
6. ابزار اندازه‌گیری را برای ترافیک تولیدی معمولی خاموش نگه دارید، سپس هنگام بررسی، تشخیص‌های محدود شده را آگاهانه فعال کنید.
7. پس از تغییرات کرنل، کانتینر، یا سندباکس systemd، kTLS و پیش‌بررسی BBR در لینوکس را دوباره بررسی کنید.

پخش جریانی زمانی سریع است که کل مسیر همکاری کند. طراحی Webship بهینه‌سازی داده‌های حجیم را مخصوص پروتکل نگه می‌دارد در حالی که یک مدل عملیاتی و یک معیار درستی را حفظ می‌کند.

مستندات کامل [Webship 1.3.1](/docs/1.3.1) را بخوانید، [روش‌شناسی بنچمارک و ماتریس رقبا](/benchmarks) را بررسی کنید، یا یک نسخه امضا شده را از [دانلودها](/downloads) دریافت کنید.