Webship teknik

TLS-avslutning eller pass-through? Att välja rätt Webship reverse-proxy-gränssnitt

TLS-terminering låser upp routning, cachning och HTTP-säkerhetsinspektion; pass-through behåller klartext och sessionsnycklar vid ursprunget. Den här guiden förklarar avvägningarna, uppmätta prestanda och live Webship-konfigurationen.

Publicerad 10 september 2026

Att välja mellan TLS-terminering och TLS-pass-through är inte en kosmetisk proxyinställning. Det avgör var kryptering slutar, vilket system som håller sessionsnycklar, om Webship kan inspektera HTTP, och vilket lager som måste upprätthålla applikationssäkerhet.

Webship standardiseras till pass-through. Det håller applikationsklartext och aktiva sessionsnycklar vid ursprunget. Aktivera terminering endast när kanten måste förstå och agera på HTTP-förfrågan.

Beslutet i en mening

Använd TLS pass-through när ursprunget måste äga TLS-gränsen. Använd TLS termination när Webship måste dirigera, skydda, transformera, cachelagra eller observera HTTP-trafik.

Ingen av lägena är allmänt mer säker. Pass-through minskar den känsliga information som hanteras av kanten, men tar bort kantens HTTP-säkerhetskontroller. Termination lägger till en inspekterbar genomdrivningspunkt, men gör Webship till en del av den betrodda TLS-gränsen.

| Bekymmer | TLS-avslut | TLS-genomgång | | --- | --- | --- | | TLS-slutpunkt | Webship | Ursprung | | Ansökningsklartext på Webship | Ja | Nej | | Aktiva nedströms sessionsnycklar vid Webship | Ja | Nej | | Rutt efter HTTP-sökväg eller metod | Ja | Nej | | WAF, API Shield och kroppslimits på Webship | Ja | Nej | | Proxicache, omskrivningar och vidarebefordringshuvuden | Ja | Nej | | TCP-routingingång | HTTP-auktoritet och ruttpolicy | ClientHello SNI | | HTTP/3 routning | HTTP-förfrågningsdata | En delad UDP-ursprung | | Ursprungssvarighet | HTTP eller separat konfigurerad upstream TLS | Full TLS, ALPN och HTTP-stack |

Den viktiga frågan är alltså inte "Vilken strömbrytare är snabbare?" Den är "Vilken komponent måste tillåtas att se och kontrollera förfrågan?"

Vilket avslut ger Webship

Med tls_termination = true slutför Webship nedströms TLS och skickar den dekrypterade förfrågan till dess HTTP-reverse-proxy-pipeline. Det gör följande funktioner möjliga:

sökväg-, värd- och metodmedveten routing;
WAF- och API-skyddsinspektion;
gränser för begäran-kropp och policytidsgränser;
proxy-cachelagring och generationssäker ogiltigförklaring;
hantering av vidarebefordringshuvuden och HTTP-åtkomstloggfält;
kroppsmedveten QUERY-hantering, omförsök där det är säkert, och kretsbrytarpolicy;
protokollöversättning mellan klientanslutningarna och upstream-anslutningarna.

Detta läge ändrar också säkerhetsansvaret. Värden Webship måste skydda certifikatets privata nyckel, sessionsnycklar, dekrypterade förfrågnings- och svarsdata, observabilitetsutdata och alla cachade representationer. Om nästa steg måste förbli krypterat, konfigurera typad upstream TLS separat; annars är HTTP-upstream klartext.

Avslutning är den högra gränsen när Webship förväntas bete sig som en applikationsmedveten kant, inte endast som en krypterad transportrelä.

Vad som passeras genom bevaras

Med tls_termination = false—standard—Webship vidarebefordrar krypterad TLS- eller QUIC-trafik utan att dekryptera HTTP-förfrågan eller svaret. Applikationsklartext och aktiva sessionsnycklar stannar vid ursprunget.

