Streaming dengan Webship: Throughput Tinggi Tanpa Mengorbankan Ketelitian

Kinerja streaming tidak hanya menjadi perhatian pemutar video. Artefak perangkat lunak, bobot model, cadangan, perpustakaan audio, dan ekspor API besar semuanya bergantung pada hal-hal mendasar yang sama: memindahkan byte dengan cepat, menjaga payload tetap utuh, menghormati tekanan balik, dan berhenti dengan bersih saat seorang klien terputus.

Webship memperlakukan persyaratan tersebut sebagai satu masalah transportasi di seluruh HTTP/1.1, HTTP/2, HTTP/3, pengiriman file langsung, reverse proxying, dan WebTransport. Jalur cepat hanya berguna ketika mempertahankan pembingkaian, pembatalan, trailer, inspeksi keamanan, dan penggunaan memori yang terbatas.

Kapasitas streaming diukur 100 MB

Kapasitas Webship 1.3.1 Debian diukur dengan median throughput muatan menggunakan fixture 100 MB tetap. Setiap sampel yang diterima memerlukan body respons sebesar 99.943.778 byte tepat dan tidak ada kesalahan klien, protokol, proxy, kesalahan halaman-besar, dan HTTP/3 kehilangan paket.

| Webship mode | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Pengiriman file langsung | 4.194,8 MiB/dtk | 3.574,3 MiB/dtk | 2.096,9 MiB/dtk | | Reverse proxy dengan terminasi TLS | 3.585,7 MiB/dtk | 3.355,0 MiB/dtk | 1.938,6 MiB/dtk | | Reverse proxy dengan TLS pass-through | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

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

Angka-angka ini mengukur kapasitas pada host patokan. Mereka bukan janji untuk jalur internet sembarangan. Latensi penyimpanan, bandwidth jaringan, waktu perjalanan pulang-pergi, kehilangan paket, kebijakan TLS, konkurensi, dan perilaku asal masih menentukan kecepatan pengiriman yang sebenarnya.

Satu biner, tiga strategi transportasi

Respon besar tidak mendapat manfaat dari kebijakan yang sama seperti dokumen HTML kecil. Webship menjaga jalur permintaan biasa tetap konservatif dan hanya mempromosikan respon massal yang telah terbukti.

HTTP/1.1: lebih sedikit transisi di sekitar file

Di Linux, Webship menjaga head respons dan payload file di dalam satu interval TCP cork best-effort. Setelah respons TLS besar memenuhi syarat untuk jalur bulk, pengiriman file langsung dapat berpindah dari catatan Rustls ke kernel TLS satu arah yang diaudit dan menggunakan sendfile tanpa menyalin payload melalui buffer aplikasi.

Koneksi masih dimulai di TLS ruang pengguna. Respons kecil tetap di sana. Webship meminta transisi kTLS hanya setelah body respons setidaknya 1 MiB membuktikan bahwa koneksi membawa data dalam jumlah besar.

HTTP/2: pengelompokan tanpa memutus kontrol aliran

HTTP/2 multiplexing membuat buffering yang tidak terkendali menjadi mahal. Webship melakukan batch pada penulisan sambil mempertahankan batas kontrol aliran stream dan koneksi. Untuk streaming dengan tingkat konkurensi tinggi, buffer penulisan TLS 128 KiB dapat menampung dua frame DATA 64 KiB, sementara anggaran pengiriman koneksi tetap eksplisit dan terbatas.

Bingkai tubuh hulu yang sudah siap dapat diambil sebelumnya tanpa melewati pemraman Hyper, trailer, pembatalan, inspeksi, atau tekanan balik. Itu mengurangi putaran penjadwal yang dapat dihindari sambil menjaga kontrak protokol tetap utuh.

HTTP/3: Penjadwalan QUIC menggantikan kTLS

HTTP/3 tidak pernah menggunakan jalur TCP kTLS. Webship menerapkan pengaturan laju QUIC yang sadar transport, paketisasi datagram terbatas, DPLPMTUD, dan microbatching berbasis timer per-reaktor. Tanggapan HTTP/3 yang besar dan sesi WebTransport yang diterima dapat memilih BBR tanpa mengubah kebijakan CUBIC yang digunakan oleh lalu lintas biasa.

Kualifikasi stabilitas HTTP/3 yang difokuskan menggunakan tujuh sampel yang diterima. Streaming yang dihentikan dengan TLS memberikan median 1.938,6 MiB/s dengan koefisien variasi 2,12%. Pass-through TLS memberikan 1.748,5 MiB/s dengan koefisien variasi 1,65%. Kedua seri tersebut tidak memiliki kesalahan integritas tubuh, klien, protokol, maupun kehilangan paket.

