Terug naar de Webship blog

Webship techniek

Streaming met Webship: Hoge doorvoer zonder correctheid op te geven

Leer hoe Webship grote mediabestanden bedient en proxy't via HTTP/1.1, HTTP/2 en HTTP/3 met behulp van adaptief kTLS, BBR-pacing, begrensde buffers en foutenloze integriteitspoorten.

Streamingprestaties zijn niet alleen een zorg van videospelers. Software-artifacten, modelgewichten, back-ups, audiobibliotheken en grote API-exports zijn allemaal afhankelijk van hetzelfde fundament: verplaats bytes snel, behoud de exacte payload, respecteer backpressure en stop netjes wanneer een client loskoppelt.

Webship behandelt die vereisten als één transportprobleem overHTTP/1.1, HTTP/2, HTTP/3, directe bestandslevering, reverse proxying, en WebTransport. Het snelle pad is alleen nuttig wanneer het framing, annulering, trailers, beveiligingsinspectie en begrensd geheugen behoudt.

Gemeten streamingcapaciteit van 100 MB

De Webship 1.3.1 Debian-capaciteitstest gemeten mediane payload-doorvoer met een vaste 100 MB-fixture. Elke geaccepteerde steekproef vereiste exact het 99.943.778-byte responslichaam en nul client-, protocol-, proxy-, major-page-fault- enHTTP/3 pakketverliesfouten.

| Webship modus | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Directe bestandsoverdracht | 4.194,8 MiB/s | 3.574,3 MiB/s | 2.096,9 MiB/s | | Reverse proxy met TLS-terminatie | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | Reverse proxy met TLS pass-through | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |

In de opgenomen vergelijking,Webship produceerde de hoogste directe en TLS-beëindigde mediaan voor elk gemeten protocol. De volledige matrix bevatNginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora en Bun op de [benchmarkpagina](/benchmarks).

Deze cijfers meten de capaciteit op de benchmark-host. Ze zijn geen belofte voor een willekeurig internetpad. Opslaglatentie, netwerkbandbreedte, round-trip-tijd, pakketverlies, TLS-beleid, gelijktijdigheid en het gedrag van de oorsprong bepalen nog steeds de werkelijke bezorgsnelheid.

Één binaire, drie transportstrategieën

Een grote respons heeft niet hetzelfde voordeel van hetzelfde beleid als een klein HTML-document.Webship houdt het gewone verzoekpad conservatief en bevordert alleen een bewezen bulkrespons.

HTTP/1.1: minder overgangen rond het bestand

Op Linux, Webship houdt de responskop en bestandspayload binnen één best-effort TCP-cork-interval. Zodra een grote TLS-respons in aanmerking komt voor het bulkpad, kan directe bestandslevering verplaatsen vanRustregistreert naar gecontroleerde eenduidige kernel TLS en gebruikt sendfile zonder de payload via een applicatiebuffer te kopiëren.

De verbinding begint nog steeds in userspace TLS. Kleine reacties blijven daar.Webship verzoekt om de kTLS-overgang pas nadat een responsbody van minstens 1 MiB heeft bewezen dat de verbinding bulkgegevens vervoert.

HTTP/2: batchen zonder de stroomregeling te onderbreken

HTTP/2 Multiplexing maakt ongecontroleerde buffering duur.Webship schrijft in batches terwijl de stroom- en verbindingsflow-control limieten behouden blijven. Voor streaming met hoge gelijktijdigheid kan een TLS-schrijfbuffer van 128 KiB twee DATA-frames van 64 KiB bevatten, terwijl het verzendbudget van de verbinding expliciet en begrensd blijft.

Een al-klaar upstream-lichaamframe kan worden voorgehaald zonder Hyper-framing, trailers, annulering, inspectie of terugdrukking te omzeilen. Dat vermindert een vermijdbare scheduler-ronde terwijl het protocolcontract intact blijft.

HTTP/3: QUIC-tempo in plaats van kTLS

HTTP/3 gebruikt nooit het TCP kTLS-pad.Webship past transportbewuste QUIC-tempering toe, begrensde datagram-packetisatie, DPLPMTUD, en per-reaktor timer-gestuurde microbatching. GrootHTTP/3 reacties en geaccepteerdWebTransport sessies kunnen BBR selecteren zonder het CUBIC-beleid te wijzigen dat door normaal verkeer wordt gebruikt.

