Le prestazioni dello streaming non riguardano solo i lettori video. Artefatti software, pesi dei modelli, backup, librerie audio ed esportazioni API di grandi dimensioni dipendono tutti dagli stessi fondamentali: spostare rapidamente i byte, preservare esattamente il payload, rispettare il backpressure e fermarsi pulitamente quando un client si disconnette.
Webship considera tali requisiti come un unico problema di trasporto su HTTP/1.1, HTTP/2, HTTP/3, consegna diretta dei file, proxy inverso e WebTransport. Il percorso veloce è utile solo quando preserva l’inquadramento, la cancellazione, i trailer, l’ispezione della sicurezza e la memoria limitata.
Capacità di streaming misurata di 100 MB
La capacità 1.3.1 Debian Webship è stata misurata come flusso di dati mediano del payload con un dispositivo fisso da 100 MB. Ogni campione accettato richiedeva esattamente un corpo della risposta di 99.943.778 byte e zero errori di client, protocollo, proxy, pagina principale, e HTTP/3 di perdita di pacchetti.
| modalità Webship | TLS HTTP/1.1 | TLS HTTP/2 | TLS HTTP/3 | | --- | ---: | ---: | ---: | | Consegna diretta dei file | 4.194,8 MiB/s | 3.574,3 MiB/s | 2.096,9 MiB/s | | Proxy inverso con terminazione TLS | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | Proxy inverso con pass-through TLS | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |
Nella comparazione registrata, Webship ha prodotto la mediana diretta e terminata TLS più alta per ogni protocollo misurato. La matrice completa include Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora e Bun sulla [pagina dei benchmark](/benchmarks).
Questi numeri misurano la capacità sull'host di riferimento. Non sono una promessa per un percorso internet arbitrario. La latenza dello storage, la larghezza di banda della rete, il tempo di andata e ritorno, la perdita di pacchetti, la politica TLS, la concorrenza e il comportamento dell'origine determinano ancora la velocità reale di consegna.
Un binario, tre strategie di trasporto
Una grande risposta non beneficia della stessa politica di un piccolo documento HTML. Webship mantiene il percorso di richiesta ordinario conservativo e promuove solo una risposta di massa comprovata.
HTTP/1.1: meno transizioni intorno al file
Su Linux, Webship mantiene l'intestazione della risposta e il payload del file all'interno di un singolo intervallo TCP cork a miglior sforzo. Una volta che una grande risposta TLS soddisfa i requisiti per il percorso bulk, la consegna diretta del file può passare dai record Rustls al TLS kernel monodirezionale controllato e utilizzare sendfile senza copiare il payload attraverso un buffer dell'applicazione.
La connessione inizia ancora nello TLS in spazio utente. Le risposte di piccole dimensioni rimangono lì. Webship richiede la transizione a kTLS solo dopo che un corpo di risposta di almeno 1 MiB dimostra che la connessione sta trasportando dati di grandi dimensioni.
HTTP/2: raggruppamento senza interrompere il controllo del flusso
HTTP/2 il multiplexing rende l'accodamento incontrollato costoso. Webship raggruppa le scritture mantenendo i limiti di flusso del flusso e della connessione. Per lo streaming ad alta concorrenza, un buffer di scrittura TLS da 128 KiB può contenere due frame DATA da 64 KiB, mentre il budget di invio della connessione rimane esplicito e limitato.
Un telaio del corpo a monte già pronto può essere precaricato senza bypassare l'Hyper framing, i trailer, la cancellazione, l'ispezione o il backpressure. Ciò riduce un ciclo di pianificatore evitabile mantenendo intatto il contratto del protocollo.
HTTP/3: pacing QUIC invece di kTLS
HTTP/3 non utilizza mai il percorso TCP kTLS. Webship applica il pacing QUIC consapevole del trasporto, la pacchettizzazione dei datagrammi limitata, DPLPMTUD e la microbatching guidata da timer per ciascun reactor. Le grandi risposte HTTP/3 e le sessioni WebTransport accettate possono selezionare BBR senza modificare la politica CUBIC utilizzata dal traffico ordinario.
La qualificazione di stabilità mirata HTTP/3 ha utilizzato sette campioni accettati. Lo streaming terminato TLS ha fornito una mediana di 1.938,6 MiB/s con un coefficiente di variazione del 2,12%. Il pass-through TLS ha fornito 1.748,5 MiB/s con un coefficiente di variazione dell'1,65%. Entrambe le serie non hanno registrato errori di integrità del corpo, client, protocollo o perdita di pacchetti.
Consegna diretta o proxy inverso?
Usa la consegna diretta quando Webship possiede l'albero dei file distribuiti. Rimuove il passaggio di origine e consente il percorso dei file statici più efficiente.
Un sito multi-protocollo minimo appare così:
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"Utilizzare la terminazione TLS del reverse-proxy quando Webship deve instradare per percorso, applicare controlli WAF o API Shield, imporre limiti sul corpo, aggiungere intestazioni di forwarding o osservare i campi 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"]Imposta tls_termination = false quando l'origine deve conservare il plaintext dell'applicazione e le chiavi di sessione attive. Il pass-through non può ispezionare i campi HTTP crittografati. Il pass-through TCP quindi instrada tramite ClientHello SNI, mentre il pass-through HTTP/3 richiede un'origine UDP condivisa.
Ottimizza lo streaming di massa esplicitamente
Per lo streaming TLS HTTP/2 ad alta concorrenza, Webship documenta queste impostazioni legate al processo:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Il budget di connessione sopra fornisce 128 KiB di credito per 256 stream attivi. Consideralo come una decisione sulla capacità, non come un default universale. Misura memoria, latenza e throughput con la concorrenza prevista prima di aumentarlo.
Su Linux, carica i moduli kernel TLS e BBR e consenti all'account di servizio Webship di selezionare BBR. Webship fallisce prima del binding quando la capacità kernel richiesta non è disponibile, quindi un deployment non può rivendicare silenziosamente il percorso ottimizzato mentre funziona senza di esso. Altri sistemi operativi mantengono i percorsi portatili Rustls e di controllo della congestione documentati per la loro piattaforma.
WebTransport è una forma di streaming diversa
WebTransport combina flussi affidabili e datagrammi non affidabili su una sessione sicura. Non utilizza TCP kTLS. Il punto finale diagnostico limitato di Webship convalida le origini e applica limiti di sessione, flusso, capsula, datagramma, byte e tempo di inattività.
Nella prova di capacità 1.3.1, il WebTransport diretto ha raggiunto 1.018,1 MiB/s per stream affidabili e 1.038,9 MiB/s per datagrammi. Il passaggio TLS ha raggiunto rispettivamente 548,6 MiB/s e 629,7 MiB/s. Entrambe le modalità hanno superato tutti e cinque i campioni con zero campioni rifiutati, zero datagrammi persi e zero errori gravi del client.
Preferisci HTTP/3 per i nuovi clienti WebTransport. Il percorso HTTP/2 esiste per compatibilità con le impostazioni di bozza scaduta più vecchie.
Cosa verificare prima del traffico di produzione
- Testa le dimensioni esatte dei media o degli artefatti che servirai, non solo una piccola risposta sintetica.
- Verificare la lunghezza della risposta e il digest del contenuto lato client.
- Cancellazione dell'esercizio, richieste di intervallo, lettori lenti e comportamento di chiusura parziale dell'origine.
- Misurare il throughput sostenuto insieme a CPU, memoria, errori di socket, ritrasmissioni e latenza finale.
- Valida separatamente le modalità diretta, terminata TLS e pass-through; hanno confini di sicurezza e instradamento diversi.
- Mantieni l'instradamento spento per il traffico di produzione normale, quindi abilita intenzionalmente la diagnostica limitata durante le indagini.
- Verifica nuovamente il preflight di Linux kTLS e BBR dopo modifiche al kernel, al container o al sandbox di systemd.
Lo streaming è veloce quando tutto il percorso coopera. Il design di Webship mantiene le ottimizzazioni per i dati voluminosi specifiche del protocollo, preservando al contempo un modello operativo e un livello di correttezza.
Leggi la documentazione completa [Webship 1.3.1](/docs/1.3.1), consulta la [metodologia di benchmark e la matrice dei concorrenti](/benchmarks), o scarica una build firmata da [Download](/downloads).