Výkon streamování není záležitostí jen přehrávače videa. Softwarové artefakty, váhy modelů, zálohy, audio knihovny a velké exporty API všechny závisí na stejných základech: rychle přenášet data, zachovat přesný obsah, respektovat zpětný tlak a čistě zastavit, když se klient odpojí.
Webship považuje tyto požadavky za jeden dopravní problém napříč HTTP/1.1, HTTP/2, HTTP/3, přímým doručením souboru, reverzním proxy a WebTransport. Rychlá cesta je užitečná pouze tehdy, když zachovává rámcování, zrušení, záhlaví, kontrolu bezpečnosti a omezenou paměť.
Naměřená přenosová kapacita 100 MB
Webship 1.3.1 kapacita Debian byla měřena podle medianu přenosu užitečného zatížení s pevnou přípravou 100 MB. Každý přijatý vzorek vyžadoval přesně 99 943 778bajtovou odpověď a žádné chyby klienta, protokolu, proxy, vážných výpadků stránek a HTTP/3 ztráty paketů.
| Webship režim | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Přímé doručení souboru | 4,194,8 MiB/s | 3,574,3 MiB/s | 2,096,9 MiB/s | | Reverzní proxy s ukončením TLS | 3 585,7 MiB/s | 3 355,0 MiB/s | 1 938,6 MiB/s | | Reverzní proxy s TLS průchodem | 2 783,2 MiB/s | 2 135,0 MiB/s | 1 748,5 MiB/s |
V zaznamenaném srovnání dosáhl Webship nejvyššího přímého a TLS-ukončeného mediánu pro každý měřený protokol. Kompletní matice zahrnuje Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora a Bun na [stránce benchmarků](/benchmarks).
Tato čísla měří kapacitu na testovacím hostiteli. Nejsou slibem pro libovolnou internetovou cestu. Skutečnou rychlost doručení stále určují latence úložiště, šířka pásma sítě, doba zpáteční cesty, ztráta paketů, politika TLS, souběžnost a chování zdroje.
Jedna binárka, tři dopravní strategie
Velká odpověď nemá prospěch ze stejné politiky jako malý HTML dokument. Webship udržuje běžnou cestu požadavku konzervativní a podporuje pouze ověřenou hromadnou odpověď.
HTTP/1.1: méně přechodů kolem souboru
Na Linuxu Webship udržuje hlavičku odpovědi a souborový obsah uvnitř jednoho TCP intervalového bloku na základě nejlepší snahy. Jakmile velká TLS odpověď splní podmínky pro hromadnou cestu, přímé doručení souboru se může přesunout z Rustls záznamů do auditované jednosměrné kernel TLS a použít sendfile bez kopírování obsahu prostřednictvím aplikačního bufferu.
Spojení stále začíná v uživatelském prostoru TLS. Malé odpovědi tam zůstávají. Webship požaduje přechod na kTLS teprve poté, co tělo odpovědi o velikosti alespoň 1 MiB prokáže, že spojení přenáší hromadná data.
HTTP/2: dávkování bez přerušení řízení toku
HTTP/2 multiplexing způsobuje, že nekontrolované vyrovnávací paměti jsou nákladné. Webship shromažďuje zápisy do dávky a přitom zachovává limity řízení toku pro streamy a spojení. Pro streamování s vysokou souběžností může 128 KiB TLS zápisová vyrovnávací paměť pojmout dvě 64 KiB DATA rámce, zatímco zasílací rozpočet spojení zůstává explicitní a omezený.
Již připravený rámec nadřazeného těla lze načíst předem, aniž by bylo přeskočeno Hyper framing, přípony, zrušení, kontrola nebo zpětný tlak. To snižuje zbytečný cyklus plánovače při zachování integrity protokolového kontraktu.
HTTP/3: Řízení rychlosti QUIC místo kTLS
HTTP/3 nikdy nepoužívá cestu TCP kTLS. Webship aplikuje přenosově orientované řízení taktování QUIC, omezené paketizování datagramů, DPLPMTUD a mikro-batchování řízené časovačem na úrovni reaktoru. Velké HTTP/3 odpovědi a přijaté WebTransport relace mohou zvolit BBR, aniž by se měnila politika CUBIC používaná běžným provozem.
Zaměřená kvalifikace stability HTTP/3 použila sedm přijatých vzorků. Proudové přenosy ukončené TLS dodaly medián 1 938,6 MiB/s s koeficientem variability 2,12 %. Přenosy TLS pass-through dodaly 1 748,5 MiB/s s koeficientem variability 1,65 %. Obě řady měly nulové chyby integrity těla, klienta, protokolu a ztráty paketů.
Přímé doručení nebo reverzní proxy?
Použijte přímé doručení, když Webship vlastní nasazený souborový strom. Odstraní to původní skok a umožní nejefektivnější cestu statického souboru.
Minimální vícepřenosový web vypadá takto:
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"Použijte ukončení TLS na reverzním proxy, když Webship musí směrovat podle cesty, aplikovat kontroly WAF nebo API Shield, vynucovat limity těla, přidávat přeposílací hlavičky nebo sledovat HTTP pole:
[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"]Nastavte tls_termination = false, když původ musí zachovat aplikační nezabezpečený text a aktivní klíče relace. Přenos přes (pass-through) nemůže kontrolovat šifrovaná pole HTTP. TCP pass-through proto směruje podle ClientHello SNI, zatímco HTTP/3 pass-through vyžaduje jeden sdílený UDP původ.
Ladit hromadné streamování explicitně
Pro vysokou souběžnost přenosu TLS HTTP/2 dokumentuje Webship tato nastavení vázaná na proces:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Výše uvedený rozpočet připojení poskytuje 128 KiB kreditu pro 256 aktivních proudů. Považujte ho za rozhodnutí o kapacitě, nikoli za univerzální výchozí hodnotu. Před jeho zvýšením změřte paměť, latenci a propustnost při očekávané souběžnosti.
Na Linuxu načtěte jádrové moduly TLS a BBR a umožněte účtu služby Webship vybrat BBR. Webship selže před navázáním, pokud jeho požadovaná schopnost jádra není k dispozici, takže nasazení nemůže tiše uplatnit optimalizovanou cestu při jeho nepřítomnosti. Ostatní operační systémy zachovávají přenositelné cesty Rustls a řízení přeplnění, dokumentované pro jejich platformu.
WebTransport je jiný tvar streamování
WebTransport kombinuje spolehlivé toky a nespolehlivé datagramy přes zabezpečenou relaci. Nepoužívá TCP kTLS. Omezený diagnostický bod Webship ověřuje původ a vynucuje limity relace, toku, kapsle, datagramu, bajtu a nečinnosti.
Při testu kapacity 1.3.1 dosáhl přímý WebTransport 1 018,1 MiB/s pro spolehlivé toky a 1 038,9 MiB/s pro datagramy. Přenos TLS dosáhl 548,6 MiB/s a 629,7 MiB/s respektive. Oba režimy prošly všemi pěti vzorky s nulovým počtem odmítnutých vzorků, nulovým počtem ztracených datagramů a nulovým počtem vážných chyb klienta.
Preferujte HTTP/3 pro nové klienty WebTransport. Cesta HTTP/2 existuje pro kompatibilitu se staršími nastaveními expirovaných konceptů.
Co ověřit před provozem v produkci
- Otestujte přesné velikosti médií nebo artefaktů, které budete poskytovat, nejen malou syntetickou odpověď.
- Ověřte délku odpovědi a souhrn obsahu na klientovi.
- Zrušení cvičení, žádosti o rozsah, pomalí čtenáři a chování půluzavření zdroje.
- Měřte trvalý průchod spolu s CPU, pamětí, chybami zásuvky, opakovanými přenosy a konečnou latencí.
- Ověřte samostatně přímé, TLS ukončené a průchozí režimy; mají odlišné bezpečnostní a směrovací hranice.
- Pro běžný provozní provoz nechte instrumentaci vypnutou, pak záměrně povolte omezenou diagnostiku při vyšetřování.
- Znovu zkontrolujte Linux kTLS a BBR předběžné kontroly po změnách jádra, kontejneru nebo sandboxu systemd.
Streamování je rychlé, když celá cesta spolupracuje. Návrh Webship udržuje optimalizace pro velká data specifické pro daný protokol a zároveň zachovává jeden provozní model a jednu úroveň správnosti.
Přečtěte si kompletní [Webship 1.3.1 dokumentaci](/docs/1.3.1), prohlédněte si [metodiku benchmarku a matici konkurentů](/benchmarks) nebo si stáhněte podepsanou verzi z [Stahování](/downloads).