Streaming-Leistung ist nicht nur ein Anliegen von Video-Playern. Software-Artefakte, Modellgewichte, Backups, Audio-Bibliotheken und große API-Exporte hängen alle von denselben Grundlagen ab: Bytes schnell übertragen, die exakte Nutzlast bewahren, Rückstau respektieren und sauber stoppen, wenn ein Client die Verbindung trennt.
Webship behandelt diese Anforderungen als ein Transportproblem über HTTP/1.1, HTTP/2, HTTP/3, direkte Dateizustellung, Reverse-Proxy und WebTransport. Der schnelle Pfad ist nur dann nützlich, wenn er Framing, Abbruch, Trailers, Sicherheitsüberprüfung und beschränkten Speicher beibehält.
Gemessene 100 MB Streaming-Kapazität
Die Webship 1.3.1 Debian-Kapazitätsausführung maß den mittleren Payload-Durchsatz mit einem festen 100-MB-Setup. Jede akzeptierte Probe erforderte den exakt 99.943.778-Byte-Antwortkörper und null Client-, Protokoll-, Proxy-, Major-Page-Fault- und HTTP/3-Paketverluste.
| Webship Modus | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Direkte Dateilieferung | 4.194,8 MiB/s | 3.574,3 MiB/s | 2.096,9 MiB/s | | Reverse-Proxy mit TLS-Termination | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | Reverse-Proxy mit TLS-Pass-Through | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |
In der aufgezeichneten Vergleichsanalyse erzielte Webship den höchsten direkten und TLS-terminierten Median für jedes gemessene Protokoll. Die vollständige Matrix umfasst Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora und Bun auf der [Benchmark-Seite](/benchmarks).
Diese Zahlen messen die Kapazität auf dem Benchmark-Host. Sie sind kein Versprechen für einen beliebigen Internetpfad. Speicherlatenz, Netzwerkbandbreite, Round-Trip-Zeit, Paketverlust, TLS-Richtlinie, Gleichzeitigkeit und Verhalten der Quelle bestimmen weiterhin die tatsächliche Liefergeschwindigkeit.
Eine Binärdatei, drei Transportstrategien
Eine große Antwort profitiert nicht von derselben Richtlinie wie ein kleines HTML-Dokument. Webship hält den gewöhnlichen Anfragepfad konservativ und fördert nur eine bewährte Massenantwort.
HTTP/1.1: weniger Übergänge rund um die Datei
Unter Linux hält Webship den Response-Header und die Datei-Nutzlast innerhalb eines Best-Effort-TCP-Cork-Intervalls. Sobald eine große TLS-Antwort für den Bulk-Pfad qualifiziert, kann die direkte Dateilieferung von Rustls-Aufzeichnungen zu geprüften unidirektionalen Kernel-TLS wechseln und sendfile verwenden, ohne die Nutzlast durch einen Anwendungs-Puffer zu kopieren.
Die Verbindung beginnt weiterhin im Userspace-TLS. Kleine Antworten bleiben dort. Webship fordert die kTLS-Übergabe erst an, nachdem ein Antwortkörper von mindestens 1 MiB bewiesen hat, dass die Verbindung Massendaten überträgt.
HTTP/2: Stapelverarbeitung ohne Unterbrechung der Flusskontrolle
HTTP/2 Multiplexing macht unkontrolliertes Puffern teuer. Webship bündelt Schreibvorgänge, während die Flusskontrollgrenzen für Stream und Verbindung beibehalten werden. Für Streams mit hoher Parallelität kann ein 128 KiB TLS-Schreibpuffer zwei 64 KiB DATA-Frames aufnehmen, während das Verbindungs-Sendebudget weiterhin explizit und begrenzt bleibt.
Ein bereits fertiger Upstream-Rahmen kann vorab geladen werden, ohne Hyper-Framing, Trailer, Stornierung, Inspektion oder Rückstau zu umgehen. Das reduziert eine vermeidbare Scheduler-Runde, während der Protokollvertrag intakt bleibt.
HTTP/3: QUIC-Taktung statt kTLS
HTTP/3 verwendet niemals den TCP kTLS-Pfad. Webship wendet transportbewusstes QUIC-Pacing, begrenzte Datagrammpaketierung, DPLPMTUD und reaktorbasierte, timer-gesteuerte Mikro-Batch-Verarbeitung an. Große HTTP/3-Antworten und akzeptierte WebTransport-Sitzungen können BBR auswählen, ohne die CUBIC-Richtlinie zu ändern, die vom normalen Datenverkehr verwendet wird.
Die fokussierte HTTP/3-Stabilitätsqualifikation verwendete sieben akzeptierte Proben. TLS-terminiertes Streaming lieferte einen Median von 1.938,6 MiB/s mit einem Variationskoeffizienten von 2,12 %. TLS-Pass-Through lieferte 1.748,5 MiB/s mit einem Variationskoeffizienten von 1,65 %. Beide Serien hatten null Fehler in Bezug auf Körperintegrität, Client, Protokoll und Paketverlust.
Direkte Lieferung oder Reverse-Proxy?
Verwenden Sie die direkte Lieferung, wenn Webship den bereitgestellten Dateibaum besitzt. Es entfernt die Origin-Hürde und ermöglicht den effizientesten Pfad für statische Dateien.
Eine minimale Multi-Protokoll-Website sieht so aus:
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"Verwenden Sie Reverse-Proxy-TLS-Terminierung, wenn Webship nach Pfad weiterleiten, WAF- oder API-Shield-Prüfungen anwenden, Begrenzungen für den Body erzwingen, Weiterleitungsheader hinzufügen oder HTTP-Felder überwachen muss:
[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"]Setzen Sie tls_termination = false, wenn die Ursprungsquelle den Anwendungsklartext und die aktiven Sitzungsschlüssel beibehalten muss. Pass-Through kann verschlüsselte HTTP-Felder nicht prüfen. TCP-Pass-Through wird daher anhand des ClientHello SNI geleitet, während HTTP/3 Pass-Through eine einzelne gemeinsame UDP-Ursprungsquelle erfordert.
Streame große Datenmengen gezielt
Für hochkonkurrierende HTTP/2 TLS-Streaming dokumentiert Webship diese prozessgebundenen Einstellungen:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Das obige Verbindungsbudget stellt 128 KiB Guthaben für 256 aktive Streams bereit. Betrachten Sie es als eine Kapazitätsentscheidung, nicht als universellen Standard. Messen Sie Speicher, Latenz und Durchsatz bei Ihrer erwarteten Parallelität, bevor Sie es erhöhen.
Unter Linux laden Sie die Kernel-TLS- und BBR-Module und erlauben Sie dem Dienstkonto Webship, BBR auszuwählen. Webship schlägt fehl, bevor es gebunden wird, wenn die erforderliche Kernel-Fähigkeit nicht verfügbar ist, sodass eine Bereitstellung den optimierten Pfad nicht stillschweigend beanspruchen kann, während sie ohne ihn läuft. Andere Betriebssysteme behalten die portablen Rustls- und Staukontrollpfade bei, die für ihre Plattform dokumentiert sind.
WebTransport ist eine andere Streaming-Form
WebTransport kombiniert zuverlässige Streams und unzuverlässige Datagramme über eine sichere Sitzung. Es verwendet kein TCP kTLS. Webship's begrenzter Diagnose-Endpunkt überprüft Ursprünge und erzwingt Sitzungs-, Stream-, Kapsel-, Datagramm-, Byte- und Leerlaufzeitgrenzen.
Im Kapazitätslauf 1.3.1 erreichte direct WebTransport 1.018,1 MiB/s für zuverlässige Streams und 1.038,9 MiB/s für Datagramme. TLS-Durchleitung erreichte jeweils 548,6 MiB/s und 629,7 MiB/s. Beide Modi bestanden alle fünf Proben mit null abgelehnten Proben, null verlorenen Datagrammen und null schwerwiegenden Client-Fehlern.
Bevorzugen Sie HTTP/3 für neue WebTransport-Kunden. Der HTTP/2-Pfad existiert zur Kompatibilität mit den älteren Einstellungen für abgelaufene Entwürfe.
Was vor dem Produktionsverkehr überprüft werden sollte
- Testen Sie die genauen Medien- oder Artefaktgrößen, die Sie bereitstellen werden, nicht nur eine kleine synthetische Antwort.
- Überprüfen Sie die Antwortlänge und den Inhaltsdigest beim Client.
- Übungsabsage, Bereichsanfragen, langsame Leser und halb-offenes Ursprungsverhalten.
- Messen Sie den nachhaltigen Durchsatz zusammen mit CPU, Speicher, Socket-Fehlern, erneuten Übertragungen und Endlatenz.
- Validieren Sie direkte, TLS-terminated und Pass-Through-Modi separat; sie haben unterschiedliche Sicherheits- und Routinggrenzen.
- Schalten Sie die Instrumentierung für normalen Produktionsverkehr aus und aktivieren Sie dann gezielt begrenzte Diagnosen bei Untersuchungen.
- Überprüfen Sie den Linux kTLS- und BBR-Preflight erneut nach Änderungen am Kernel, Container oder systemd-Sandbox.
Streaming ist schnell, wenn der gesamte Pfad zusammenarbeitet. Webship's Design hält die Optimierungen für Massendaten protokollspezifisch, während ein einheitliches Betriebsmodell und eine einheitliche Korrektheitsnorm beibehalten werden.
Lesen Sie die vollständige [Webship 1.3.1 Dokumentation](/docs/1.3.1), prüfen Sie die [Benchmark-Methodik und Wettbewerbermatrix](/benchmarks) oder laden Sie eine signierte Version von [Downloads](/downloads) herunter.