Zakończenie TLS czy Przekazywanie? Wybór właściwej granicy Webship reverse-proxy

Wybór między zakończeniem TLS a przekazywaniem TLS nie jest kosmetyczną opcją w ustawieniach proxy. Decyduje on, gdzie kończy się szyfrowanie, który system posiada klucze sesji, czy Webship może analizować HTTP oraz która warstwa musi wprowadzać zabezpieczenia aplikacji.

Webship domyślnie działa w trybie pass-through. To utrzymuje aplikację w postaci niezaszyfrowanej i aktywne klucze sesji na źródle. Włącz terminację tylko wtedy, gdy brzeg musi rozumieć i reagować na żądanie HTTP.

Decyzja w jednym zdaniu

Używaj przekazywania TLS (TLS pass-through), gdy źródło musi posiadać granicę TLS. Używaj zakończenia TLS (TLS termination), gdy Webship musi kierować, chronić, przekształcać, buforować lub obserwować ruch HTTP.

Żaden z trybów nie jest uniwersalnie bezpieczniejszy. Tryb przekazywania redukuje ilość wrażliwych materiałów przetwarzanych przez brzeg, ale usuwa kontrolki bezpieczeństwa HTTP na brzegu. Zakończenie dodaje punkt egzekwowania, który można sprawdzić, ale sprawia, że Webship staje się częścią zaufanej granicy TLS.

| Obawa | Zakończenie TLS | Przekazywanie TLS | | --- | --- | --- | | Punkt końcowy TLS | Webship | Źródło | | Aplikacja w postaci zwykłego tekstu na Webship | Tak | Nie | | Aktywne klucze sesji downstream na Webship | Tak | Nie | | Trasa według ścieżki HTTP lub metody | Tak | Nie | | WAF, API Shield i limity ciała w Webship | Tak | Nie | | Pamięć podręczna proxy, przepisania i nagłówki przesyłania | Tak | Nie | | Wejście trasowania TCP | Autorytet HTTP i polityka tras | ClientHello SNI | | HTTP/3 routowanie | Dane żądania HTTP | Jedno wspólne źródło UDP | | Odpowiedzialność źródła | TLS HTTP lub osobno skonfigurowany upstream | Pełny TLS, ALPN i stos HTTP |

Ważne pytanie brzmi zatem nie „Który przełącznik jest szybszy?”, lecz „Który komponent musi mieć możliwość widzenia i kontrolowania żądania?”

Jakie zakończenie daje Webship

Dzięki tls_termination = true, Webship kończy obsługę TLS po stronie serwera i wprowadza odszyfrowane żądanie do swojego potoku HTTP reverse-proxy. Umożliwia to następujące funkcje:

• trasowanie świadome ścieżki, hosta i metody;
• Inspekcja WAF i ochrony API;
• limity ciała żądania i limity czasu polityki;
• buforowanie proxy i unieważnianie bezpieczne dla generacji;
• zarządzanie nagłówkami przekazywania i polami dziennika dostępu HTTP;
• obsługa zapytań z uwzględnieniem ciała, ponawianie w bezpiecznych sytuacjach oraz polityka przełącznika awaryjnego;
• tłumaczenie protokołu między połączeniami skierowanymi do klienta a połączeniami w górę strumienia.

Ten tryb zmienia również odpowiedzialność za bezpieczeństwo. Host Webship musi chronić prywatny klucz certyfikatu, klucze sesji, odszyfrowane dane żądań i odpowiedzi, wyniki obserwowalności oraz wszelkie przechowywane w pamięci reprezentacje. Jeśli następny przeskok musi pozostać zaszyfrowany, skonfiguruj osobno typowany TLS dla upstream; w przeciwnym razie upstream HTTP jest w postaci niezaszyfrowanej.

Zakończenie jest prawą granicą, gdy Webship ma działać jako brzeg świadomy aplikacji, a nie tylko jako zaszyfrowany przekaźnik transportowy.

Co zachowuje przejście

Z tls_termination = false — domyślnie — Webship przesyła zaszyfrowany ruch TLS lub QUIC bez odszyfrowywania żądania lub odpowiedzi HTTP. Dane tekstowe aplikacji i aktywne klucze sesji pozostają w źródle.

Ta mniejsza granica zaufania jest cenna, gdy certyfikaty muszą pozostać w warstwie aplikacji, polityka zgodności zabrania dekryptowania na krawędzi lub tożsamość TLS specyficzna dla źródła musi dotrzeć do klienta niezmieniona. Usuwa ona również analizę HTTP i pracę nad polityką ze ścieżki przekaźnika.

