Webship pang-inhinyeriya

Pagtatapos ng TLS o Pass-Through? Pumipili ng Tamang Webship Hangganan ng Reverse-Proxy

Pinapayagan ng TLS termination ang routing, caching, at inspeksyon ng seguridad ng HTTP; pinananatili ng pass-through ang plaintext at session keys sa pinagmulan. Ipinaliwanag sa gabay na ito ang mga trade-off, sukat na performance, at live na Webship na configuration.

Ipinag-publish September 10, 2026

Ang pagpili sa pagitan ng TLS termination at TLS pass-through ay hindi isang cosmetic na setting ng proxy. Ito ang nagtatakda kung saan nagtatapos ang encryption, aling sistema ang may hawak ng session keys, kung maaaring inspeksyunin ng Webship ang HTTP, at aling layer ang kailangang magpatupad ng seguridad ng aplikasyon.

Webship ay naka-default sa pass-through. Pinapanatili nito ang plaintext ng aplikasyon at ang active session keys sa pinagmulan. Payagan lamang ang termination kapag kailangan ng edge na maunawaan at kumilos sa HTTP request.

Ang desisyon sa isang pangungusap

Gumamit ng TLS pass-through kapag ang pinagmulan ay kailangang magkaroon ng sariling hangganan ng TLS. Gumamit ng TLS termination kapag ang Webship ay kailangang magpatakbo, magprotekta, mag-transform, mag-cache, o mag-obserba ng traffic ng HTTP.

Walang mode na mas ligtas sa lahat ng pagkakataon. Pinapababa ng pass-through ang dami ng sensitibong materyal na hinahawakan ng edge, ngunit tinatanggal nito ang mga kontrol sa seguridad ng HTTP ng edge. Nagdaragdag ang termination ng isang puntong maaaring suriin para sa pagpapatupad, ngunit ginagawa nitong bahagi ng pinagkakatiwalaang hangganan ng TLS ang Webship.

| Alalahanin | Pagtatapos ng TLS | Pagdaan ng TLS | | --- | --- | --- | | TLS endpoint | Webship | Pinagmulan | | Plaintext ng aplikasyon sa Webship | Oo | Hindi | | Mga aktibong susi ng downstream session sa Webship | Oo | Hindi | | Ruta ayon sa HTTP path o paraan | Oo | Hindi | | WAF, API Shield, at mga limitasyon sa katawan sa Webship | Oo | Hindi | | Proxy cache, mga pagbabago sa pagsusulat, at pagpapasa ng mga header | Oo | Hindi | | Input ng ruta ng TCP | Awtoridad ng HTTP at patakaran sa ruta | ClientHello SNI | | HTTP/3 ruting | Data ng HTTP request | Isang pinagbahaging pinagmulan ng UDP | | Pananagutan ng pinagmulan | HTTP o hiwalay na nakatakdang upstream TLS | Buong TLS, ALPN, at stack ng HTTP |

Ang mahalagang tanong ay hindi "Aling switch ang mas mabilis?" Ito ay "Aling bahagi ang dapat payagang makita at kontrolin ang kahilingan?"

Anong pagtatapos ang ibinibigay ng Webship

Sa pamamagitan ng tls_termination = true, tinatapos ng Webship ang downstream TLS at ipinasok ang nadecrypt na kahilingan sa kanyang HTTP reverse-proxy pipeline. Ginagawa nito ang mga sumusunod na tampok na posible:

routing na sumusunod sa path, host, at method;
WAF at pagsusuri ng API Shield;
mga limitasyon ng request-body at mga timeout ng patakaran;
proxy caching at generation-safe na pagbawi;
pamamahala ng forwarding-header at mga patlang ng HTTP access-log;
pag-handle ng query na may kamalayan sa katawan, muling pagtatangkang kung ligtas, at patakaran ng circuit-breaker;
salin ng protokol sa pagitan ng mga koneksyon na nakaharap sa kliyente at batayang koneksyon.

