Qué se encuentra frente a casi todos los servicios web
Bienvenido
Si escribe example.com en un navegador, casi nunca llega a la máquina que realmente ejecuta la aplicación. Llega a una máquina que envía la solicitud a una que lo hace. Esa máquina de enlace lleva un nombre: una proxy inversa.
Esta lección enseña qué hace una proxy inversa, por qué casi todos los servicios web públicos ocultan detrás de una y qué tres trabajos lleva a cabo 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 frente a un origen protege, escala y permite cambiar piezas sin que nadie se dé cuenta
- Los tres trabajos que maneja una proxy inversa al mismo tiempo: ocultar el origen, terminar TLS y distribuir la carga entre replicas
- Cómo una solicitud viaja desde el navegador hasta el proxy, upstream y de vuelta, paso a paso
Al final, razonarás con confianza sobre la ubicación de los proxies, la separación de responsabilidades en la orilla y por qué una capa de proxy sin estado se multiplica fácilmente mientras un solo origen no lo hace.
Proxy Forward vs Proxy Inversa
Dos direcciones de proxy
Ambos tipos de proxy están entre dos partes y relajan el tráfico. Diferencian en qué parte representan.
Proxy forward: se interpone entre un grupo de clientes. Los clientes saben sobre un proxy; un servidor externo ve una dirección de proxy, no una dirección de cliente.
Proxy inversa: se interpone entre un grupo de servidores. El mundo externo (los clientes) habla con una dirección de proxy; los clientes no tienen idea de que un servidor real se esconde detrás.
Mnemonica: un proxy forward esconde a los clientes de los servidores. Un proxy inversa esconde a los servidores de los clientes.
¿Por qué importa en qué dirección? El trabajo, los modos de falla y el límite de seguridad difieren. Un proxy forward se preocupa por quién sus usuarios contactan; un proxy inversa se preocupa por quién contacta a sus servidores.
Un cliente que envía tráfico a través de ambos a la vez viaja: cliente -> proxy_forward -> internet -> proxy_inversa -> origen.
¿Por qué tanto en la Orilla
La Capa de Orilla Gana Su Busto
Un proxy inverso lleva a cabo tres trabajos al mismo tiempo. Cualquiera de ellos justifica el nivel; llevar a cabo todos ellos en la misma dirección explica por qué casi toda la arquitectura web en producción tiene la misma forma en la parte del frente.
Trabajo 1: Esconder el origen. El proxy responde en una IP pública. Los backends están en IPs privadas que el internet no puede alcanzar. Un atacante que quiere golpear el origen debe comprometer primero el proxy.
Trabajo 2: Terminar TLS. El proxy tiene el certificado para example.com y descifra las solicitudes HTTPS entrantes. Los backends hablan HTTP plano (o TLS más simple interno) con el proxy en una segmento de red confiable. La rotación, renovación y política de cifrado viven en un lugar.
Trabajo 3: Distribuir carga. El proxy elige qué backend maneja cada solicitud. Los backends detrás de un proxy forman una piscina; el proxy elige uno por solicitud usando una estrategia (en orden, menos conexiones, hash en una cabecera). Añadir capacidad significa añadir un backend a la piscina, no decir a cada cliente una nueva dirección.
Cada trabajo es un pequeño programa. Juntos explican por qué una capa tan simple como 'Caddy frente a una aplicación de Python' lleva más peso en el diseño que la aplicación de Python en sí.
Diseñando para Todos Tres
Tu equipo corre una pequeña API en un solo proceso de Python escuchando en el puerto 8000 en una sola VM. El tráfico ha crecido lo suficiente como para que una sola VM no pueda seguir, y una revisión de seguridad señaló que la VM tiene una IP pública y tiene su propio certificado TLS.
Decides poner un proxy inverso delante. Esboza el esquema: ¿a dónde apunta DNS, dónde vive el certificado, cómo llega la carga de carga a los backends y qué cambia sobre la VM original?
Intercambiar una Componente Sin Que Nadie Se Diga Nada
La Indirección Compra Libertad
Un viejo aforismo de la informática sostiene: todos los problemas se pueden resolver agregando una capa de indirección (excepto el problema de tener demasiadas capas de indirección). La reversa proxy es una de las indirecciones más útiles en los sistemas distribuidos.
Lo que te compra:
- Backends intercambiables. Cambiar la aplicación de Python a Go? Migrar de uno a otro datacenter? Desplegar una nueva versión con tiempo de inactividad cero? Cada uno de ellos ocurre detrás de una dirección pública estable. Nada cambia para los usuarios.
- Escalabilidad independiente. La capa de proxy se escala en función de la banda ancha y la CPU en el nivel de TLS. La capa de backend se escala en función del trabajo de la aplicación. Cada una crece en su propio eje porque viven en máquinas diferentes.
- Contención de fallos. Una mala implementación en el backend no derriba la dirección pública. La proxy sigue funcionando; puedes empujar una corrección o dar marcha atrás; el mundo se vuelve a conectar cuando el backend se recupera.
- Preocupaciones transversales en un lugar. Limitación de velocidad, bloqueo por zona, registro de solicitudes, reescritura de encabezados, caché, compresión de respuestas: todo vive en la proxy. El código del backend se centra en la aplicación.
Sin la proxy cada uno de estos problemas debe vivir dentro del proceso de la aplicación. Con la proxy viven en una capa que un equipo posee.
El costo: otra capa que administrar. Los equipos maduros aceptan el costo porque la capa de proxy en sí misma corre sin estado y se escala horizontalmente; reemplazar una proxy por dos no requiere coordinación.
Un Despliegue Azul/Verde a Través de la Proxy
Tu equipo ejecuta la versión 1 de la API en tres VM de backend (pool azul) detrás de una reversa proxy. Quieres desplegar la versión 2 con la capacidad de dar marcha atrás en menos de treinta segundos si algo sale mal.
Lanzas tres nuevas VM de backend (pool verde) ejecutando la versión 2, junto a lado con el pool azul, pero aún no rutas ningún tráfico a ellas.
De Navegador a Backend y de Regreso
Sigue una Solicitud HTTPS de Principio a Fin
Rastree una sola solicitud GET HTTPS de https://api.example.com/users/42 a través de una proxy inversa frente a una piscina de backends.
Paso 1: Resolución DNS. El navegador pregunta a un resolvente para api.example.com. El resolvente devuelve la IP pública de la proxy (digamos, 203.0.113.10). El navegador abre una conexión TCP a 203.0.113.10:443.
Paso 2: Manosaca de TLS. La proxy presenta su certificado para api.example.com. El navegador valida el certificado, los dos lados acuerdan una clave de sesión y se abre el canal cifrado.
Paso 3: Solicitud HTTP dentro de TLS. El navegador envía GET /users/42 HTTP/1.1\nHost: api.example.com\n.... La proxy descifra los bytes de la solicitud.
Paso 4: Selección de backend. La proxy consulta su piscina de backends para api.example.com y elige uno (digamos 10.0.0.21:8000) utilizando su estrategia de equilibrio de carga.
Paso 5: Solicitud de upstream. La proxy abre (o reutiliza) una conexión HTTP en claro a 10.0.0.21:8000 y reenvía la solicitud. La proxy puede reescribir encabezados en el camino: agregar X-Forwarded-For: <client-ip>, establecer Host: correctamente, eliminar encabezados como Connection que se transmiten de hop en hop.
Paso 6: Procesamiento de backend. La aplicación de backend lee la solicitud, consulta su base de datos y crea una respuesta JSON.
Paso 7: Respuesta de upstream. El backend envía la respuesta de regreso a la proxy en forma de HTTP en claro.
Paso 8: Respuesta de borde. La proxy puede reescribir o comprimir la respuesta, cifrarla nuevamente a través de la sesión TLS y enviarla al navegador.
Paso 9: Ciclo de vida de la conexión. La sesión TLS generalmente permanece abierta para la siguiente solicitud (HTTP/2 multiplexa varias solicitudes en una conexión). La conexión proxy-a-backend a menudo se almacena en una piscina para su reutilización.
Cada servicio web público sigue una variante de esta forma. Conocer los pasos te permite razonar sobre dónde se acumula la latencia, dónde pertenece el registro y dónde puede ocultarse un error.
¿Dónde se fue el tiempo?
Un usuario se queja de que la API parece lenta. Mides y encuentras que la solicitud toma 850 ms de principio a fin. Los registros del servidor en el backend muestran que la aplicación atendió la solicitud en 40 ms. Los registros del proxy muestran que el proxy pasó 50 ms en su lado del trabajo (mano de TLS + enrutamiento + escritura de respuesta).
Diseña una Arquitectura Mínima de Orilla para un Nuevo Servicio
Síntesis
Has aprendido la diferencia entre un proxy hacia adelante y hacia atrás, los tres trabajos que maneja simultáneamente un proxy hacia atrás, por qué es un pago ocultar el origen cada vez que necesitas cambiar algo y cómo una solicitud fluye de un salto a través de la orilla.
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 VM de backend en el lanzamiento y espera escalar a diez en el siguiente año. Quieren HTTPS para los usuarios, lanzamiento gradual para nuevas versiones y ninguna exposición pública de IPs de backend.
Dónde Continúa Este Curso
Dónde Continúa Este Curso
Esta lección estableció la forma de la capa de orilla. Otras cuatro lecciones en este curso se basan en ella:
- Escalabilidad Horizontal Sin Estado: por qué una capa de proxy (& los backends detrás de ella) se multiplica barata y la matemática para dimensionar los conteos de copias bajo inundación.
- Separación de Ingreso / Egreso: por qué una caja de proxy que maneja tanto tráfico entrante como saliente finalmente falla de manera sorprendente y cómo dividir los capas.
- Modos de Fallo y Radio de Explosión: cómo un cambio de configuración se desborda en una interrupción y cómo escribir acciones sin culpa que prevengan la repetición.
- Observabilidad y Capacidad: qué medir en la orilla para saber que algo está roto antes de que los usuarios lo hagan.
Cada lección se sostiene por sí sola. Juntas, te dan un modelo mental de trabajo de una flota a nivel de web.
Lección complementaria: geometry_of_proxies_and_origins redibuja todo en esta lección como un gráfico dirigido y explora qué le dice la teoría de los grafos sobre un camino de solicitud.
Bien hecho. Adelante.