Komisja jest ścisła: Webship nie może sprawdzać tego, czego nie może odszyfrować. Nie może stosować reguł HTTP WAF, kierować według ścieżki, przepisywać nagłówków, egzekwować polityki API świadomej ciała ani wypełniać dzienników dostępu do pól HTTP. Źródło musi samodzielnie zapewnić wszystkie te kontrole.

Przepustowość nie oznacza więc „zakończenia z mniejszą liczbą funkcji.” To inna architektura z innym właścicielem bezpieczeństwa.

Ograniczenia specyficzne dla protokołu mają znaczenie

Dla HTTP/1.1 TLS i HTTP/2 TLS, Webship analizuje ClientHello tylko na tyle, aby wybrać skonfigurowany docelowy TCP za pomocą SNI. Każda domena przekazywana wymaga uniwersalnej trasy path_prefix = "/", ponieważ rzeczywista ścieżka żądania pozostaje zaszyfrowana. Klient bez SNI jest akceptowany tylko wtedy, gdy konfiguracja zawiera jedną domenę.

Pochodzenie musi negocjować ALPN klienta i wspierać wybrany protokół. Webship nie może przekształcić klienta HTTP/2 w pochodzenie HTTP/1.1, podczas gdy sesja TLS przechodzi bez zmian.

HTTP/3 używa QUIC przez UDP i ma ciasniejsze granice. Przekazywanie nie może bezpiecznie kierować po zaszyfrowanym adresie HTTP, więc każda skonfigurowana trasa HTTP/3 musi rozwiązywać się do tego samego pochodzenia IP-socket UDP. Webship odrzuca gniazda Unix oraz wiele pochodzeń HTTP/3 podczas walidacji konfiguracji, zamiast cicho kierować w sposób niejednoznaczny.

Tekst jawny HTTP/1.1 i h2c nie są dotknięte przez reverse_proxy.tls_termination. To ustawienie kontroluje tylko downstream HTTP/1.1 TLS, HTTP/2 TLS i HTTP/3 TLS.

Zmierzona pojemność żądań

Webship 1.3.1 test wydajnościowy Debiana mierzył dwie zaszyfrowane tryby reverse-proxy osobno. Każda akceptowana próbka wymagała zerowych błędów HTTP, socket, protokołu, proxy, poważnych błędów strony oraz HTTP/3 utraty pakietów.

| Tryb reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Zakończenie TLS | 123 344 RPS | 124 957 RPS | 131 529 RPS | | Przekazywanie TLS | 203 950 RPS | 266 845 RPS | 167 010 RPS |

Przepustowość o małej odpowiedzi wymaga od aplikacji mniejszej ilości pracy: przesyła zaszyfrowane dane transportowe zamiast kończyć TLS, analizować HTTP, oceniać politykę i tworzyć nowy strumień TLS do odbiorcy. Wyższe wskaźniki żądań przepustowości odzwierciedlają to węższe zadanie.

Te wiersze nie reprezentują identycznych zestawów funkcji i nie powinny być używane do stwierdzenia, że jedna architektura bezpieczeństwa jest uniwersalnie lepsza. Terminacja płaci za możliwości świadome HTTP, których świadome przekazywanie celowo nie może zapewnić.

Masowe przesyłanie strumieniowe zmienia wynik

Ten sam benchmark używał dokładnej odpowiedzi o rozmiarze 99 943 778 bajtów dla strumieniowej macierzy 100 MB. Tutaj zakończenie TLS wygenerowało wyższą medianę przepustowości ładunku dla wszystkich trzech protokołów:

| Tryb reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Zakończenie TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Przekazywanie TLS | 2 783,2 MiB/s | 2 135,0 MiB/s | 1 748,5 MiB/s |

Dlaczego kierunek się zmienia? W trybie terminacji, punkt odniesienia benchmarku wysyła nieszyfrowany HTTP do Webship, a Webship zarządza zoptymalizowaną końcową ścieżką zbiorczą downstream. Duże odpowiedzi HTTP/1.1 i HTTP/2 mogą korzystać z adaptacyjnego Linux kTLS i ograniczonego buforowania specyficznego dla transportu. HTTP/3 używa pacingu QUIC, DPLPMTUD i grupowania na poziomie reaktora zamiast kTLS.

W trybie pass-through, źródło posiada TLS dla odbiorców końcowych, a Webship przesyła powstały zaszyfrowany strumień lub pakiety QUIC. To zachowuje granicę TLS źródła, ale nie można użyć ścieżki masowej odpowiedzi HTTP świadomej przez Webship.

Siedmioprzypadkowa kwalifikacja HTTP/3 sprawdzała również stabilność. Zakończone strumieniowanie osiągnęło medianę 1 938,6 MiB/s z współczynnikiem zmienności 2,12%; przekazywanie przez pass-through osiągnęło 1 748,5 MiB/s z współczynnikiem zmienności 1,65%. Oba dostarczyły dokładnie to samo ciało bez żadnych błędów klienta, protokołu i utraty pakietów.