Den mindre förtroendegränsen är värdefull när certifikat måste förbli på applikationsnivån, när efterlevnadspolicy förbjuder kantavkryptering, eller när en ursprungsspecifik TLS-identitet måste nå klienten oförändrad. Den tar också bort HTTP-parsing och policysarbete från relävägen.

Avvägningen är strikt: Webship kan inte inspektera vad det inte kan dekryptera. Det kan inte tillämpa HTTP WAF-regler, styra efter sökväg, skriva om headers, upprätthålla kropp-medveten API-policy eller fylla i HTTP-fältåtkomstloggar. Ursprungssystemet måste tillhandahålla alla dessa kontroller själv.

Pass-through är därför inte ”avslut med färre funktioner.” Det är en annan arkitektur med en annan säkerhetsägare.

Protokolls-specifika gränser spelar roll

För HTTP/1.1 TLS och HTTP/2 TLS inspekterar Webship ClientHello endast tillräckligt för att välja den konfigurerade TCP-destinationen via SNI. Varje pass-through-domän behöver en catch-all path_prefix = "/"-rutt eftersom den faktiska begäransvägen förblir krypterad. En klient utan SNI accepteras endast när konfigurationen har en domän.

Ursprunget måste förhandla om klientens ALPN och stödja det valda protokollet. Webship kan inte konvertera en HTTP/2-klient till ett HTTP/1.1-ursprung medan TLS-sessionen passerar oförändrad.

HTTP/3 använder QUIC över UDP och har en striktare gräns. Pass-through kan inte säkert dirigera efter krypterad HTTP-auktoritet, så varje konfigurerad HTTP/3-rutt måste lösas till samma IP-socket UDP-ursprung. Webship avvisar Unix-sockets och flera HTTP/3-pass-through-ursprung under konfigurationsvalidering istället för att tyst dirigera tvetydigt.

Klartext HTTP/1.1 och h2c påverkas inte av reverse_proxy.tls_termination. Inställningen styr endast nedströms HTTP/1.1 TLS, HTTP/2 TLS och HTTP/3 TLS.

Mätt begäranskapacitet

Webship 1.3.1 Debian kapacitetsbenchmark mätte de två krypterade omvända proxylägena separat. Varje accepterat prov krävde noll HTTP-, socket-, protokoll-, proxy-, stora-sidfel- och HTTP/3 paketförlustfel.

| Omvänd proxy-läge | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS-avslut | 123 344 RPS | 124 957 RPS | 131 529 RPS | | TLS pass-through | 203 950 RPS | 266 845 RPS | 167 010 RPS |

Små-svar pass-through har mindre applikationsarbete att utföra: det vidarebefordrar krypterad transportdata istället för att avsluta TLS, analysera HTTP, utvärdera policy och skapa en ny nedströms TLS-ström. De högre pass-through-förfrågningshastigheterna återspeglar det smalare arbetet.

Dessa rader representerar inte identiska funktionsuppsättningar, och de bör inte användas för att påstå att en säkerhetsarkitektur är universellt bättre. Termination betalar för HTTP-medvetna funktioner som pass-through medvetet inte kan tillhandahålla.

Massströmning ändrar resultatet

Samma benchmark använde en exakt 99 943 778-byte svarskropp för den 100 MB stora strömningsmatrisen. Här gav TLS-terminering högre median genomströmning av nyttolast för alla tre protokollen:

| Omvänd proxy-läge | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS-avslut | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | TLS pass-through | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

Varför ändras riktningen? I terminationsläge skickar benchmark-ursprunget klartext-HTTP till Webship, och Webship äger den optimerade nedströms massvägen. Stora HTTP/1.1 och HTTP/2-svar kan använda adaptiv Linux kTLS och begränsad transport-specifik buffring. HTTP/3 använder QUIC-pacing, DPLPMTUD och per-reaktor-batching istället för kTLS.

I pass-through-läge äger ursprunget downstream TLS och Webship vidarebefordrar den resulterande krypterade strömmen eller QUIC-paketen. Det bevarar ursprungets TLS-gräns, men det kan inte använda Webships HTTP-medvetna bulk-svarsväg.