Binabago rin ng mode na ito ang responsibilidad sa seguridad. Ang Webship host ay dapat protektahan ang pribadong susi ng sertipiko, mga susi ng session, decrypted na data ng kahilingan at tugon, output ng observability, at anumang naka-cache na representasyon. Kung ang susunod na hop ay kailangang manatiling naka-encrypt, i-configure ang typed upstream TLS nang hiwalay; kung hindi, ang HTTP upstream ay malinaw na teksto.

Ang pagtatapos ay ang tamang hangganan kapag inaasahang kumilos ang Webship bilang isang application-aware na dulo, hindi lamang bilang isang encrypted na transport relay.

Ano ang pinapanatili ng pass-through

Sa tls_termination = false—ang default—Webship ay nagpapadala ng naka-encrypt na TLS o QUIC na trapiko nang hindi dine-decrypt ang HTTP na kahilingan o tugon. Ang plaintext ng aplikasyon at aktibong mga susi ng sesyon ay nananatili sa pinagmulan.

Mahalaga ang mas maliit na hangganan ng tiwala kapag ang mga sertipiko ay kailangang manatili sa tier ng aplikasyon, ipinagbabawal ng patakaran sa pagsunod ang decryption sa gilid, o ang isang TLS na pagkakakilanlan na partikular sa pinagmulan ay kailangang maabot ang kliyente nang hindi nagbabago. Inaalis din nito ang pag-parsing ng HTTP at ang gawain sa patakaran mula sa path ng relay.

Ang kapalit ay mahigpit: Webship ay hindi maaaring suriin ang hindi nito ma-decrypt. Hindi nito maaaring ipatupad ang mga patakaran ng HTTP WAF, mag-route ayon sa path, muling isulat ang mga header, ipatupad ang body-aware API policy, o punan ang HTTP-field access logs. Ang pinagmulan ay kailangang magbigay ng lahat ng kontrol na iyon mismo.

Ang pass-through ay hindi kaya't 'pagwawakas na may mas kaunting tampok.' Ito ay isang ibang arkitektura na may ibang may-ari ng seguridad.

Mahalaga ang mga limitasyong tiyak sa protocol

Para sa HTTP/1.1 TLS at HTTP/2 TLS, sinusuri lang ng Webship ang ClientHello hanggang sa sapat upang piliin ang naka-configure na TCP na destinasyon ayon sa SNI. Ang bawat pass-through na domain ay nangangailangan ng catch-all na path_prefix = "/" route dahil nananatiling naka-encrypt ang aktwal na path ng kahilingan. Ang isang kliyente na walang SNI ay tinatanggap lamang kapag ang configuration ay may isang domain.

Dapat makipag-ayos ang pinagmulan sa ALPN ng kliyente at suportahan ang napiling protocol. Hindi maaaring i-convert ng Webship ang HTTP/2 na kliyente sa HTTP/1.1 na pinagmulan habang ang session ng TLS ay dumaraan nang hindi nagbabago.

Gumagamit ang HTTP/3 ng QUIC sa ibabaw ng UDP at may mas mahigpit na hangganan. Hindi ligtas na maiparating ng pass-through ang ruta ayon sa encrypted HTTP authority, kaya bawat naka-configure na HTTP/3 route ay dapat mag-resolve sa parehong IP-socket UDP origin. Tinanggihan ng Webship ang Unix sockets at maraming HTTP/3 pass-through origins sa panahon ng validation ng configuration sa halip na tahimik na iruta nang malabo.

Ang Cleartext HTTP/1.1 at h2c ay hindi naapektuhan ng reverse_proxy.tls_termination. Kinokontrol ng setting ang downstream HTTP/1.1 TLS, HTTP/2 TLS, at HTTP/3 TLS lamang.

Sinukat na kapasidad ng kahilingan