Skonfiguruj przekazywanie celowo

Minimalna konfiguracja pass-through utrzymuje tożsamość TLS w gotowości, aby operator mógł włączyć terminację później bez zmiany ścieżek certyfikatów:

[reverse_proxy]
enabled = true
tls_termination = false

[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 = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

Sceniczne świadectwo Webship jest zweryfikowane, ale nie jest używane przez aktywne sesje przejściowe. Źródło na 10.0.0.20:443 musi zakończyć TLS i obsługiwać protokół negocjowany przez klienta.

Włącz zakończenie, gdy edge potrzebuje HTTP

Dla krawędzi świadomej aplikacji włącz zakończenie i prześlij wynikowy ruch HTTP do wybranego źródła:

[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 = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

Ta konfiguracja może kierować i analizować HTTP. Dodaj TLS upstream, gdy sieć między Webship a źródłem nie jest już zaufana ani odizolowana.

Przełącz tryby bez ponownego uruchamiania Webship

Webship może zmienić tls_termination poprzez ponowne wczytanie pliku konfiguracyjnego lub przez narzędzie webship.reverse_proxy.apply_config MCP sprawdzające wersję. Odczytaj bieżący obiekt i wersję za pomocą webship.reverse_proxy.get_config, zmień tylko zamierzone pole w całym zwróconym obiekcie i prześlij je z odpowiadającym expected_version_id.

Nowe połączenia TCP używają nowego trybu. Klienci HTTP/3 ponownie łączą się z wymienionym transportem UDP. Zmiany ścieżki certyfikatu i klucza pozostają powiązane z procesem i wymagają restartu, więc przed przełączeniem na tryb na żywo należy przygotować prawidłową tożsamość zakończenia.

Sprawdzanie wersji zapobiega nadpisaniu równoczesnej zmiany konfiguracji przez jednego operatora. Odrzucona aktualizacja nie zmienia aktywnej konfiguracji w czasie rzeczywistym ani zapisanej konfiguracji.

Praktyczna lista kontrolna doboru

Wybierz opcję pass-through, gdy wszystkie z poniższych są prawdziwe:

1. Punkt początkowy musi zachować granicę certyfikatu i klucze sesji.
2. Routing TCP na poziomie SNI — lub jeden wspólny HTTP/3 pochodzenie UDP — jest wystarczający.
3. Źródło zapewnia niezbędny WAF, autoryzację, rejestrowanie, limity dotyczące treści oraz kontrolę nadużyć.
4. Nie jest wymagana pamięć podręczna brzegowa, przepisywanie ścieżek, polityka nagłówków przekazywania ani tłumaczenie protokołu HTTP.

Wybierz zakończenie, gdy którekolwiek z tych jest wymagane w Webship:

1. Trasa według hosta, ścieżki lub metody.
2. Sprawdzaj żądania przy użyciu WAF lub API Shield.
3. Wymuszaj limity ciała, limity czasu HTTP lub uwierzytelnianie na krawędzi.
4. Pamiętaj odpowiedzi w pamięci podręcznej lub przepisuj nagłówki HTTP.
5. Tłumacz między protokołami HTTP downstream i upstream.
6. Obserwuj pola HTTP na granicy proxy.

Niezależnie od wybranego trybu, przetestuj SNI, ALPN, tożsamość certyfikatu, anulowanie przez klienta, częściowe zamknięcie po stronie upstream oraz dokładną integralność odpowiedzi. Mierz osobno pojemność żądań i przepustowość strumieniową: najszybszy tryb dla małej odpowiedzi niekoniecznie jest najszybszym trybem dla ciała o rozmiarze 100 MB.

Webship ustawia przekazywanie jako domyślne, ponieważ serwer proxy nie powinien cicho rozszerzać swojej granicy zaufania. Zakończenie pozostaje aktywnym, wyraźnym wyborem operacyjnym, gdy zachowanie krawędzi świadome HTTP jest warte tej odpowiedzialności.

Przeczytaj pełną [dokumentację reverse-proxy](/docs/1.3.1), porównaj akceptowaną [macierz benchmarkową](/benchmarks) lub pobierz Webship z [Pobrania](/downloads).

Źródła i metoda treści

Wartości wydajności są akceptowanymi medianami z zunifikowanego testu wydajności Debiana 1.3.1 Webship z dnia 11 września 2026 r.; jego kryteria akceptacji wymagają zerowej liczby błędów klienta, HTTP, socket, protokołu, proxy, błędu głównej strony oraz HTTP/3 utraty pakietów.