X-Forwarded-For y equilibrio de carga efectivo
De hecho, LVS realiza un equilibrio de carga dinámico y realiza un aislamiento de tráfico o equilibrio de carga en función de la IP del nodo de acceso del cliente, lo cual es problemático. La razón es que en realidad es imposible saber si la IP de origen del cliente es la IP real o la IP proxy. Además, en circunstancias normales el acceso desde el cliente pasa por el proxy inverso de nuestro servidor. En estos momentos es aún más necesario conocer la IP real. Un ejemplo de proxy inverso es, por ejemplo, visito Yahoo Finance para verificar el precio de las acciones de Tesla:
Entonces, cuando DevOps de su empresa construye un servidor de equilibrio de carga, debe considerar este problema: cómo obtener el la verdadera identidad del cliente que inició la solicitud de IP, esto no se puede obtener en la mayoría de los casos, pero si no, es un pseudo equilibrio de carga, que solo equilibra la carga de la capa frontal del proxy inverso y no equilibra la carga de la IP de origen.
De lo anterior, podemos ver que la dirección remota es en realidad la dirección del servidor proxy inverso, que es la dirección remota/de origen de la solicitud HTTP. Esta dirección se utiliza en el protocolo de enlace de tres vías; , así como en el ACK; si se olvida, entonces la respuesta HTTP no se puede recibir, por lo que esta falsificación no tiene significado, es decir, la dirección remota es antifalsificación por defecto y solo la dirección remota es real del usuario; La dirección IP se perderá, por lo que existe el encabezado de extensión HTTP X-Forward-For. Servidor proxy inverso Al reenviar la solicitud HTTP de un usuario, la dirección IP real del usuario debe escribirse en X-Forward-For para que el servicio backend pueda. úsalo. Dado que X-Forward-For es modificable, la dirección en X-Forward-For no es confiable. Al realizar operaciones relacionadas con la seguridad, la dirección IP del usuario solo se puede obtener a través de la dirección remota y no se puede confiar en ningún encabezado de solicitud
Explicación de X-Forwarded-For en Wikipedia: X-Forwarded-For
Es decir, LB y proxy se usan generalmente para reducir el ancho de banda externo. Generalmente usamos proxy inverso, que es un proxy transparente;
Nota:
X. -Adelante: para Like Referer y User-Agent, son campos de encabezado en HTTP. El número de documento RFC de HTTP/1.1 es 2616. X-Forward-For no se menciona en 2616, lo que significa que X-Forward-For no nació cuando apareció HTTP/1.1. Lo que realmente propuso X-Forward-For fue el RFC7239 en 2014 (para más detalles, consulte https://www.rfc-editor.org/rfc/rfc7239.txt X-Forward-For aparece como una extensión HTTP;
RFC7239 es muy largo. De hecho, solo hay unas pocas partes que son relevantes para nosotros, como: 1. Resumen 7.5. Ejemplo de uso
El resumen es el resumen de este artículo. El papel de RFC7239:
Desde aquí entendemos que el propósito directo de X-Forward-For es facilitar que el servidor identifique la IP original y realice un procesamiento dinámico basado en la IP original. el servidor realiza el equilibrio de carga en función de las direcciones IP; si se puede ver el proxy IP, obtenga la dirección IP original, entonces puede realizar una carga efectiva. De lo contrario, puede provocar una distribución desigual de los recursos, lo que provocará un equilibrio de carga falso.
El uso de ejemplo proporciona un ejemplo:
Formato X-Forwarded-For:
Si una solicitud HTTP pasa a través de tres servidores proxy Proxy1, las IP de Proxy2 y Proxy3 son IP1, IP2 e IP3 respectivamente, y la IP real del usuario es IP0. Luego, de acuerdo con el estándar XFF, el servidor eventualmente recibirá la siguiente información:
Por lo tanto, si es de la primera capa de. el servidor proxy o la última capa, necesita recopilar IP reales para un equilibrio de carga real