Sinukat ng Webship 1.3.1 Debian capacity benchmark ang dalawang na-encrypt na reverse-proxy na mode nang hiwalay. Bawat tinanggap na halimbawa ay nangangailangan ng zero HTTP, socket, protocol, proxy, major-page-fault, at HTTP/3 na packet-loss errors.

| Mode ng reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Pagwawakas ng TLS | 123,344 RPS | 124,957 RPS | 131,529 RPS | | TLS pass-through | 203,950 RPS | 266,845 RPS | 167,010 RPS |

Ang small-response pass-through ay may mas kaunting trabaho na kailangang gawin ng application: ipinapasa nito ang naka-encrypt na transport data sa halip na i-terminate ang TLS, i-parse ang HTTP, suriin ang patakaran, at gumawa ng bagong downstream TLS stream. Ang mas mataas na pass-through request rates ay nagpapakita ng mas makitid na trabahong iyon.

Ang mga hilera na ito ay hindi kumakatawan sa magkatulad na set ng mga tampok, at hindi dapat gamitin upang igiit na ang isang arkitektura ng seguridad ay mas mahusay sa lahat ng pagkakataon. Ang termination ay nagbabayad para sa mga kakayahang batay sa HTTP na hindi kayang ibigay ng pass-through sa intensiyonal na paraan.

Binabago ng maramihang streaming ang resulta

Gumamit ang parehong benchmark ng eksaktong 99,943,778-byte na katawan ng tugon para sa 100 MB na streaming matrix. Dito, ang TLS termination ay nagbigay ng mas mataas na median na throughput ng payload para sa lahat ng tatlong protocol:

| Mode ng reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Pagwawakas ng TLS | 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 |

Bakit nagbabago ang direksyon? Sa termination mode, ang benchmark origin ay nagpapadala ng cleartext HTTP sa Webship, at ang Webship ay nagmamay-ari ng optimized downstream bulk path. Ang malalaking HTTP/1.1 at HTTP/2 na mga tugon ay maaaring gumamit ng adaptive Linux kTLS at bounded transport-specific buffering. Ang HTTP/3 ay gumagamit ng QUIC pacing, DPLPMTUD, at per-reactor batching sa halip na kTLS.

Sa pass-through mode, ang pinagmulan ang nagmamay-ari ng downstream TLS at ang Webship ay nagrarelay ng nagresultang encrypted stream o QUIC packets. Pinapanatili nito ang origin TLS boundary, ngunit hindi nito magagamit ang HTTP-aware bulk-response path ng Webship.

Sinuri rin ng pitong-sample na HTTP/3 kwalipikasyon ang katatagan. Ang natapos na streaming ay umabot sa 1,938.6 MiB/s median na may 2.12% na koepisyent ng pagbabago; ang pass-through ay umabot sa 1,748.5 MiB/s na may 1.65% na koepisyent ng pagbabago. Pareho nitong naihatid ang eksaktong katawan na walang mga error sa kliyente, protocol, at pagkawala ng pakete.

I-configure ang pass-through nang sinadya

Ang isang minimal na pass-through na konfigurasyon ay nagpapanatili ng identity ng TLS na naka-stage upang maaaring paganahin ng isang operator ang termination mamaya nang hindi binabago ang mga path ng sertipiko:

