Streaming kasama ang Webship: Mataas na Daloy ng Datos Nang Hindi Isinasakripisyo ang Katumpakan

Ang pagganap sa streaming ay hindi lamang alalahanin ng isang video player. Ang mga software artifact, bigat ng modelo, backup, audio library, at malalaking API export ay nakadepende rin sa parehong mga pundamental: ilipat nang mabilis ang mga byte, panatilihin ang eksaktong payload, igalang ang backpressure, at huminto nang maayos kapag nag-disconnect ang kliyente.

Webship tinuturing ang mga kinakailangang iyon bilang isang problema sa transportasyon sa buongHTTP/1.1, HTTP/2, HTTP/3, direktang paghahatid ng file, reverse proxying, at WebTransport. Kapaki-pakinabang lamang ang mabilis na daan kapag napapanatili nito ang framing, pagkansela, trailers, inspeksyon ng seguridad, at limitadong memorya.

Sinukat na 100 MB kakayahan sa streaming

Ang Webship 1.3.1 Nasusukat ang kapasidad ng Debian gamit ang median na daloy ng payload throughput sa isang nakapirming 100 MB na fixture. Bawat tinanggap na sample ay nangangailangan ng eksaktong 99,943,778-byte na katawan ng tugon at walang client, protocol, proxy, major-page-fault, at HTTP/3 mga error sa pagkawala ng packet.

| Webship mode | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Direktang paghahatid ng file | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | Reverse proxy na may TLS termination | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Reverse proxy na may TLS pass-through | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

Sa naitalang paghahambing,Webship nagsagawa ng pinakamataas na direktang at TLS-tapos na median para sa bawat sinusukat na protocol. Kasama sa kumpletong matrix angNginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora, at Bun sa [pahina ng benchmark](/benchmarks).

Ang mga numerong ito ay sumusukat ng kapasidad sa benchmark host. Hindi ito pangako para sa isang arbitraryong internet path. Ang latency ng storage, bandwidth ng network, round-trip time, pagkawala ng packet, patakaran sa TLS, concurrency, at asal ng pinagmulan ay patuloy na tumutukoy sa totoong bilis ng paghahatid.

Isang binaryo, tatlong estratehiya sa transportasyon

Ang isang malaking tugon ay hindi nakikinabang mula sa parehong patakaran tulad ng isang maliit na dokumentong HTML.Webship pinapanatili ang karaniwang landas ng kahilingan na konserbatibo at itinataguyod lamang ang subok na maramihang tugon.

HTTP/1.1: mas kaunting pagbabago sa paligid ng file

Sa Linux, Webship pinapanatili ang response head at file payload sa loob ng isang best-effort TCP cork interval. Kapag ang isang malaking TLS response ay kwalipikado para sa bulk path, maaaring lumipat ang direktang paghahatid ng file mula saRustIlista ang mga rekord sa na-audit na one-way kernel TLS at gamitin ang sendfile nang hindi kopyahin ang payload sa pamamagitan ng application buffer.

Ang koneksyon ay nagsisimula pa rin sa userspace TLS. Maliit na mga tugon ay nananatili doon.Webship inaasahan ang kTLS na paglipat lamang pagkatapos ng isang katawan ng tugon na hindi bababa sa 1 MiB na nagpapatunay na ang koneksyon ay nagdadala ng dambuhalang datos.

HTTP/2: pagbubuo ng batch nang hindi sinisira ang kontrol ng daloy

HTTP/2 Ginagawang mahal ng multiplexing ang hindi kontroladong pag-buffer.Webship Ang mga batch ay nagsusulat habang pinananatili ang mga limitasyon ng daloy ng kontrol ng stream at koneksyon. Para sa mataas na sabayang streaming, ang 128 KiB na TLS write buffer ay maaaring humawak ng dalawang 64 KiB na DATA frame, habang ang badyet ng pagpapadala ng koneksyon ay nananatiling malinaw at limitado.

Maaaring kunin nang maaga ang isang handa nang upstream body frame nang hindi nilalaktawan ang Hyper framing, trailers, pagkansela, inspeksyon, o backpressure. Binabawasan nito ang isang maiiwasang pag-ikot ng scheduler habang pinapanatili ang buo ng kontrata ng protocol.

HTTP/3: QUIC pacing sa halip na kTLS

HTTP/3 hindi ginagamit kailanman ang TCP kTLS na daan.Webship nagpapatupad ng transport-aware QUIC pacing, bounded datagram packetization, DPLPMTUD, at per-reactor timer-driven microbatching. MalakiHTTP/3 mga tugon at tinanggapWebTransport maaaring pumili ang mga session ng BBR nang hindi binabago ang patakaran ng CUBIC na ginagamit ng karaniwang trapiko.

Ang nakatutokHTTP/3 Ang kwalipikasyong pangkatatagan ay gumamit ng pitong tinanggap na mga sample. Ang TLS-terminated streaming ay nagbigay ng median na 1,938.6 MiB/s na may 2.12% coefficient of variation. Ang TLS pass-through ay nagbigay ng 1,748.5 MiB/s na may 1.65% coefficient of variation. Ang parehong serye ay walang mga error sa integridad ng katawan, client, protocol, at pagkawala ng packet.