De gefocusteHTTP/3 de stabiliteitskwalificatie gebruikte zeven geaccepteerde monsters. TLS-beëindigde streaming leverde een mediaan van 1.938,6 MiB/s met 2,12% variatiecoëfficiënt. TLS pass-through leverde 1.748,5 MiB/s met 1,65% variatiecoëfficiënt. Beide series hadden nul fouten in de lichaam-integriteit, client, protocol en pakketverlies.

Directe levering of reverse proxy?

Gebruik directe levering wanneer Webship beheert de uitgerolde bestandsstructuur. Het verwijdert de origin-hop en maakt het meest efficiënte pad voor statische bestanden mogelijk.

Een minimale multi-protocolsite ziet er zo uit:

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"

Gebruik reverse-proxy TLS-terminatie wanneerWebship moet routeren op pad, WAF- of API Shield-controles toepassen, limieten voor de inhoud afdwingen, doorgestuurde headers toevoegen of HTTP-velden observeren:

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

Instellentls_termination = false wanneer de oorsprong de toepassings-plaintext en actieve sessiesleutels moet behouden. Pass-through kan versleutelde HTTP-velden niet inspecteren. TCP pass-through leidt daarom via ClientHello SNI, terwijlHTTP/3 pass-through vereist één gedeelde UDP-bron.

Stel bulkstreaming expliciet af

Voor hoge gelijktijdigheidHTTP/2 TLS-streamingWebship documenteert deze procesgebonden instellingen:

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

Het bovenstaande verbindingsbudget biedt 128 KiB krediet voor 256 actieve streams. Beschouw het als een capaciteitsbeslissing, niet als een universele standaard. Meet geheugen, latentie en doorvoer met uw verwachte gelijktijdigheid voordat u het verhoogt.

Op Linux, laad de kernel TLS- en BBR-modules en sta deWebship serviceaccount om BBR te selecteren.Webship faalt vóór het binden wanneer de vereiste kernelcapaciteit niet beschikbaar is, zodat een implementatie het geoptimaliseerde pad niet stilzwijgend kan claimen terwijl het zonder draait. Andere besturingssystemen behouden de draagbareRustls en congestiebeheerspaden gedocumenteerd voor hun platform.

WebTransport is een andere streamingvorm

WebTransport combineert betrouwbare streams en onbetrouwbare datagrammen over een beveiligde sessie. Het gebruikt geen TCP kTLS.Webship's gebonden diagnostische eindpunt valideert oorsprongen en handhaaft sessie-, stream-, capsule-, datagram-, byte- en inactiviteitstijdlimieten.

In de 1.3.1 capaciteitsrun, directWebTransport bereikte 1.018,1 MiB/s voor betrouwbare streams en 1.038,9 MiB/s voor datagrammen. TLS pass-through bereikte respectievelijk 548,6 MiB/s en 629,7 MiB/s. Beide modi slaagden voor alle vijf de monsters met nul afgewezen monsters, nul verloren datagrammen en nul grote clientfouten.

Voorkeur geven aanHTTP/3 voor nieuwWebTransport klanten. De HTTP/2 pad bestaat voor compatibiliteit met de oudere verlopen-conceptinstellingen.

Wat te verifiëren voordat het productieverkeer start

  1. Test de exacte mediagrootten of artefactformaten die je zult leveren, niet alleen een klein synthetisch antwoord.
  2. Controleer de antwoordlengte en inhoudsdigest bij de client.
  3. Annulering van oefeningen, bereikverzoeken, trage lezers en origineel halfsluitend gedrag.
  4. Meet de doorlopende doorvoer samen met CPU, geheugen, socketfouten, retransmissies en taillaaglatentie.
  5. Valideer directe, TLS-beëindigde en pass-through modi afzonderlijk; ze hebben verschillende beveiligings- en routeringsgrenzen.
  6. Houd instrumentatie uitgeschakeld voor normaal productieverkeer en schakel vervolgens gebonden diagnostiek opzettelijk in bij onderzoek.
  7. Controleer opnieuw de Linux kTLS- en BBR-preflight na kernel-, container- of systemd-sandboxwijzigingen.

Streaming is snel wanneer het hele pad meewerkt.WebshipHet ontwerp van 's houdt de bulk-gegevensoptimalisaties protocoolspecifiek terwijl het één operationeel model en één correctheidsnorm behoudt.

Lees het volledige [Webship 1.3.1 documentatie](/docs/1.3.1), bekijk de [benchmarkmethodologie en concurrentiematrix](/benchmarks), of download een ondertekende build van [Downloads](/downloads).