Den sjuproviga HTTP/3-kvalificeringen kontrollerade också stabilitet. Avslutad strömning nådde en median på 1 938,6 MiB/s med 2,12% variationskoefficient; pass-through nådde 1 748,5 MiB/s med 1,65% variationskoefficient. Båda levererade exakt kropp utan några klient-, protokoll- eller paketförlustfel.

Konfigurera pass-through medvetet

En minimal pass-through-konfiguration håller TLS-identiteten i beredskap så att en operatör kan aktivera terminering senare utan att ändra certifikatvägar:

[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

Det iscensatta Webship-certifikatet är validerat men används inte av aktiva pass-through-sessioner. Ursprungspunkten på 10.0.0.20:443 måste avsluta TLS och stödja den klientförhandlade protokollen.

Aktivera avslutning när kanten behöver HTTP

För en applikationsmedveten edge, aktivera terminering och skicka den resulterande HTTP-trafiken till den valda ursprungsservern:

[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

Denna konfiguration kan routa och inspektera HTTP. Lägg till upstream TLS när nätverket mellan Webship och ursprunget inte redan är betrott eller isolerat.

Byt lägen utan att starta om Webship

Webship kan ändra tls_termination genom att ladda om en konfigurationsfil eller använda det versionskontrollerade webship.reverse_proxy.apply_config MCP-verktyget. Läs det aktuella objektet och versionen med webship.reverse_proxy.get_config, ändra endast det avsedda fältet i det fullständiga returnerade objektet och skicka det med den matchande expected_version_id.

Nya TCP-anslutningar använder det nya läget. HTTP/3 klienter återansluter till den ersatta UDP-transporten. Ändringar av certifikat- och nyckelvägar förblir processbundna och kräver en omstart, så håll en giltig avslutsidentitet förberedd före en direkt växling.

Versionskontroll förhindrar att en operatör skriver över en samtidig konfigurationsändring. En avvisad uppdatering lämnar den aktiva körningen och den sparade konfigurationen oförändrad.

En praktisk urvalslista

Välj pass-through när alla dessa är sanna:

Ursprunget måste behålla certifikatgränsen och sessionsnycklarna.
SNI-nivå TCP-routing—eller en delad HTTP/3 UDP-ursprung—är tillräcklig.
Ursprunget tillhandahåller nödvändig WAF, auktorisering, loggning, kroppsliga gränser och missbrukscontroller.
Ingen kantcache, omdirigering av sökväg, vidarebefordringshuvudpolicy eller HTTP-protokollöversättning krävs.

Välj avslut när någon av dessa krävs vid Webship:

Rutt efter värd, väg eller metod.
Inspektera förfrågningar med WAF eller API-sköld.
Tvinga fram kroppsliga gränser, HTTP-tidsgränser eller kantautentisering.
Cachea svar eller skriv om HTTP-rubriker.
Översätt mellan nedströms- och uppströms-HTTP-protokoll.
Observera HTTP-fält vid proxygränsen.

Oavsett vilken läge du väljer, testa SNI, ALPN, certifikatidentitet, klientavbokning, uppström halvstängning och exakt svarsintegritet. Mät förfrågningskapacitet och strömmande genomströmning separat: den snabbaste läget för ett litet svar är inte nödvändigtvis det snabbaste läget för en kropp på 100 MB.

Webship gör pass-through till standard eftersom en proxy inte bör tyst utvidga sin förtroendegräns. Termination förblir ett aktivt, uttryckligt operativt val när HTTP-medvetet edge-beteende är värt det ansvaret.

Läs hela [reverse-proxy-dokumentationen](/docs/1.3.1), jämför den accepterade [benchmark-matrisen](/benchmarks), eller ladda ner Webship från [Downloads](/downloads).

Källor och innehållsmetod

Prestandavärdena är accepterade medianer från Webship 1.3.1 enhetliga Debian kapacitetsbenchmark daterad den 11 september 2026; dess accepteringsgrindar kräver noll klient-, HTTP-, socket-, protokoll-, proxy-, huvudsidfel- och HTTP/3 paketförloringsfel.