Alegerea între terminarea TLS și trecerea prin TLS nu este o setare cosmetică a proxy-ului. Aceasta decide unde se încheie criptarea, care sistem deține cheile de sesiune, dacă Webship poate inspecta HTTP și ce nivel trebuie să aplice securitatea aplicației.
Webship are implicit setat pe pass-through. Aceasta păstrează textul clar al aplicației și cheile de sesiune active la origine. Activează terminarea doar atunci când edge-ul trebuie să înțeleagă și să acționeze pe cererea HTTP.
Decizia într-o propoziție
Folosește TLS pass-through atunci când originea trebuie să dețină limita TLS. Folosește TLS termination atunci când Webship trebuie să ruteze, să protejeze, să transforme, să cache-uiască sau să observe traficul HTTP.
Niciun mod nu este universal mai sigur. Modul de trecere reduce cantitatea de materiale sensibile gestionate de margine, dar elimină controalele de securitate HTTP ale marginii. Terminarea adaugă un punct de aplicare inspectabil, dar face ca Webship să fie parte a limitei TLS de încredere.
| Îngrijorare | Terminarea TLS | Transmiterea TLS | | --- | --- | --- | | Punct terminal TLS | Webship | Origine | | Text simplu al aplicației la Webship | Da | Nu | | Chei de sesiune activă downstream la Webship | Da | Nu | | Ruta după calea HTTP sau metodă | Da | Nu | | WAF, Scut API și limite de corp la Webship | Da | Nu | | Cache proxy, rescrieri și redirecționare anteturi | Da | Nu | | Intrare rutare TCP | Autoritate și politică de rutare HTTP | ClientHello SNI | | HTTP/3 rutare | Date cerere HTTP | Un singur origin UDP partajat | | Responsabilitate origine | HTTP sau TLS upstream configurat separat | TLS complet, ALPN și stivă HTTP |
Întrebarea importantă nu este, prin urmare, „Care comutator este mai rapid?” Ci „Care componentă trebuie să fie lăsată să vadă și să controleze cererea?”
Ce terminare oferă Webship
Cu tls_termination = true, Webship finalizează TLS-ul downstream și introduce cererea decriptată în fluxul său de proxy invers HTTP. Aceasta face posibile următoarele funcționalități:
- rutare conștientă de cale, gazdă și metodă;
- Inspectarea WAF și a scutului API;
- limitele corpului cererii și timpii de expirare ai politicii;
- cache proxy și invalidare sigură pentru generare;
- gestionarea antetelor de redirecționare și câmpurile jurnalului de acces HTTP;
- gestionarea cererilor conștiente de corp, reîncercări acolo unde este sigur și politică de întrerupător de circuit;
- traducerea protocolului între conexiunile cu clientul și cele upstream.
Acest mod schimbă și responsabilitatea pentru securitate. Gazda Webship trebuie să protejeze cheia privată a certificatului, cheile de sesiune, datele cererii și răspunsului decriptate, ieșirea pentru observabilitate și orice reprezentare cache-uită. Dacă următorul hop trebuie să rămână criptat, configurează TLS-ul tipizat upstream separat; în caz contrar, HTTP-ul upstream este în text clar.
Terminarea este limita dreaptă atunci când Webship este așteptat să se comporte ca un edge conștient de aplicație, nu doar ca un releu de transport criptat.
Ce păstrează trecerea
Cu tls_termination = false—implicit—Webship transmite trafic TLS sau QUIC criptat fără a decripta cererea sau răspunsul HTTP. Textul clar al aplicației și cheile de sesiune active rămân la origine.
Acea limită de încredere mai mică este valoroasă atunci când certificatele trebuie să rămână pe nivelul aplicației, politica de conformitate interzice decriptarea la margine sau o identitate TLS specifică sursei trebuie să ajungă la client neschimbată. De asemenea, elimină analiza HTTP și munca de aplicare a politicii din calea de retransmisie.
Compromisul este strict: Webship nu poate inspecta ceea ce nu poate decripta. Nu poate aplica reguli HTTP WAF, nu poate direcționa după cale, nu poate rescrie anteturile, nu poate impune politici API conștiente de conținutul corpului sau nu poate completa jurnalele de acces pentru câmpurile HTTP. Originea trebuie să furnizeze singură toate aceste controale.
Prin urmare, pass-through nu înseamnă „terminare cu mai puține funcții.” Este o arhitectură diferită cu un proprietar de securitate diferit.
Limitele specifice protocolului contează
Pentru HTTP/1.1 TLS și HTTP/2 TLS, Webship inspectează ClientHello doar până la punctul necesar pentru a selecta destinația TCP configurată prin SNI. Fiecare domeniu de tip pass-through necesită o rută path_prefix = "/" catch-all deoarece calea reală a cererii rămâne criptată. Un client fără SNI este acceptat doar atunci când configurația are un singur domeniu.
Originea trebuie să negocieze ALPN-ul clientului și să suporte protocolul selectat. Webship nu poate transforma un client HTTP/2 într-o origine HTTP/1.1 în timp ce sesiunea TLS trece neschimbată.
HTTP/3 folosește QUIC peste UDP și are o limită mai strictă. Pass-through nu poate ruta în siguranță după autoritatea HTTP criptată, așa că fiecare rută configurată HTTP/3 trebuie să se rezolve către același origin UDP de tip IP-socket. Webship respinge socket-urile Unix și mai multe origini HTTP/3 pass-through în timpul validării configurației, în loc să ruteze ambiguu în mod tacit.
Cleartext HTTP/1.1 și h2c nu sunt afectate de reverse_proxy.tls_termination. Setarea controlează doar TLS-ul HTTP/1.1 downstream, TLS-ul HTTP/2 downstream și TLS-ul HTTP/3 downstream.
Capacitate de solicitare măsurată
Indicele de capacitate Webship 1.3.1 Debian a măsurat separat cele două moduri de proxy invers criptat. Fiecare eșantion acceptat a necesitat zero erori HTTP, socket, protocol, proxy, defecțiune majoră de pagină și pierderi de pachete HTTP/3.
| Mod reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminarea TLS | 123.344 RPS | 124.957 RPS | 131.529 RPS | | Trecere prin TLS | 203.950 RPS | 266.845 RPS | 167.010 RPS |
Transmiterea prin răspuns mic necesită mai puțină muncă de aplicație: transmite datele de transport criptate în loc să încheie TLS, să parseze HTTP, să evalueze politica și să producă un nou flux TLS în aval. Ratele mai mari de cereri în modul de transmitere reflectă această muncă mai restrânsă.
Aceste rânduri nu reprezintă seturi de caracteristici identice și nu ar trebui să fie utilizate pentru a afirma că o arhitectură de securitate este universal mai bună. Termination plătește pentru capabilitățile conștiente de HTTP pe care pass-through-ul intenționat nu le poate furniza.
Transmiterea în masă modifică rezultatul
Același benchmark a folosit un corp de răspuns exact de 99.943.778 de octeți pentru matricea de streaming de 100 MB. Aici, terminarea TLS a produs un debit mediu al încărcăturii utile mai mare pentru toate cele trei protocoale:
| Mod reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminarea TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | TLS passthrough | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |
De ce se schimbă direcția? În modul de terminare, originea de referință trimite HTTP în clar către Webship, iar Webship deține calea optimizată de transport în aval. Răspunsurile mari HTTP/1.1 și HTTP/2 pot folosi kTLS Linux adaptiv și bufferizare limitată specifică transportului. HTTP/3 folosește reglarea ritmului QUIC, DPLPMTUD și procesarea în lot pe reactor în loc de kTLS.
În modul de trecere, originea deține TLS-ul downstream și Webship retransmite fluxul criptat rezultat sau pachetele QUIC. Aceasta păstrează limita TLS a originii, dar nu poate folosi calea de răspuns în bloc conștientă de HTTP a Webship.
Calificarea HTTP/3 cu șapte probe a verificat, de asemenea, stabilitatea. Streamingul terminat a atins o medie de 1.938,6 MiB/s cu un coeficient de variație de 2,12%; pass-through a atins 1.748,5 MiB/s cu un coeficient de variație de 1,65%. Ambele au livrat corpul exact fără erori de client, protocol sau pierdere de pachete.
Configurează trecerea prin sistem intenționat
O configurație minimală de tip pass-through păstrează identitatea TLS pregătită astfel încât un operator să poată activa terminarea mai târziu fără a schimba căile certificatelor:
[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 = 30000Certificatul Webship pus în scenă este validat, dar nu este utilizat de sesiunile active de trecere prin proxy. Originea de la 10.0.0.20:443 trebuie să încheie TLS și să suporte protocolul negociat de client.
Activează terminarea atunci când marginea necesită HTTP
Pentru un edge conștient de aplicație, activați terminarea și trimiteți traficul HTTP rezultat către originea selectată:
[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 = 30000Această configurație poate ruta și inspecta HTTP. Adăugați TLS upstream atunci când rețeaua dintre Webship și origin nu este deja de încredere sau izolită.
Comutați modurile fără a reporni Webship
Webship poate schimba tls_termination printr-o reîncărcare a fișierului de configurare sau prin instrumentul webship.reverse_proxy.apply_config MCP verificat după versiune. Citiți obiectul și versiunea curentă cu webship.reverse_proxy.get_config, schimbați doar câmpul dorit în obiectul complet returnat și trimiteți-l cu expected_version_id corespunzător.
Noile conexiuni TCP utilizează noul mod. Clienții HTTP/3 se reconectează la transportul UDP înlocuit. Schimbările de cale pentru certificat și cheie rămân legate de proces și necesită o repornire, așa că păstrați o identitate de terminare validă pregătită înainte de o comutare live.
Verificarea versiunii împiedică un operator să suprascrie o modificare de configurație efectuată concomitent. O actualizare respinsă lasă configurația activă la rulare și configurația păstrată neschimbate.
O listă de verificare practică pentru selecție
Alegeți trecerea atunci când toate acestea sunt adevărate:
- Originea trebuie să păstreze limita certificatului și cheile de sesiune.
- Rutarea TCP la nivel SNI—sau un origin UDP HTTP/3 partajat—este suficientă.
- Originea oferă WAF-ul necesar, autorizarea, înregistrarea, limitele pentru corp și controalele împotriva abuzurilor.
- Nu este necesar cache la margine, rescrierea căii, politică de antet de redirecționare sau traducere a protocolului HTTP.
Alege terminarea atunci când oricare dintre acestea este necesar la Webship:
- Ruta după gazdă, cale sau metodă.
- Inspectați cererile cu WAF sau API Shield.
- Aplică limite pentru corp, timpi de expirare HTTP sau autentificare la margine.
- Cachează răspunsurile sau rescrie anteturile HTTP.
- Tradu între protocoalele HTTP downstream și upstream.
- Observați câmpurile HTTP la limita proxy-ului.
Indiferent de modul pe care îl selectați, testați SNI, ALPN, identitatea certificatului, anularea de către client, închiderea parțială upstream și integritatea exactă a răspunsului. Măsurați separat capacitatea cererii și rata de transfer a fluxului: modul cel mai rapid pentru un răspuns mic nu este neapărat modul cel mai rapid pentru un corp de 100 MB.
Webship face din pass-through opțiunea implicită deoarece un proxy nu ar trebui să lărgească tăcut limita sa de încredere. Terminarea rămâne o alegere operațională activă și explicită atunci când comportamentul la margine conștient de HTTP merită această responsabilitate.
Citește documentația completă despre [reverse-proxy](/docs/1.3.1), compară [matricea de referință](/benchmarks) acceptată sau descarcă Webship de la [Descărcări](/downloads).
Surse și metodă de conținut
Valorile de performanță sunt medii acceptate din benchmark-ul unificat Debian de capacitate Webship 1.3.1 datat 11 septembrie 2026; porțile de acceptare ale acestuia necesită zero erori de client, HTTP, socket, protocol, proxy, defalcare majoră de pagină și HTTP/3 pierdere de pachete.