Direktang paghahatid o reverse proxy?

Gumamit ng direktang paghahatid kapagWebship pag-aari ng naka-deploy na file tree. Tinatanggal nito ang origin hop at pinapagana ang pinakaepektibong static-file path.

Ganito ang hitsura ng isang minimal na multi-protocol na site:

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"

Gumamit ng reverse-proxy TLS termination kapagWebship dapat i-route batay sa path, magpatupad ng WAF o API Shield checks, ipatupad ang mga limitasyon sa katawan, magdagdag ng mga forwarding headers, o obserbahan ang mga HTTP fields:

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

Itakdatls_termination = false kapag ang pinagmulan ay dapat panatilihin ang plaintext ng aplikasyon at aktibong mga susi ng sesyon. Ang pass-through ay hindi maaaring suriin ang naka-encrypt na mga patlang ng HTTP. Kaya't ang TCP pass-through ay nagri-route batay sa ClientHello SNI, habangHTTP/3 kinakailangan ng pass-through ng isang pinag-isang UDP na pinagmulan.

I-tune ang maramihang streaming nang tahasan

Para sa mataas na sabayang pag-accessHTTP/2 TLS streamingWebship idokumento ang mga setting na nakatali sa proseso na ito:

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

Ang connection budget sa itaas ay nagbibigay ng 128 KiB na credit para sa 256 na aktibong stream. Ituring ito bilang desisyon sa kapasidad, hindi bilang pangkalahatang default. Sukatin ang memorya, latency, at throughput ayon sa inaasahang sabayang paggamit bago ito pataasin.

Sa Linux, i-load ang kernel TLS at BBR na mga module at pahintulutan ang Webship account ng serbisyo para piliin ang BBR.Webship nabibigo bago ang binding kapag ang kinakailangang kakayahan ng kernel ay hindi magagamit, kaya ang isang deployment ay hindi maaaring tahimik na kunin ang na-optimize na path habang tumatakbo nang wala ito. Ang ibang mga operating system ay pinananatili ang portableRustls at mga landas ng pagkontrol sa pagsisikip na naitala para sa kanilang plataporma.

WebTransport ay isang ibang anyo ng streaming

WebTransport pinagsasama ang maaasahang mga stream at hindi maaasahang mga datagram sa isang ligtas na sesyon. Hindi nito ginagamit ang TCP kTLS.WebshipAng naka-bounded na diagnostic endpoint nito ay nagva-validate ng mga pinagmulan at nagpapatupad ng mga limitasyon sa session, stream, capsule, datagram, byte, at idle-time.

Sa 1.3.1 na pagpapatakbo ng kapasidad, direktaWebTransport umabot sa 1,018.1 MiB/s para sa maaasahang mga stream at 1,038.9 MiB/s para sa mga datagram. Umabot ang TLS pass-through sa 548.6 MiB/s at 629.7 MiB/s ayon sa pagkakabanggit. Parehong mode ay pumasa sa lahat ng limang sample na walang tinanggihan na sample, walang nawalang datagram, at walang malaking mali sa kliyente.

Mas gustoHTTP/3 para sa bagoWebTransport mga kliyente. Ang HTTP/2 Umiiral ang path para sa pagiging compatible sa mas lumang expired-draft settings.

Ano ang dapat beripikahin bago ang produksiyong trapiko

1. Subukan ang eksaktong laki ng media o artepakto na ihahain mo, hindi lamang ang maliit na artipisyal na tugon.
2. Suriin ang haba ng tugon at buod ng nilalaman sa kliyente.
3. Kanselasyon ng ehersisyo, mga kahilingan sa hanay, mabagal na mambabasa, at kalahating pagsasara ng pinagmulan na pag-uugali.
4. Sukatin ang patuloy na throughput kasabay ng CPU, memorya, mga error sa socket, mga retransmit, at tail latency.
5. I-validate ang direct, TLS-terminated, at pass-through na mga mode nang hiwalay; mayroon silang magkaibang mga hangganan sa seguridad at pag-ruta.
6. Panatilihing naka-off ang instrumentation para sa normal na production traffic, pagkatapos ay sadyang paganahin ang bounded diagnostics kapag nagsisiyasat.
7. Muling suriin ang Linux kTLS at BBR preflight pagkatapos ng mga pagbabago sa kernel, container, o systemd sandbox.

Mabilis ang streaming kapag ang buong ruta ay nagtatulungan.WebshipPinapanatili ng disenyo nito ang mga batayang-optimizasyon ng data na tiyak sa protocol habang pinangangalagaan ang isang modelo ng operasyon at isang pamantayan ng katumpakan.

Basahin ang kumpleto [Webship 1.3.1 dokumentasyon](/docs/1.3.1), suriin ang [benchmark methodology at competitor matrix](/benchmarks), o i-download ang isang pinirmahang build mula sa [Downloads](/downloads).