Streamingprestanda är inte bara en fråga för videospelare. Mjukvaruartiklar, modellvikter, säkerhetskopior, ljudbibliotek och stora API-exporter är alla beroende av samma grundprinciper: flytta byte snabbt, bevara den exakta nyttolasten, respektera backpressure och stanna rent när en klient kopplar från.
Webship behandlar dessa krav som ett transportproblem över HTTP/1.1, HTTP/2, HTTP/3, direkt filöverföring, omvänd proxying och WebTransport. Den snabba vägen är användbar endast när den bevarar inramning, avbokning, trailers, säkerhetskontroll och begränsat minne.
Mätt 100 MB strömningskapacitet
Webship 1.3.1 Debians kapacitetskörning mätte medianen för nyttolastgenomströmning med en fast 100 MB-fixtur. Varje accepterat prov krävde exakt 99 943 778-byte svarskropp och noll klient-, protokoll-, proxy-, större sidfels- och HTTP/3 paketförlustfel.
| Webship läge | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Direkt filöverföring | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | Omvänd proxy med TLS-avslutning | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Omvänd proxy med TLS-passering | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |
I den inspelade jämförelsen producerade Webship det högsta direkta och TLS-terminerade medianvärdet för varje uppmätt protokoll. Den fullständiga matrisen inkluderar Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora och Bun på [benchmark-sidan](/benchmarks).
Dessa siffror mäter kapacitet på referensvärddatorn. De är inget löfte för en godtycklig internetväg. Lagringslatens, nätverksbandbredd, rundresetid, paketförlust, TLS-policy, samtidighet och ursprungsbeteende avgör fortfarande den faktiska leveranshastigheten.
En binär, tre transportstrategier
Ett stort svar drar inte nytta av samma policy som ett litet HTML-dokument. Webship håller den vanliga begäran vägen försiktig och främjar endast ett beprövat bulk-svar.
HTTP/1.1: färre övergångar runt filen
På Linux håller Webship svarshuvudet och filinnehållet inom ett enda best-effort TCP cork-intervall. När ett stort TLS-svar kvalificerar sig för bulkvägen kan direkt fildistribuering flyttas från Rustls-poster till granskad envägs kernel TLS och använda sendfile utan att kopiera innehållet genom en applikationsbuffert.
Anslutningen börjar fortfarande i användarutrymmet TLS. Små svar förblir där. Webship begär kTLS-övergång först efter att ett svarskropp på minst 1 MiB visar att anslutningen bär bulkdata.
HTTP/2: batchbearbetning utan att bryta flödeskontrollen
HTTP/2 multiplexing gör okontrollerad buffring dyrt. Webship samlar skrivningar i batchar samtidigt som ström- och anslutningsflödeskontrollgränser behålls. För strömmande data med hög samtidighet kan en 128 KiB TLS-skrivbuffert hålla två 64 KiB DATA-ramar, medan anslutningens sändbudget förblir explicit och begränsad.
En redan färdig upstream-ram kan förhämtas utan att kringgå Hyper-framning, trailers, avbokning, inspektion eller baktryck. Det minskar ett undvikbart schemaläggarrunda samtidigt som protokollkontraktet hålls intakt.
HTTP/3: QUIC-rymning istället för kTLS
HTTP/3 använder aldrig TCP kTLS-vägen. Webship tillämpar transportmedveten QUIC-pacing, begränsad datagrampaketering, DPLPMTUD och mikrobatchning styrd av per-reaktortimer. Stora HTTP/3-svar och accepterade WebTransport-sessioner kan välja BBR utan att ändra CUBIC-policyn som används av vanlig trafik.
Den fokuserade HTTP/3 stabilitetskvalificeringen använde sju godkända prover. TLS-avslutad streaming levererade en median på 1 938,6 MiB/s med 2,12 % variationskoefficient. TLS pass-through levererade 1 748,5 MiB/s med 1,65 % variationskoefficient. Båda serierna hade noll fel gällande kroppsintegritet, klient, protokoll och paketförlust.
Direktleverans eller omvänd proxy?
Använd direkt leverans när Webship äger den distribuerade filstrukturen. Det tar bort ursprungshoppet och möjliggör den mest effektiva sökvägen för statiska filer.
En minimal webbplats med flera protokoll ser ut så här:
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"Använd TLS-terminering via omvänd proxy när Webship måste routas efter sökväg, tillämpa WAF- eller API Shield-kontroller, upprätthålla kroppslimits, lägga till vidarebefordringshuvuden eller observera HTTP-fält:
[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"]Ange tls_termination = false när ursprunget måste behålla applikationens klartext och aktiva sessionsnycklar. Pass-through kan inte inspektera krypterade HTTP-fält. TCP pass-through styrs därför via ClientHello SNI, medan HTTP/3 pass-through kräver ett delat UDP-ursprung.
Ställ in bulkströmning explicit
För högkonkurrens HTTP/2 TLS-strömning dokumenterar Webship dessa processbundna inställningar:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Anslutningsbudgeten ovan ger 128 KiB kredit för 256 aktiva strömmar. Behandla det som ett kapacitetsbeslut, inte som en universell standard. Mät minne, latens och genomströmning med den förväntade samtidigheten innan du ökar det.
På Linux, ladda kärnans TLS- och BBR-moduler och tillåt Webship tjänstekonto att välja BBR. Webship misslyckas innan bindning när dess nödvändiga kärnkapacitet inte är tillgänglig, så en distribution kan inte tyst påstå den optimerade vägen medan den körs utan den. Andra operativsystem behåller de portabla Rustls- och överbelastningskontrollvägar som dokumenterats för deras plattform.
WebTransport är en annan strömningsform
WebTransport kombinerar pålitliga strömmar och opålitliga datagram över en säker session. Det använder inte TCP kTLS. Webships begränsade diagnostikendpunkt validerar ursprung och upprätthåller gränser för session, ström, kapsel, datagram, byte och inaktiv tid.
I kapacitetskörningen 1.3.1 nådde direkt WebTransport 1 018,1 MiB/s för pålitliga strömmar och 1 038,9 MiB/s för datagram. TLS pass-through nådde 548,6 MiB/s respektive 629,7 MiB/s. Båda lägena klarade alla fem prover med noll avvisade prover, noll förlorade datagram och noll stora klientfel.
Föredra HTTP/3 för nya WebTransport klienter. HTTP/2-vägen finns för kompatibilitet med de äldre inställningarna för utgångna utkast.
Vad man ska verifiera innan produktions trafik
- Testa de exakta medie- eller artefaktstorlekarna du kommer att leverera, inte bara ett litet syntetiskt svar.
- Verifiera svarslängden och innehållsdigesten hos klienten.
- Avbokning av övning, räckviddsförfrågningar, långsamma läsare och ursprungs halv-stängningsbeteende.
- Mät kontinuerlig genomströmning tillsammans med CPU, minne, socketfel, omsändningar och toppfördröjning.
- Validera direkt-, TLS-terminerad- och pass-through-lägen separat; de har olika säkerhets- och routningsgränser.
- Håll instrumentering avstängd för normal produktionstrafik, och aktivera sedan begränsad diagnostik medvetet när du undersöker.
- Kontrollera om Linux kTLS och BBR förhandskontroll på nytt efter ändringar i kärnan, containern eller systemd-sandboxen.
Streaming är snabbt när hela vägen samarbetar. Webships design håller stordataoptimeringar protokollspecifika samtidigt som den bevarar en operativ modell och en korrekthetsnivå.
Läs den kompletta [Webship 1.3.1-dokumentationen](/docs/1.3.1), granska [benchmarkmetodiken och konkurrentmatrisen](/benchmarks), eller ladda ner en signerad version från [Nedladdningar](/downloads).