A streaming teljesítmény nemcsak a videolejátszók problémája. A szoftvertermékek, a modell súlyok, a biztonsági mentések, a hangkönyvtárak és a nagy API exportok mind ugyanazokon az alapelveken függenek: mozgasd gyorsan a bájtokat, őrizd meg a pontos adatcsomagot, tiszteld a vissznyomást, és állj meg tisztán, amikor egy kliens lecsatlakozik.
Webship ezeket a követelményeket egyetlen szállítási problémaként kezeli az HTTP/1.1, HTTP/2, HTTP/3, közvetlen fájlszállítás, fordított proxyzás és WebTransport között. A gyors út csak akkor hasznos, ha megőrzi a keretezést, a megszakítást, a lábjegyzeteket, a biztonsági ellenőrzést és a korlátozott memóriát.
Mért 100 MB streaming kapacitás
A Webship 1.3.1 Debian kapacitásmérés során a középértékű terhelési átvitelt egy rögzített 100 MB-os rögzítővel mérték. Minden elfogadott minta pontosan 99,943,778 byte méretű választestet igényelt, valamint nullát az ügyfél-, protokoll-, proxy-, főoldalhiba- és HTTP/3 csomagvesztési hibákból.
| Webship mód | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Közvetlen fájlátvitel | 4,194,8 MiB/s | 3,574,3 MiB/s | 2,096,9 MiB/s | | Reverz proxy TLS terminációval | 3,585,7 MiB/s | 3,355,0 MiB/s | 1,938,6 MiB/s | | Visszafordító proxy TLS átvitellel | 2 783,2 MiB/s | 2 135,0 MiB/s | 1 748,5 MiB/s |
A rögzített összehasonlításban a Webship adta a legmagasabb közvetlen és TLS-sel lezárt mediánt minden mért protokoll esetében. A teljes mátrix tartalmazza a Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora, és Bun elemeket a [benchmark oldalon](/benchmarks).
Ezek a számok a referencia gazdagépen mért kapacitást jelzik. Nem jelentenek ígéretet tetszőleges internetes útvonalra. A tárolási késleltetés, a hálózati sávszélesség, a köridő, a csomagvesztés, a TLS-szabályzat, a párhuzamosság és a forrás viselkedése továbbra is meghatározza a tényleges szállítási sebességet.
Egy bináris, három szállítási stratégia
Egy nagy válasz nem profitál ugyanabból a szabályzatból, mint egy kis HTML dokumentum. Webship megtartja a rendes kérési útvonalat konzervatívnak, és csak egy bizonyított tömeges választ támogat.
HTTP/1.1: kevesebb átmenet a fájl körül
Linuxon a Webship a válasz fejlécét és a fájl tartalmát egyetlen legjobb próbálkozás szerinti TCP dugó intervallumon belül tartja. Amint egy nagy TLS válasz megfelel a tömeges útvonal követelményeinek, a közvetlen fájlszolgáltatás átléphet a Rustls rekordokról a felügyelt egyirányú kernel TLS-re, és a sendfile használható anélkül, hogy a terhelést alkalmazás-pufferen keresztül másolnánk.
A kapcsolat továbbra is a felhasználói térbeli TLS-ben kezdődik. A kis válaszok ott maradnak. Webship csak akkor kéri a kTLS átmenetet, miután egy legalább 1 MiB méretű választörzs bizonyítja, hogy a kapcsolat tömeges adatot szállít.
HTTP/2: feldolgozás csomagolása a folyamatszabályozás megszakítása nélkül
HTTP/2 a multiplexelés miatt a kontrollálatlan pufferelés költséges. Webship kötegesíti az írásokat, miközben megtartja a stream és a kapcsolat áramlásvezérlési korlátait. Nagy párhuzamosságú streaming esetén egy 128 KiB-os TLS írási puffer két 64 KiB-os DATA keretet tud tárolni, miközben a kapcsolat küldési költségvetése explicit és korlátos marad.
Egy már kész upstream vázszerkezet előre betölthető anélkül, hogy megkerülnénk a Hyper keretezést, a zárójelek, a visszavonás, az ellenőrzés vagy a vissznyomás kezelését. Ez csökkenti egy elkerülhető ütemezői kört, miközben a protokollszerződés érvényben marad.
HTTP/3: QUIC ütemezés kTLS helyett
HTTP/3 soha nem használja a TCP kTLS útvonalat. Webship alkalmazza a szállítástudatos QUIC ütemezést, korlátozott datagram csomagolást, DPLPMTUD-t és reakciós időzítő vezérelt mikrocsomagolást. Nagy HTTP/3 válaszok és elfogadott WebTransport munkamenetek választhatják a BBR-t anélkül, hogy megváltoztatnák a rendes forgalom által használt CUBIC szabályt.
A fókuszált HTTP/3 stabilitási minősítés hét elfogadott mintát használt. A TLS-lel lezárt streamelés középértéke 1 938,6 MiB/s volt, 2,12%-os szóráskoefficiens mellett. A TLS átmenő (pass-through) értéke 1 748,5 MiB/s volt 1,65%-os szóráskoefficiens mellett. Mindkét sorozat esetében nulla volt a testintegritási, kliens-, protokoll- és csomagvesztési hiba.
Közvetlen szállítás vagy fordított proxy?
Használjon közvetlen kézbesítést, amikor a Webship birtokolja a telepített fájlrendszert. Ez eltávolítja az eredeti lépést, és lehetővé teszi a leghatékonyabb statikus fájl útvonalat.
Egy minimális többprotokollos oldal így néz ki:
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"Használjon reverse-proxy TLS lezárást, amikor Webship-nak útvonal szerint kell irányítania, WAF vagy API Shield ellenőrzéseket kell alkalmaznia, érvényesítenie kell a testméret korlátozásokat, továbbító fejléceket kell hozzáadnia, vagy figyelnie kell a HTTP mezőket:
[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"]Állítsa be a tls_termination = false értéket, amikor az eredetnek meg kell őriznie az alkalmazás egyszerű szövegű és aktív munkamenetkulcsait. A pass-through nem tudja ellenőrizni a titkosított HTTP mezőket. A TCP pass-through ezért a ClientHello SNI alapján irányít, míg a HTTP/3 pass-through egy közös UDP eredetet igényel.
Hangolás tömeges streameléshez kifejezetten
A magas egyidejűségű HTTP/2 TLS folyamtovábbításhoz, a Webship dokumentálja ezeket a folyamathez kötött beállításokat:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"A fenti kapcsolat-költségvetés 128 KiB kreditet biztosít 256 aktív adatfolyamhoz. Kezelje ezt kapacitási döntésként, ne univerzális alapértelmezésként. Mérje a memóriát, a késleltetést és az átviteli teljesítményt a várható párhuzamosság mellett, mielőtt növelné azt.
Linuxon töltse be a kernel TLS és BBR modulokat, és engedélyezze a Webship szolgáltatásfióknak a BBR kiválasztását. A Webship kötés előtt meghiúsul, ha a szükséges kernel képesség nem érhető el, így egy telepítés nem igényelheti csendben az optimalizált útvonalat anélkül, hogy futna. Más operációs rendszerek megőrzik a hordozható Rustls és torlódásvezérlési útvonalakat, amelyeket a platformjukhoz dokumentáltak.
WebTransport egy másik streamelési alak
WebTransport megbízható adatfolyamokat és megbízhatatlan datagramokat kombinál egy biztonságos munkamenet során. Nem használ TCP kTLS-t. Webship korlátos diagnosztikai végpontja érvényesíti az eredetet, és betartatja a munkameneti, adatfolyam-, kapszula-, datagram-, bájt- és tétlenidő-korlátokat.
Az 1.3.1 kapacitásfutás során a közvetlen WebTransport 1 018,1 MiB/s sebességet ért el megbízható streamekhez és 1 038,9 MiB/s sebességet datagramokhoz. A TLS átjárás 548,6 MiB/s, illetve 629,7 MiB/s sebességet ért el. Mindkét mód mind az öt mintát meghaladta nullát visszautasított mintával, nullát elveszett datagrammal és nullát ügyfél főhibával.
Az új WebTransport ügyfelek esetében részesítsük előnyben a HTTP/3-t. A HTTP/2 útvonal a régebbi lejárt-tervezet beállításokkal való kompatibilitás érdekében létezik.
Mit ellenőrizzünk a termelési forgalom előtt
- Tesztelje a pontos média- vagy tárgyméreteket, amelyeket szolgáltatni fog, ne csak egy kicsi, szintetikus választ.
- Ellenőrizze a válasz hosszát és a tartalomellenőrzőt az ügyfélnél.
- Gyakorlat törlése, tartománykérelmek, lassú olvasók és az eredet félig zárt viselkedése.
- Mérje a folyamatos áteresztőképességet együtt a CPU, memória, foglalati hibák, újraküldések és farok-latencia mellett.
- Érvényesítse külön a közvetlen, TLS-sel lezárt és átmenő üzemmódokat; ezeknek eltérő biztonsági és útválasztási határai vannak.
- Tartsd kikapcsolva az instrumentációt a normál éles forgalomhoz, majd engedélyezd a korlátozott diagnosztikát szándékosan, amikor vizsgálódsz.
- Ellenőrizze újra a Linux kTLS és BBR előzetes ellenőrzését a kernel, a konténer vagy a systemd homokozó változtatásai után.
A streamelés gyors, amikor az egész útvonal együttműködik. Webship terve a tömeges adatoptimalizálásokat protokoll-specifikusan tartja, miközben megőrzi az egy működési modellt és az egy helyességi szintet.
Olvassa el a teljes [Webship 1.3.1 dokumentációt](/docs/1.3.1), tekintse át a [benchmark módszertant és versenytársi mátrixot](/benchmarks), vagy töltse le az aláírt verziót a [Letöltések](/downloads) menüből.