Lo que se sitúa delante de casi todos los servicios web
Bienvenido
Si escribes example.com en un navegador, casi nunca llegas al equipo que realmente ejecuta la aplicación. Llegas a un equipo que reenvía la solicitud a uno que sí lo hace. Ese equipo de reenvío tiene un nombre: un proxy inverso.
Esta lección enseña qué hace un proxy inverso, por qué casi todos los servicios web públicos se ocultan detrás de uno y qué tres funciones maneja la capa de borde al mismo tiempo.
Al final entenderás:
- La diferencia entre un cliente, un proxy y un origen
- Por qué un proxy delante de un origen protege, escala y permite cambiar componentes sin que nadie se dé cuenta
- Las tres tareas que un proxy inverso maneja simultáneamente: ocultar el origen, terminar TLS y distribuir la carga entre réplicas
- Cómo viaja una solicitud desde el navegador hasta el proxy, luego al servidor upstream y de vuelta, salto a salto
Al finalizar, podrás razonar con confianza sobre la ubicación de los proxies, la separación de responsabilidades en el borde y por qué una capa de proxy sin estado se multiplica de forma económica, mientras que un único origen no.
Proxy Directo vs Proxy Inverso
Dos direcciones de proxy
Ambos tipos de proxy se sitúan entre dos partes y retransmiten el tráfico. Difieren en qué parte representan.
Proxy de reenvío (Forward proxy): se sitúa delante de un grupo de clientes. Los clientes conocen la existencia del proxy; un servidor externo ve la dirección del proxy, no la dirección del cliente. Los proxies de salida corporativos, los filtros de contenido y los proxies SOCKS encajan en este patrón.
Proxy inverso (Reverse proxy): se sitúa delante de un grupo de servidores. El mundo exterior (los clientes) se comunica con la dirección del proxy; los clientes no tienen ni idea de que hay un servidor real oculto detrás. Casi todos los servicios web públicos utilizan uno.
Mnemotecnia: un proxy de reenvío oculta a los clientes de los servidores. Un proxy inverso oculta a los servidores de los clientes.
¿Por qué importa la dirección? La función, los modos de fallo y el límite de seguridad son todos diferentes. Un proxy de reenvío se preocupa por quién contactan sus usuarios; un proxy inverso se preocupa por quién contacta con sus servidores.
Un cliente que envía tráfico a través de ambos tipos a la vez viaja: client -> forward_proxy -> internet -> reverse_proxy -> origin.
Por qué tanto reside en el borde
La capa de borde justifica su existencia
Un proxy inverso realiza tres funciones simultáneamente. Cualquiera de ellas justifica la capa por sí sola; realizar las tres en la misma dirección explica por qué casi toda arquitectura web de producción tiene la misma forma en la parte frontal.
Función 1: Ocultar el origen. El proxy responde en una IP pública. Los backends están en IPs privadas a las que internet no puede acceder. Un atacante que quiera atacar el origen debe primero comprometer el proxy.
Función 2: Terminar TLS. El proxy posee el certificado para example.com y descifra las solicitudes HTTPS entrantes. Los backends hablan HTTP plano (o un TLS interno más simple) con el proxy a través de un segmento de red de confianza. La rotación, renovación y política de cifrado de los certificados se gestionan en un solo lugar.
Función 3: Distribuir la carga. El proxy elige qué backend procesa cada solicitud. Los backends detrás de un mismo proxy forman un pool; el proxy selecciona uno por solicitud utilizando una estrategia (round-robin, menos conexiones, hash sobre un encabezado). Añadir capacidad significa añadir un backend al pool, no informar a cada cliente de una nueva dirección.
Cada función es un pequeño programa. Juntas explican por qué un nivel tan simple como «Caddy delante de una aplicación Python» tiene más peso de diseño que la propia aplicación Python.
Diseño para las tres funciones
Tu equipo ejecuta una pequeña API en un único proceso Python que escucha en el puerto 8000 en una única VM. El tráfico ha crecido lo suficiente como para que una sola VM no pueda seguir el ritmo, y una revisión de seguridad señaló que la VM tiene una IP pública y ejecuta su propio certificado TLS.
Decides colocar un proxy inverso delante. Dibuja el esquema: ¿a dónde apunta el DNS, dónde reside el certificado, cómo llega la carga a los backends y qué cambia en la VM original?
Sustituir un componente sin que nadie se dé cuenta
La indirecta compra libertad
Un viejo adagio de la informática sostiene: todo problema puede resolverse añadiendo una capa de indirección (excepto el problema de tener demasiadas capas de indirección). El proxy inverso es una de las indirecciones más útiles en los sistemas distribuidos.
Lo que te aporta:
- Backends intercambiables. ¿Mueves la aplicación de Python a Go? ¿Migras de un centro de datos a otro? ¿Lanzas una nueva versión con cero tiempo de inactividad? Cada uno de estos cambios ocurre detrás de una dirección pública estable. Nada cambia para los usuarios.
- Escala independiente. La capa del proxy escala según el ancho de banda y la CPU en la capa TLS. La capa del backend escala según el trabajo de la aplicación. Cada una crece en su propio eje porque residen en máquinas diferentes.
- Contención de fallos. Una implementación defectuosa en el backend no derriba la dirección pública. El proxy sigue activo; aplicas una corrección o haces una reversión; el mundo se reconecta cuando el backend se recupera.
- Preocupaciones transversales en un solo lugar. Limitación de tasa, bloqueo geográfico, registro de solicitudes, reescritura de encabezados, caché, compresión de respuestas: todo reside en el proxy. El código del backend se mantiene enfocado en la aplicación.
Sin el proxy, cada uno de estos problemas debe residir dentro del proceso de la aplicación. Con el proxy, residen en una capa que un solo equipo posee.
El costo: otra capa que operar. Los equipos maduros aceptan el costo porque la capa del proxy en sí misma es sin estado y escala horizontalmente; reemplazar un proxy por dos no requiere coordinación.
Una implementación azul/verde a través del proxy
Su equipo ejecuta la versión 1 de la API en tres VMs de backend (pila azul) detrás de un proxy inverso. Desea implementar la versión 2 con la capacidad de revertir en menos de treinta segundos si algo sale mal.
Inicia tres nuevas VMs de backend (pila verde) ejecutando la versión 2, junto a la pila azul, pero aún no enruta ningún tráfico hacia ellas.
Del Navegador al Backend y de Vuelta
Sigue una Solicitud de Extremo a Extremo
Rastrea una única solicitud HTTPS GET de https://api.example.com/users/42 a través de un proxy inverso situado frente a un grupo de backends.
Salto 1: Resolución de DNS. El navegador consulta a un resolver por api.example.com. El resolver devuelve la IP pública del proxy (por ejemplo, 203.0.113.10). El navegador abre una conexión TCP a 203.0.113.10:443.
Salto 2: Handshake de TLS. El proxy presenta su certificado para api.example.com. El navegador valida el certificado, ambas partes acuerdan una clave de sesión y se abre el canal cifrado.
Salto 3: Solicitud HTTP dentro de TLS. El navegador envía GET /users/42 HTTP/1.1\nHost: api.example.com\n.... El proxy descifra los bytes de la solicitud.
Salto 4: Selección de backend. El proxy consulta su grupo de servidores upstream para api.example.com y elige un backend (por ejemplo, 10.0.0.21:8000) utilizando su estrategia de balanceo de carga.
Salto 5: Solicitud upstream. El proxy abre (o reutiliza) una conexión HTTP simple con 10.0.0.21:8000 y reenvía la solicitud. El proxy puede reescribir encabezados en el proceso: añadir X-Forwarded-For: <client-ip>, establecer correctamente Host: y eliminar encabezados de salto a salto (hop-by-hop) como Connection.
Salto 6: Procesamiento del backend. La aplicación del backend lee la solicitud, consulta su base de datos y construye una respuesta JSON.
Salto 7: Respuesta upstream. El backend envía la respuesta de vuelta al proxy como HTTP simple.
Salto 8: Respuesta en el borde. El proxy puede reescribir o comprimir la respuesta, la cifra de nuevo a través de la sesión TLS y la envía al navegador.
Salto 9: Ciclo de vida de la conexión. La sesión TLS generalmente permanece abierta para la siguiente solicitud (HTTP/2 multiplexa muchas solicitudes en una sola conexión). La conexión del proxy al backend a menudo se agrupa (pooling) para su reutilización.
Todo servicio web público sigue alguna variante de esta estructura. Conocer los saltos te permite razonar sobre dónde se acumula la latencia, dónde debe ubicarse la registración de eventos (logging) y dónde puede ocultarse un fallo.
¿A dónde fue a parar el tiempo?
Un usuario se queja de que la API se siente lenta. Mides y descubres que la solicitud tarda 850 ms de principio a fin. Los registros del servidor en el backend muestran que la aplicación procesó la solicitud en 40 ms. Los registros del proxy indican que el proxy dedicó 50 ms a su parte del trabajo (acercamiento TLS + enrutamiento + escritura de la respuesta).
Diseña un borde mínimo para un nuevo servicio
Síntesis
Has aprendido la diferencia entre un proxy hacia adelante y un proxy inverso, las tres funciones que un proxy inverso maneja simultáneamente, por qué ocultar el origen de pago dividendos cada vez que necesitas cambiar algo, y cómo fluye una solicitud de salto en salto a través del borde.
Ahora aplícalo.
Un pequeño equipo planea lanzar un nuevo servicio llamado notes.example.com. Los usuarios leerán y escribirán notas personales. El equipo ejecutará dos VMs de backend al lanzamiento y espera escalar a diez en el próximo año. Quieren HTTPS para los usuarios, despliegue gradual para nuevas versiones y ninguna exposición pública de las IPs de los backends.
Hacia dónde va este curso
Hacia dónde va este curso
Esta lección estableció la forma de la capa de borde. Cuatro lecciones más en este curso se construyen sobre ella:
- Escala horizontal sin estado: por qué una capa de proxy (y los backends detrás de ella) se multiplica de forma económica, y la matemática para dimensionar el número de réplicas ante picos de tráfico.
- Separación de tráfico de entrada y salida: por qué un solo servidor proxy que maneja tanto el tráfico entrante como el saliente falla eventualmente de formas sorprendentes, y cómo dividir las capas.
- Modos de fallo y alcance del impacto: cómo un solo cambio de configuración puede desencadenar una interrupción del servicio y cómo redactar acciones correctivas sin culpas que prevengan la recurrencia.
- Observabilidad y capacidad: qué medir en el borde para detectar que algo está roto antes de que lo hagan los usuarios.
Cada lección es independiente. Tomadas en conjunto, te proporcionan un modelo mental funcional de una flota a escala web.
Lección complementaria: geometry_of_proxies_and_origins reformula todo lo de esta lección como un grafo dirigido y explora lo que la teoría de grafos te dice sobre una ruta de solicitud.
Buen trabajo. Adelante.