Pengiriman langsung atau proxy terbalik?

Gunakan pengiriman langsung ketika Webship memiliki pohon file yang dikerahkan. Ini menghilangkan lompatan asal dan memungkinkan jalur file statis yang paling efisien.

Sebuah situs multi-protokol minimal terlihat 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 terminasi TLS reverse-proxy ketika Webship harus melakukan routing berdasarkan jalur, menerapkan pemeriksaan WAF atau API Shield, menegakkan batasan tubuh, menambahkan header penerusan, atau mengamati bidang 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"]

Setel tls_termination = false ketika asal harus mempertahankan plaintext aplikasi dan kunci sesi aktif. Pass-through tidak dapat memeriksa bidang HTTP yang terenkripsi. Oleh karena itu, pass-through TCP diarahkan berdasarkan SNI ClientHello, sementara pass-through HTTP/3 memerlukan satu asal UDP yang dibagikan.

Atur streaming massal secara eksplisit

Untuk streaming TLS HTTP/2 dengan konkruensi tinggi, Webship mendokumentasikan pengaturan yang terkait dengan 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"

Anggaran koneksi di atas menyediakan 128 KiB kredit untuk 256 aliran aktif. Anggap ini sebagai keputusan kapasitas, bukan default universal. Ukur memori, latensi, dan throughput dengan tingkat konkruensi yang diharapkan sebelum meningkatkannya.

Di Linux, muat modul kernel TLS dan BBR serta izinkan akun layanan Webship untuk memilih BBR. Webship gagal sebelum melakukan binding ketika kemampuan kernel yang diperlukan tidak tersedia, sehingga sebuah deployment tidak dapat secara diam-diam menggunakan jalur yang dioptimalkan saat dijalankan tanpa kemampuan tersebut. Sistem operasi lain mempertahankan jalur Rustls dan pengendalian kemacetan yang portabel seperti yang didokumentasikan untuk platform mereka.

WebTransport adalah bentuk streaming yang berbeda

WebTransport menggabungkan aliran yang dapat diandalkan dan datagram yang tidak dapat diandalkan melalui sesi yang aman. Itu tidak menggunakan TCP kTLS. Titik akhir diagnostik terbatas Webship memvalidasi asal dan memberlakukan batas sesi, aliran, kapsul, datagram, byte, dan waktu diam.

Dalam uji kapasitas 1.3.1, WebTransport langsung mencapai 1.018,1 MiB/s untuk aliran yang andal dan 1.038,9 MiB/s untuk datagram. Lalu lintas TLS mencapai 548,6 MiB/s dan 629,7 MiB/s masing-masing. Kedua mode melewati semua lima sampel dengan nol sampel ditolak, nol datagram hilang, dan nol kesalahan besar klien.

Preferensi HTTP/3 untuk klien WebTransport baru. Jalur HTTP/2 ada untuk kompatibilitas dengan pengaturan draft kadaluwarsa yang lebih lama.

Apa yang harus diverifikasi sebelum lalu lintas produksi

1. Ujilah ukuran media atau artefak yang sebenarnya akan Anda sajikan, bukan hanya respons sintetis yang kecil.
2. Verifikasi panjang respons dan ringkasan konten di klien.
3. Pembatalan latihan, permintaan jangkauan, pembaca lambat, dan perilaku setengah-tutup asal.
4. Ukur throughput berkelanjutan bersama dengan CPU, memori, kesalahan soket, pengiriman ulang, dan latensi ekor.
5. Validasi mode langsung, yang berakhir TLS, dan pass-through secara terpisah; mereka memiliki batas keamanan dan routing yang berbeda.
6. Biarkan instrumentasi mati untuk lalu lintas produksi normal, kemudian aktifkan diagnostik terbatas secara sengaja saat melakukan investigasi.
7. Periksa ulang kTLS Linux dan BBR preflight setelah perubahan kernel, container, atau sandbox systemd.

Streaming berjalan cepat ketika seluruh jalur bekerja sama. Desain Webship menjaga optimisasi data besar tetap spesifik pada protokol sambil mempertahankan satu model operasional dan satu standar kebenaran.

Baca lengkap [Webship 1.3.1 dokumentasi](/docs/1.3.1), periksa [metodologi tolok ukur dan matriks pesaing](/benchmarks), atau unduh build yang ditandatangani dari [Unduhan](/downloads).