Elegir entre la terminación TLS y el paso de TLS no es un ajuste cosmético del proxy. Decide dónde termina el cifrado, qué sistema posee las claves de sesión, si Webship puede inspeccionar HTTP y qué capa debe hacer cumplir la seguridad de la aplicación.
Webship predeterminado es pasar a través. Eso mantiene la aplicación en texto plano y las claves de sesión activas en el origen. Habilite la terminación solo cuando el borde deba comprender y actuar sobre la solicitud HTTP.
La decisión en una oración
Use paso a través de TLS cuando el origen deba poseer el límite TLS. Use terminación TLS cuando Webship deba enrutar, proteger, transformar, almacenar en caché u observar el tráfico HTTP.
Ningún modo es universalmente más seguro. El paso directo reduce el material sensible manejado por el borde, pero elimina los controles de seguridad HTTP del borde. La terminación añade un punto de aplicación inspeccionable, pero hace que Webship forme parte del límite de confianza TLS.
| Preocupación | Terminación TLS | Paso a través de TLS | | --- | --- | --- | | Punto final TLS | Webship | Origen | | Texto sin formato de la aplicación en Webship | Sí | No | | Claves de sesión activa aguas abajo en Webship | Sí | No | | Ruta por ruta HTTP o método | Sí | No | | WAF, Escudo API y límites de cuerpo en Webship | Sí | No | | Caché de proxy, reescrituras y encabezados de reenvío | Sí | No | | Entrada de enrutamiento TCP | Autoridad y política de ruta HTTP | SNI de ClientHello | | HTTP/3 enrutamiento | Datos de solicitud HTTP | Un origen UDP compartido | | Responsabilidad de origen | HTTP o TLS upstream configurado por separado | TLS completo, ALPN y pila HTTP |
La pregunta importante, por lo tanto, no es “¿Cuál interruptor es más rápido?” Es “¿Qué componente debe poder ver y controlar la solicitud?”
Qué terminación da Webship
Con tls_termination = true, Webship completa TLS descendente y alimenta la solicitud descifrada en su canal de proxy inverso HTTP. Eso hace posibles las siguientes funciones:
- enrutamiento consciente de la ruta, el host y el método;
- Inspección de WAF y API Shield;
- límites del cuerpo de la solicitud y tiempos de espera de la política;
- caché de proxy e invalidación segura para la generación;
- gestión de encabezados de reenvío y campos del registro de acceso HTTP;
- manejo de consultas consciente del cuerpo, reintentos cuando sea seguro y política de cortacircuitos;
- traducción de protocolo entre las conexiones orientadas al cliente y las conexiones ascendentes.
Este modo también cambia la responsabilidad de seguridad. El host Webship debe proteger la clave privada del certificado, las claves de sesión, los datos de solicitud y respuesta descifrados, la salida de observabilidad y cualquier representación en caché. Si el siguiente salto debe permanecer encriptado, configure TLS ascendente tipado por separado; de lo contrario, el ascendente HTTP está en texto claro.
La terminación es el límite derecho cuando se espera que Webship se comporte como un borde consciente de la aplicación, y no solo como un relevo de transporte cifrado.
Lo que preserva el paso
Con tls_termination = false, el valor predeterminado, Webship retransmite el tráfico TLS o QUIC cifrado sin descifrar la solicitud o respuesta HTTP. El texto plano de la aplicación y las claves de sesión activas permanecen en el origen.
Ese límite de confianza más pequeño es valioso cuando los certificados deben permanecer en la capa de la aplicación, la política de cumplimiento prohíbe la descifrado en el borde, o una identidad TLS específica del origen debe llegar al cliente sin cambios. También elimina el análisis de HTTP y el trabajo de políticas del camino de retransmisión.
La compensación es estricta: Webship no puede inspeccionar lo que no puede descifrar. No puede aplicar reglas HTTP WAF, enrutar por ruta, reescribir encabezados, hacer cumplir políticas de API conscientes del cuerpo, ni llenar registros de acceso de campos HTTP. El origen debe proporcionar todos esos controles por sí mismo.
Por lo tanto, Pass-through no es “terminación con menos funciones”. Es una arquitectura diferente con un propietario de seguridad diferente.
Los límites específicos del protocolo importan
Para TLS HTTP/1.1 y TLS HTTP/2, Webship inspecciona el ClientHello solo lo suficiente para seleccionar el destino TCP configurado mediante SNI. Cada dominio de paso necesita una ruta path_prefix = "/" de captura general porque la ruta real de la solicitud permanece cifrada. Un cliente sin SNI se acepta solo cuando la configuración tiene un dominio.
El origen debe negociar el ALPN del cliente y soportar el protocolo seleccionado. Webship no puede convertir un cliente HTTP/2 en un origen HTTP/1.1 mientras la sesión TLS pasa sin cambios.
HTTP/3 utiliza QUIC sobre UDP y tiene un límite más estricto. El paso a través no puede enrutar de forma segura por la autoridad HTTP cifrada, por lo que cada ruta HTTP/3 configurada debe resolverse al mismo origen UDP de socket IP. Webship rechaza sockets Unix y múltiples orígenes de paso a través HTTP/3 durante la validación de configuración en lugar de enrutar silenciosamente de manera ambigua.
El texto claro HTTP/1.1 y h2c no se ven afectados por reverse_proxy.tls_termination. La configuración controla únicamente TLS HTTP/1.1 aguas abajo, TLS HTTP/2 y TLS HTTP/3.
Capacidad de solicitud medida
El Webship 1.3.1 banco de pruebas de capacidad de Debian midió los dos modos de proxy inverso cifrados por separado. Cada muestra aceptada requirió cero errores de HTTP, socket, protocolo, proxy, fallo de página principal y HTTP/3 pérdida de paquetes.
| Modo de proxy inverso | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminación TLS | 123,344 RPS | 124,957 RPS | 131,529 RPS | | Paso de TLS | 203,950 RPS | 266,845 RPS | 167,010 RPS |
El paso a través de respuesta pequeña tiene menos trabajo de aplicación que realizar: retransmite datos de transporte encriptados en lugar de terminar TLS, analizar HTTP, evaluar políticas y producir un nuevo flujo TLS descendente. Las mayores tasas de solicitudes de paso a través reflejan ese trabajo más limitado.
Estas filas no representan conjuntos de funciones idénticos, y no deben usarse para afirmar que una arquitectura de seguridad es universalmente mejor. La terminación paga por capacidades conscientes de HTTP que el paso a través intencionalmente no puede proporcionar.
La transmisión masiva cambia el resultado
El mismo punto de referencia utilizó un cuerpo de respuesta exacto de 99,943,778 bytes para la matriz de transmisión de 100 MB. Aquí, la terminación TLS produjo un mayor rendimiento medio de carga útil para los tres protocolos:
| Modo de proxy inverso | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminación TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Paso a través de TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |
¿Por qué cambia la dirección? En el modo de terminación, el origen de referencia envía HTTP en texto claro a Webship, y Webship posee la ruta optimizada de transferencia masiva descendente. Grandes respuestas de HTTP/1.1 y HTTP/2 pueden usar kTLS adaptativo en Linux y almacenamiento en búfer acotado específico del transporte. HTTP/3 utiliza control de ritmo de QUIC, DPLPMTUD y procesamiento por lotes por reactor en lugar de kTLS.
En modo de paso, el origen posee TLS descendente y Webship retransmite la transmisión encriptada o los paquetes QUIC resultantes. Eso preserva el límite de TLS del origen, pero no puede usar la ruta de respuesta masiva consciente de HTTP de Webship.
La calificación de siete muestras HTTP/3 también verificó la estabilidad. La transmisión terminada alcanzó una mediana de 1,938.6 MiB/s con un coeficiente de variación de 2.12%; el paso a través alcanzó 1,748.5 MiB/s con un coeficiente de variación de 1.65%. Ambos entregaron el cuerpo exacto sin errores de cliente, protocolo ni pérdida de paquetes.
Configure el paso a través deliberadamente
Una configuración mínima de paso mantiene la identidad TLS preparada para que un operador pueda habilitar la terminación más tarde sin cambiar las rutas de certificados:
[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 = 30000El certificado Webship en escena está validado pero no es utilizado por sesiones activas de paso. El origen en 10.0.0.20:443 debe finalizar TLS y soportar el protocolo negociado por el cliente.
Habilitar la terminación cuando el borde necesite HTTP
Para un edge consciente de la aplicación, habilite la terminación y envíe el tráfico HTTP resultante al origen seleccionado:
[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 = 30000Esta configuración puede enrutar e inspeccionar HTTP. Agregue TLS ascendente cuando la red entre Webship y el origen no sea ya confiable o esté aislada.
Cambiar modos sin reiniciar Webship
Webship puede cambiar tls_termination a través de una recarga del archivo de configuración o de la herramienta webship.reverse_proxy.apply_config MCP con verificación de versión. Lea el objeto y la versión actuales con webship.reverse_proxy.get_config, cambie solo el campo previsto en el objeto completo devuelto y envíelo con el expected_version_id correspondiente.
Las nuevas conexiones TCP utilizan el nuevo modo. Los clientes HTTP/3 se vuelven a conectar al transporte UDP reemplazado. Los cambios en la ruta del certificado y la clave continúan ligados al proceso y requieren un reinicio, por lo que debe mantener una identidad de terminación válida preparada antes de un cambio en vivo.
La verificación de versiones evita que un operador sobrescriba un cambio de configuración concurrente. Una actualización rechazada deja la configuración activa en tiempo de ejecución y la configuración persistida sin cambios.
Una lista de verificación práctica para la selección
Elija pasar a través cuando todas estas sean verdaderas:
- El origen debe mantener el límite del certificado y las claves de sesión.
- El enrutamiento TCP a nivel SNI, o un origen UDP HTTP/3 compartido, es suficiente.
- El origen proporciona el WAF necesario, autorización, registro, límites de cuerpo y controles de abuso.
- No se requiere caché de borde, reescritura de rutas, política de encabezados de reenvío ni traducción del protocolo HTTP.
Elija terminación cuando se requiera cualquiera de estos en Webship:
- Enrutar por host, ruta o método.
- Inspeccionar solicitudes con WAF o API Shield.
- Aplicar límites de cuerpo, tiempos de espera HTTP o autenticación en el borde.
- Almacenar en caché las respuestas o reescribir los encabezados HTTP.
- Traducir entre los protocolos HTTP descendente y ascendente.
- Observe los campos HTTP en el límite del proxy.
Cualquiera que sea el modo que selecciones, prueba SNI, ALPN, la identidad del certificado, la cancelación del cliente, el cierre parcial ascendente y la integridad exacta de la respuesta. Mide la capacidad de solicitudes y el rendimiento de transmisión por separado: el modo más rápido para una respuesta pequeña no es necesariamente el modo más rápido para un cuerpo de 100 MB.
Webship hace que el paso directo sea la opción predeterminada porque un proxy no debería ampliar silenciosamente su límite de confianza. La terminación sigue siendo una elección operativa explícita y vigente cuando vale la pena esa responsabilidad por el comportamiento en el borde consciente de HTTP.
Lee toda la [documentación de reverse-proxy](/docs/1.3.1), compara la [matriz de referencia](/benchmarks) aceptada, o descarga Webship de [Descargas](/downloads).
Fuentes y método de contenido
Los valores de rendimiento son medianas aceptadas del Webship 1.3.1 punto de referencia unificado de capacidad de Debian fechado el 11 de septiembre de 2026; sus criterios de aceptación requieren cero errores de cliente, HTTP, socket, protocolo, proxy, fallo de página principal y pérdida de paquetes HTTP/3.