Penstriman dengan Webship: Lalu Lintas Tinggi Tanpa Mengorbankan Ketepatan

Prestasi penstriman bukan sahaja menjadi kebimbangan pemain video. Artefak perisian, berat model, sandaran, perpustakaan audio, dan eksport API besar semuanya bergantung pada asas yang sama: memindahkan bait dengan cepat, mengekalkan muatan persis, menghormati tekanan balik, dan berhenti dengan bersih apabila klien terputus sambungan.

Webship menganggap keperluan-keperluan itu sebagai satu masalah penghantaran merentasi HTTP/1.1, HTTP/2, HTTP/3, penghantaran fail terus, proksi terbalik, dan WebTransport. Laluan pantas hanya berguna apabila ia mengekalkan pembingkaian, pembatalan, pengiring, pemeriksaan keselamatan, dan memori terhad.

Kapasiti penstriman diukur 100 MB

Webship 1.3.1 kapasiti Debian dijalankan dengan ukuran median muatan throughput menggunakan alat tetap 100 MB. Setiap sampel yang diterima memerlukan badan respons tepat 99,943,778 bait dan sifar ralat klien, protokol, proksi, major-page-fault, dan HTTP/3 kehilangan paket.

| mod Webship | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Penghantaran fail terus | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | Proksi terbalik dengan penamatan TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Proksi terbalik dengan laluan TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

Dalam perbandingan yang direkodkan, Webship menghasilkan median langsung dan TLS-terminated tertinggi untuk setiap protokol yang diukur. Matriks lengkap termasuk Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora, dan Bun di [halaman penanda aras](/benchmarks).

Nombor-nombor ini mengukur kapasiti pada hos penanda aras. Ia bukan janji untuk laluan internet sewenang-wenangnya. Latensi storan, lebar jalur rangkaian, masa pergi-balik, kehilangan peket, polisi TLS, keserentakan, dan perilaku asal masih menentukan kelajuan penghantaran sebenar.

Satu binari, tiga strategi pengangkutan

Respons besar tidak mendapat manfaat daripada polisi yang sama seperti dokumen HTML kecil. Webship mengekalkan laluan permintaan biasa secara konservatif dan hanya menggalakkan respons pukal yang terbukti.

HTTP/1.1: lebih sedikit peralihan di sekitar fail

Pada Linux, Webship mengekalkan kepala respons dan muatan fail di dalam satu selang gabus TCP usaha terbaik. Setelah respons TLS yang besar memenuhi syarat untuk laluan pukal, penghantaran fail terus boleh berpindah dari rekod Rustls ke TLS kernel sehala yang diaudit dan menggunakan sendfile tanpa menyalin muatan melalui penimbal aplikasi.

Sambungan masih bermula dalam TLS ruang pengguna. Respons kecil tetap di situ. Webship hanya meminta peralihan kTLS selepas badan respons sekurang-kurangnya 1 MiB membuktikan bahawa sambungan membawa data pukal.

HTTP/2: pemrosesan berkelompok tanpa memutuskan kawalan aliran

Pembuatan HTTP/2 berbilang aliran menjadikan penimbal tanpa kawalan mahal. Webship mengelompokkan penulisan sambil mengekalkan had kawalan aliran aliran dan sambungan. Untuk penstriman berkecekapan tinggi, penimbal penulisan TLS 128 KiB boleh menampung dua bingkai DATA 64 KiB, sementara belanjawan penghantaran sambungan kekal jelas dan terhad.

Rangka badan hulu yang sudah sedia boleh dipra-muat tanpa memintas penbingkisan Hyper, treler, pembatalan, pemeriksaan, atau tekanan balik. Ini mengurangkan pusingan penyusun tugas yang boleh dielakkan sambil mengekalkan kontrak protokol.

HTTP/3: Penjadualan QUIC dan bukannya kTLS

HTTP/3 tidak pernah menggunakan laluan kTLS TCP. Webship menerapkan pengawalan QUIC yang menyedari pengangkutan, paketisasi datagram terhad, DPLPMTUD, dan microbatching yang digerakkan oleh pemasa bagi setiap reaktor. Respons HTTP/3 yang besar dan sesi WebTransport yang diterima boleh memilih BBR tanpa mengubah polisi CUBIC yang digunakan oleh trafik biasa.

Kelayakan kestabilan HTTP/3 yang difokuskan menggunakan tujuh sampel yang diterima. Penstriman berakhir-TLS memberikan median 1,938.6 MiB/s dengan pekali variasi 2.12%. Penstriman lepasi-TLS memberikan 1,748.5 MiB/s dengan pekali variasi 1.65%. Kedua-dua siri tidak mempunyai sebarang kesilapan integriti badan, klien, protokol, dan kehilangan paket.