[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

Ang naka-stage na Webship na sertipiko ay napatunayan ngunit hindi ginagamit ng aktibong pass-through na mga session. Ang pinagmulan sa 10.0.0.20:443 ay dapat magtapos ng TLS at suportahan ang protocol na napagkasunduan ng kliyente.

Paganahin ang pagtatapos kapag kinakailangan ng edge ang HTTP

Para sa isang application-aware edge, paganahin ang pagtigil at ipadala ang nagresultang HTTP na trapiko sa napiling pinagmulan:

[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

Ang konfigurasyong ito ay maaaring mag-route at mag-inspeksyon ng HTTP. Magdagdag ng upstream TLS kapag ang network sa pagitan ng Webship at ng pinagmulan ay hindi pa pinagkakatiwalaan o hiwalay.

Magpalit ng mga mode nang hindi nire-restart Webship

Maaaring baguhin ng Webship ang tls_termination sa pamamagitan ng pag-reload ng configuration file o ang bersyon-na-sineguradong webship.reverse_proxy.apply_config MCP na tool. Basahin ang kasalukuyang bagay at bersyon gamit ang webship.reverse_proxy.get_config, baguhin lamang ang nilalayong field sa kumpletong ibinalik na bagay, at isumite ito gamit ang tumutugmang expected_version_id.

Gumagamit ang mga bagong TCP na koneksyon ng bagong mode. Ang HTTP/3 na mga kliyente ay muling kumokonekta sa pinalitang UDP transport. Ang mga pagbabago sa certificate at key path ay nananatiling nakatali sa proseso at nangangailangan ng restart, kaya tiyaking may naka-prepare na wastong termination identity bago ang isang live na pagpapalit.

Ang pag-check ng bersyon ay pumipigil sa isang operator na mapalitan ang kasabay na pagbabagong ginawa sa configuration. Ang tinanggihan na update ay hindi binabago ang aktibong runtime at ang naka-save na configuration.

Isang praktikal na talaan para sa pagpili

Piliin ang pass-through kapag lahat ng ito ay totoo:

Dapat panatilihin ng pinagmulan ang hangganan ng sertipiko at mga susi ng sesyon.
Ang SNI-level TCP routing—o isang ibinahaging HTTP/3 UDP origin—ay sapat na.
Ang pinagmulan ay nagbibigay ng kinakailangang WAF, awtorisasyon, pag-log, limitasyon sa katawan, at mga kontrol sa pang-aabuso.
Walang kinakailangang edge cache, path rewrite, forwarding-header policy, o pagsasalin ng HTTP protocol.

Pumili ng pagtatapos kapag alinman sa mga ito ay kinakailangan sa Webship:

Ruta ayon sa host, path, o method.
Suriin ang mga kahilingan gamit ang WAF o API Shield.
Ipataw ang mga limitasyon sa katawan, mga timeout ng HTTP, o authentication sa gilid.
I-cache ang mga tugon o isulat muli ang mga HTTP header.
Isalin sa pagitan ng downstream at upstream na mga HTTP protocol.
Obserbahan ang mga HTTP field sa hangganan ng proxy.

Anuman ang mode na piliin mo, subukan ang SNI, ALPN, identidad ng sertipiko, pagkansela ng kliyente, kalahating pagsasara sa upstream, at eksaktong integridad ng tugon. Sukatin ang kapasidad ng kahilingan at daloy ng streaming nang hiwalay: ang pinakamabilis na mode para sa maliit na tugon ay hindi kinakailangang ang pinakamabilis na mode para sa 100 MB na katawan.

Webship ang pass-through bilang default dahil hindi dapat tahimik na palawakin ng isang proxy ang hangganan ng tiwala nito. Ang termination ay nananatiling isang aktibo, hayagang pagpipilian sa operasyon kapag ang HTTP-aware na pag-uugali sa edge ay karapat-dapat sa responsibilidad na iyon.

Basahin ang buong [reverse-proxy documentation](/docs/1.3.1), ihambing ang tinanggap na [benchmark matrix](/benchmarks), o i-download ang Webship mula sa [Downloads](/downloads).

Mga pinagmulan at pamamaraan ng nilalaman

Ang mga halaga ng pagganap ay tinatanggap na mga karaniwang halaga mula sa Webship 1.3.1 pinagsama-samang benchmark sa kapasidad ng Debian na may petsang Setyembre 11, 2026; ang mga pintuan ng pagtanggap nito ay nangangailangan ng zero na client, HTTP, socket, protocol, proxy, major-page-fault, at HTTP/3 nawawalang packet na mga error.