Performanța streamingului nu este doar o problemă a player-ului video. Artefactele software, greutățile modelelor, copiile de siguranță, bibliotecile audio și exporturile mari de API depind toate de aceleași fundamentale: mută rapid biții, păstrează exact payload-ul, respectă contrapresiunea și oprește curat când un client se deconectează.
Webship tratează aceste cerințe ca o singură problemă de transport prin HTTP/1.1, HTTP/2, HTTP/3, livrare directă de fișiere, proxy invers și WebTransport. Calea rapidă este utilă doar atunci când păstrează încadratura, anularea, indexurile finale, inspectarea securității și memoria limitată.
Capacitate de streaming măsurată la 100 MB
Capacitatea Webship 1.3.1 Debian a fost măsurată prin debitul mediu al încărcăturii utile cu o fixare de 100 MB. Fiecare eșantion acceptat a necesitat corpul răspunsului exact de 99.943.778 de octeți și zero erori ale clientului, protocolului, proxy-ului, paginii majore de eroare și HTTP/3 pierderi de pachete.
| modul Webship | TLS HTTP/1.1 | TLS HTTP/2 | TLS HTTP/3 | | --- | ---: | ---: | ---: | | Livrare directă a fișierelor | 4.194,8 MiB/s | 3.574,3 MiB/s | 2.096,9 MiB/s | | Proxy invers cu terminare TLS | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | Proxy invers cu transmitere TLS | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |
În comparația înregistrată, Webship a produs cea mai mare mediană directă și terminată TLS pentru fiecare protocol măsurat. Matricea completă include Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora și Bun pe [pagina de referință](/benchmarks).
Aceste numere măsoară capacitatea pe gazda de referință. Ele nu reprezintă o promisiune pentru o cale arbitrară pe internet. Latența stocării, lățimea de bandă a rețelei, timpul de deplasare dus-întors, pierderea pachetelor, politica TLS, concurența și comportamentul sursei determină în continuare viteza reală de livrare.
Un binar, trei strategii de transport
Un răspuns mare nu beneficiază de aceeași politică ca un document HTML mic. Webship păstrează calea obișnuită a cererii conservatoare și promovează doar un răspuns în masă dovedit.
HTTP/1.1: mai puține tranziții în jurul fișierului
Pe Linux, Webship păstrează antetul răspunsului și conținutul fișierului într-un singur interval TCP cork pe principiul celei mai bune încercări. Odată ce un răspuns TLS mare se califică pentru calea de volum, livrarea directă a fișierului poate trece de la înregistrările Rustls la TLS kernel unidirecțional auditat și poate folosi sendfile fără a copia conținutul printr-un buffer aplicație.
Conexiunea începe încă în TLS la nivel de utilizator. Răspunsurile mici rămân acolo. Webship solicită tranziția către kTLS doar după ce un corp de răspuns de cel puțin 1 MiB dovedește că conexiunea transportă date în vrac.
HTTP/2: procesare în loturi fără a întrerupe controlul fluxului
Multiplexarea HTTP/2 face ca tamponarea necontrolată să fie costisitoare. Webship grupează scrierile păstrând în același timp limitele de control al fluxului pentru stream și conexiune. Pentru streaming de mare concurență, un tampon de scriere TLS de 128 KiB poate reține două cadre DATA de 64 KiB, în timp ce bugetul de trimitere al conexiunii rămâne explicit și limitat.
Un cadru de corp de nivel superior deja pregătit poate fi preluat în avans fără a ocoli Hyper framing, trailerele, anularea, inspectarea sau presiunea inversă. Aceasta reduce o rundă de planificator evitabilă, menținând în același timp intact contractul protocolului.
HTTP/3: Ritmarea QUIC în loc de kTLS
HTTP/3 nu folosește niciodată calea TCP kTLS. Webship aplică reglarea traficului QUIC conștientă de transport, packetizare limitată a datagramelor, DPLPMTUD și microcolectare bazată pe temporizator per reactor. Răspunsurile mari HTTP/3 și sesiunile acceptate WebTransport pot selecta BBR fără a schimba politica CUBIC utilizată de traficul obișnuit.
Calificarea de stabilitate HTTP/3 concentrată a folosit șapte probe acceptate. Streaming-ul terminat TLS a livrat un median de 1.938,6 MiB/s cu un coeficient de variație de 2,12%. Traversarea TLS a livrat 1.748,5 MiB/s cu un coeficient de variație de 1,65%. Ambele serii nu au avut erori de integritate a corpului, client, protocol sau pierdere de pachete.
Livrare directă sau proxy invers?
Utilizați livrarea directă când Webship deține arborele de fișiere implementat. Aceasta elimină saltul de origine și permite cea mai eficientă cale a fișierelor statice.
Un site multi-protocolar minimal arată astfel:
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"Utilizați terminarea TLS prin reverse-proxy atunci când Webship trebuie să fie rutat după cale, să se aplice verificări WAF sau API Shield, să se impună limite de conținut, să se adauge antete de redirecționare sau să se observe câmpurile HTTP:
[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"]Setați tls_termination = false atunci când originea trebuie să păstreze textul simplu al aplicației și cheile de sesiune active. Pass-through nu poate inspecta câmpurile HTTP criptate. Pass-through TCP se trasează prin urmare după ClientHello SNI, în timp ce pass-through HTTP/3 necesită o origine UDP partajată.
Ajustează transmiterea în masă în mod explicit
Pentru streaming TLS cu concurență ridicată HTTP/2, Webship documentează aceste setări legate de 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"Bugetul de conexiune de mai sus oferă 128 KiB de credit pentru 256 de fluxuri active. Tratați-l ca pe o decizie de capacitate, nu ca pe o valoare implicită universală. Măsurați memoria, latența și debitul cu concurența așteptată înainte de a-l crește.
Pe Linux, încarcă modulele kernel TLS și BBR și permite contului de serviciu Webship să selecteze BBR. Webship eșuează înainte de legare atunci când capacitatea kernel necesară nu este disponibilă, astfel încât o implementare nu poate revendica în mod silențios calea optimizată în timp ce rulează fără aceasta. Alte sisteme de operare păstrează căile portabile Rustls și de control al congestiei documentate pentru platforma lor.
WebTransport este o formă de streaming diferită
WebTransport combină fluxuri fiabile și datagrame nefiabile peste o sesiune securizată. Nu utilizează TCP kTLS. Endpoint-ul de diagnostic limitat al Webship validează originile și impune limite pentru sesiune, flux, capsulă, datagramă, octet și timp de inactivitate.
În testul de capacitate 1.3.1, WebTransport direct a atins 1.018,1 MiB/s pentru fluxuri fiabile și 1.038,9 MiB/s pentru datagrame. Trecerea prin TLS a atins 548,6 MiB/s și 629,7 MiB/s respectiv. Ambele moduri au trecut toate cele cinci probe fără nicio probă respinsă, fără datagrame pierdute și fără faulturi majore ale clientului.
Prefer HTTP/3 pentru noii clienți WebTransport. Calea HTTP/2 există pentru compatibilitate cu setările mai vechi de schiță expirată.
Ce să verificați înainte de traficul de producție
- Testează dimensiunile exacte ale mediilor sau artefactelor pe care le vei servi, nu doar un răspuns sintetic mic.
- Verificați lungimea răspunsului și rezumatul conținutului la client.
- Anularea exercițiului, cererile de rază, cititorii lenți și comportamentul de semi-închidere a originii.
- Măsurați debitul susținut împreună cu CPU, memoria, erorile de soclu, retransmiterile și latența finală.
- Validați separat modurile directe, terminate TLS și prin trecere; ele au limite diferite de securitate și rutare.
- Mențineți instrumentarea dezactivată pentru traficul normal de producție, apoi activați în mod deliberat diagnosticațile limitate atunci când investigați.
- Verificați din nou preflight-ul Linux kTLS și BBR după modificările kernelului, containerului sau sandbox-ului systemd.
Streaming-ul este rapid atunci când întregul traseu cooperează. Designul lui Webship păstrează optimizările pentru date voluminoase specifice protocolului, menținând în același timp un singur model operațional și un singur standard de corectitudine.
Citește documentația completă [Webship 1.3.1](/docs/1.3.1), inspectează [metodologia de benchmark și matricea competitorilor](/benchmarks), sau descarcă o versiune semnată de la [Descărcări](/downloads).