Penghantaran terus atau proksi terbalik?

Gunakan penghantaran terus apabila Webship memiliki pokok fail yang digunakan. Ia menghapuskan lonjakan asal dan membolehkan laluan fail statik yang paling cekap.

Laman pelbagai protokol minimal kelihatan seperti ini:

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"

Gunakan penamatan TLS proksi terbalik apabila Webship mesti menghala mengikut laluan, menggunakan pemeriksaan WAF atau API Shield, menguatkuasakan had badan, menambah pengepala penerusan, atau memerhatikan medan 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"]

Tetapkan tls_termination = false apabila asal mesti mengekalkan plaintext aplikasi dan kunci sesi aktif. Lalu lintas pass-through tidak dapat memeriksa medan HTTP yang disulitkan. Oleh itu, pass-through TCP menghala berdasarkan ClientHello SNI, manakala pass-through HTTP/3 memerlukan satu asal UDP yang dikongsi.

Laraskan penstriman pukal secara eksplisit

Untuk penstriman TLS HTTP/2 berbilang serentak tinggi, Webship mendokumentasikan tetapan terikat-proses ini:

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

Bajet sambungan di atas menyediakan 128 KiB kredit untuk 256 aliran aktif. Anggap ia sebagai keputusan kapasiti, bukan tetapan lalai sejagat. Ukur memori, kelewatan, dan hasil dengan kebolehtarangkuman yang dijangkakan sebelum meningkatkannya.

Pada Linux, muatkan modul TLS dan BBR kernel dan benarkan akaun perkhidmatan Webship untuk memilih BBR. Webship gagal sebelum pengikatan apabila keupayaan kernel yang diperlukan tidak tersedia, jadi sesebuah penyebaran tidak boleh secara senyap menuntut laluan yang dioptimumkan semasa berjalan tanpa ia. Sistem pengendalian lain mengekalkan laluan Rustls dan kawalan kesesakan yang mudah alih yang didokumenkan untuk platform mereka.

WebTransport adalah bentuk penstriman yang berbeza

WebTransport menggabungkan aliran yang boleh dipercayai dan datagram yang tidak boleh dipercayai melalui sesi yang selamat. Ia tidak menggunakan TCP kTLS. Titik diagnostik terhad Webship mengesahkan asal dan menguatkuasakan had sesi, aliran, kapsul, datagram, bait, dan masa menganggur.

Dalam ujian kapasiti 1.3.1, WebTransport terus mencapai 1,018.1 MiB/s untuk aliran boleh dipercayai dan 1,038.9 MiB/s untuk datagram. Lintasan TLS mencapai 548.6 MiB/s dan 629.7 MiB/s masing-masing. Kedua-dua mod lulus semua lima sampel dengan sifar sampel ditolak, sifar datagram hilang, dan sifar kesalahan utama klien.

Utamakan HTTP/3 untuk klien baru WebTransport. Laluan HTTP/2 wujud untuk keserasian dengan tetapan draf tamat tempoh yang lama.

Apa yang perlu disahkan sebelum trafik pengeluaran

1. Uji saiz media atau artifak sebenar yang akan anda sampaikan, bukan hanya respons sintetik kecil.
2. Sahkan panjang respons dan ringkasan kandungan di pihak klien.
3. Pembatalan latihan, permintaan julat, pembaca perlahan, dan tingkah laku separuh tutup asal.
4. Ukur kelajuan pemindahan berterusan bersama dengan CPU, memori, ralat soket, penghantaran semula, dan kelewatan ekor.
5. Sahkan mod langsung, berakhir TLS, dan laluan terus secara berasingan; mereka mempunyai sempadan keselamatan dan penghantaran yang berbeza.
6. Pastikan instrumentasi dimatikan untuk trafik pengeluaran normal, kemudian aktifkan diagnostik terbatas dengan sengaja semasa menyiasat.
7. Periksa semula kTLS dan BBR Linux selepas perubahan kernel, kontena, atau sandbox systemd.

Penstriman adalah pantas apabila seluruh laluan bekerjasama. Reka bentuk Webship mengekalkan pengoptimuman data besar khusus protokol sambil mengekalkan satu model operasi dan satu piawaian ketepatan.

Baca keseluruhan [Webship 1.3.1 dokumentasi](/docs/1.3.1), periksa [metodologi penanda aras dan matriks pesaing](/benchmarks), atau muat turun binaan yang ditandatangani dari [Muat Turun](/downloads).