Wydajność przesyłania strumieniowego nie dotyczy jedynie odtwarzacza wideo. Artefakty oprogramowania, wagi modeli, kopie zapasowe, biblioteki audio i duże eksporty API wszystkie zależą od tych samych podstaw: szybko przesyłać bajty, zachować dokładną zawartość, respektować przeciążenie i kończyć czysto, gdy klient się rozłączy.
Webship traktuje te wymagania jako jeden problem transportowy obejmujący HTTP/1.1, HTTP/2, HTTP/3, bezpośrednią dostawę plików, odwrotne proxy oraz WebTransport. Szybka ścieżka jest użyteczna tylko wtedy, gdy zachowuje ramkowanie, anulowanie, nagłówki końcowe, kontrolę bezpieczeństwa i ograniczoną pamięć.
Zmierzona przepustowość strumieniowania 100 MB
Webship 1.3.1 zdolność uruchamiania Debiana mierzyła medianę przepustowości ładunku przy stałym obiekcie testowym 100 MB. Każda zaakceptowana próbka wymagała dokładnie 99 943 778-bajtowej treści odpowiedzi oraz zerowych błędów po stronie klienta, protokołu, proxy, poważnych błędów stron i HTTP/3 utraty pakietów.
| tryb Webship | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Bezpośrednia wysyłka plików | 4,194,8 MiB/s | 3,574,3 MiB/s | 2,096,9 MiB/s | | Proxy odwrotny z zakończeniem TLS | 3 585,7 MiB/s | 3 355,0 MiB/s | 1 938,6 MiB/s | | Reverse proxy z przekazywaniem TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |
W porównaniu na nagraniu, Webship uzyskał najwyższą medianę bezpośrednią i zakończoną w TLS dla każdego mierzonego protokołu. Pełna macierz obejmuje Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora i Bun na [stronie z benchmarkami](/benchmarks).
Te liczby mierzą wydajność na maszynie testowej. Nie są one obietnicą dotyczącą dowolnej ścieżki w internecie. Opóźnienie w magazynowaniu, przepustowość sieci, czas podróży w obie strony, utrata pakietów, polityka TLS, współbieżność i zachowanie źródła nadal decydują o rzeczywistej prędkości dostarczania.
Jedna binarka, trzy strategie transportu
Duża odpowiedź nie korzysta z tej samej polityki co mały dokument HTML. Webship utrzymuje zwykłą ścieżkę żądania w sposób ostrożny i promuje tylko sprawdzoną odpowiedź zbiorczą.
HTTP/1.1: mniej przejść wokół pliku
Na Linuksie, Webship przechowuje nagłówek odpowiedzi i dane pliku w jednym, starającym się najlepiej interwale korka TCP. Gdy duża odpowiedź TLS kwalifikuje się do ścieżki masowej, bezpośrednia dostawa pliku może przejść od rekordów Rustls do audytowanego jednokierunkowego jądrowego TLS i używać sendfile bez kopiowania danych przez bufor aplikacji.
Połączenie nadal zaczyna się w TLS w przestrzeni użytkownika. Małe odpowiedzi pozostają tam. Webship żąda przejścia na kTLS dopiero po tym, jak ciało odpowiedzi o wielkości co najmniej 1 MiB udowodni, że połączenie przenosi dane masowe.
HTTP/2: grupowanie bez przerywania kontroli przepływu
Multipleksowanie HTTP/2 sprawia, że niekontrolowane buforowanie jest kosztowne. Webship grupuje zapisy, zachowując jednocześnie limity kontroli przepływu dla strumienia i połączenia. Dla strumieniowania przy wysokiej współbieżności, bufor zapisu TLS o rozmiarze 128 KiB może pomieścić dwa 64 KiB ramki DATA, podczas gdy budżet wysyłki połączenia pozostaje jawny i ograniczony.
Gotowa rama korpusu z górnego poziomu może być wstępnie pobrana bez pomijania ramienia Hyper, nagłówków końcowych, anulowania, inspekcji ani przeciążenia wstecznego. To zmniejsza uniknioną rundę planisty, jednocześnie utrzymując nienaruszoną umowę protokołu.
HTTP/3: Harmonogramowanie QUIC zamiast kTLS
HTTP/3 nigdy nie używa ścieżki TCP kTLS. Webship stosuje transportowo-świadome sterowanie tempem QUIC, ograniczoną pakietyzację datagramów, DPLPMTUD oraz mikropartiowanie sterowane timerem dla każdego reactor-a. Duże odpowiedzi HTTP/3 i akceptowane sesje WebTransport mogą wybierać BBR bez zmiany polityki CUBIC stosowanej w zwykłym ruchu.
Skoncentrowana kwalifikacja stabilności HTTP/3 wykorzystała siedem zaakceptowanych próbek. Strumieniowanie zakończone TLS dostarczyło medianę 1 938,6 MiB/s przy współczynniku zmienności 2,12%. Przepuszczanie TLS dostarczyło 1 748,5 MiB/s przy współczynniku zmienności 1,65%. Obie serie nie miały błędów integralności danych, klienta, protokołu ani utraty pakietów.
Bezpośrednia dostawa czy odwrotny serwer proxy?
Używaj bezpośredniej dostawy, gdy Webship posiada wdrożone drzewo plików. Usuwa to pośredni etap pochodzenia i umożliwia najwydajniejszą ścieżkę plików statycznych.
Minimalna wieloprotokołowa strona wygląda tak:
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"Używaj zakończenia TLS przez reverse-proxy, gdy Webship musi kierować ruchem według ścieżki, stosować kontrole WAF lub API Shield, egzekwować limity treści, dodawać nagłówki przekazywania lub obserwować pola 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"]Ustaw tls_termination = false, gdy źródło musi zachować niezaszyfrowaną aplikację i aktywne klucze sesji. Przejście przez nie może nie sprawdzać zaszyfrowanych pól HTTP. Przejście TCP dlatego trasuje według ClientHello SNI, podczas gdy przejście HTTP/3 wymaga jednego współdzielonego pochodzenia UDP.
Dostosuj przesyłanie strumieniowe masowo explicite
Dla wysokiej współbieżności strumieniowania TLS HTTP/2, Webship dokumentuje te ustawienia związane z procesem:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Powyższy budżet połączenia zapewnia 128 KiB kredytu dla 256 aktywnych strumieni. Traktuj go jako decyzję dotyczącą pojemności, a nie uniwersalną domyślną wartość. Zmierz pamięć, opóźnienie i przepustowość przy oczekiwanej współbieżności, zanim go zwiększysz.
Na Linuksie załaduj moduły jądra TLS i BBR i pozwól kontu serwisowemu Webship wybrać BBR. Webship niepowodzenie występuje przed powiązaniem, gdy wymagana zdolność jądra jest niedostępna, więc wdrożenie nie może cicho korzystać ze ścieżki zoptymalizowanej podczas działania bez niej. Inne systemy operacyjne zachowują przenośne ścieżki Rustls i kontroli przeciążenia udokumentowane dla swojej platformy.
WebTransport to inny kształt transmisji strumieniowej
WebTransport łączy niezawodne strumienie i zawodowe datagramy w ramach bezpiecznej sesji. Nie używa TCP kTLS. Ograniczony punkt diagnostyczny Webship weryfikuje pochodzenie i egzekwuje limity sesji, strumienia, kapsułki, datagramu, bajtu i czasu bezczynności.
W teście wydajności 1.3.1, bezpośredni WebTransport osiągnął 1,018.1 MiB/s dla strumieni niezawodnych i 1,038.9 MiB/s dla datagramów. Przepuszczanie TLS osiągnęło odpowiednio 548.6 MiB/s i 629.7 MiB/s. Oba tryby przeszły wszystkie pięć próbek bez odrzuconych próbek, bez utraconych datagramów i bez poważnych błędów klienta.
Preferuj HTTP/3 dla nowych klientów WebTransport. Ścieżka HTTP/2 istnieje dla zgodności ze starszymi ustawieniami wygasłego szkicu.
Co zweryfikować przed ruchem produkcyjnym
- Przetestuj dokładne rozmiary mediów lub artefaktów, które będziesz serwować, a nie tylko małą syntetyczną odpowiedź.
- Zweryfikuj długość odpowiedzi i sumę kontrolną treści po stronie klienta.
- Anulowanie ćwiczeń, żądania zakresu, powolni czytelnicy i zachowanie półzamknięcia pochodzenia.
- Mierz ciągłą przepustowość wraz z użyciem procesora, pamięci, błędami gniazd, retransmisjami i opóźnieniem ogona.
- Zweryfikuj tryby bezpośredni, zakończony TLS i przejściowy osobno; mają one różne granice bezpieczeństwa i routingu.
- Wyłącz instrumentację dla normalnego ruchu produkcyjnego, a następnie włącz ograniczoną diagnostykę celowo podczas prowadzenia badań.
- Ponownie sprawdź wstępne testy Linux kTLS i BBR po zmianach w jądrze, kontenerze lub piaskownicy systemd.
Streaming jest szybki, gdy cała ścieżka współpracuje. Projekt Webship utrzymuje optymalizacje przesyłania dużych danych specyficzne dla protokołu, zachowując jednocześnie jeden model operacyjny i jeden standard poprawności.
Przeczytaj kompletną [Webship dokumentację 1.3.1](/docs/1.3.1), przeanalizuj [metodologię benchmarku i macierz konkurentów](/benchmarks), lub pobierz podpisaną wersję z [Pobierania](/downloads).