El protocolo HTTP se ejecuta sobre el protocolo TCP pero proporciona información adicional sobre el destino del
mensaje. Por esta razón, los dos proxies se configuran de manera distinta.
El tráfico HTTP incluye el host y el puerto de destino del mensaje y se envía a través
de una conexión TCP a un punto final TCP, es decir, un host y un puerto específicos. Normalmente,
el mensaje HTTP especifica el mismo punto final TCP con el que se realiza la conexión TCP subyacente. Si cambia la configuración del cliente para que utilice un proxy HTTP, la conexión TCP se lleva a cabo con un host
y un puerto distintos de los URL de HTTP, lo que significa que el punto final TCP del mensaje no es igual que
el del punto final al que se está conectando. Por ejemplo, si la solicitud HTTP se envía a http://192.0.2.1:8080/operation,
la solicitud incluye "192.0.2.1:8080" en la cabecera "Host" del mensaje HTTP que se envía al
puerto TCP 8080 en el host 192.0.2.1.
No obstante, si configura el cliente HTTP para que utilice un proxy, la conexión TCP subyacente va al punto
final TCP para el proxy, mientras que los mensajes todavía contienen el punto final TCP original. Por ejemplo,
si configura el cliente para enviar sus mensajes a un proxy 198.51.100.1, puerto 3128, y el cliente
envía una solicitud para http://192.0.2.1:8080/operation, el mensaje todavía contiene "192.0.2.1:8080" en
la cabecera "Host" y ahora también en el campo "Request-Line". Sin embargo, ahora este mensaje se envía a través de una
conexión TCP con el proxy en 198.51.100.1:3128.
De esta manera, el proxy HTTP puede recibir mensajes en un solo puerto y puede
reenviar dichos mensajes a muchos servicios distintos basándose en la información de destino del mensaje.
Nota: La cabecera "Host" se añadió en HTTP/1.1. Las conexiones HTTP/1.0 no incluye esta cabecera. Por este motivo,
las conexiones HTTP/1.0 que no pasan a través de un proxy no incluyen el host y el puerto
para el mensaje. No obstante, los mensajes HTTP/1.0 que se envían a un proxy contienen todavía el host y el puerto
de destino en "Request-Line"; por lo tanto, la ausencia de una cabecera "Host"
no crea un problema a los proxies.
Para habilitar un proxy TCP, se cambia la configuración de cliente del punto final TCP del sistema activo por el
punto final TCP del proxy. Al contrario de HTTP, TCP no incorpora la posibilidad de utilizar un proxy. Es decir, si
se conecta un proxy a través de TCP, no hay ningún mecanismo definido para comunicar al proxy el
destino final previsto. La única manera de que un proxy TCP permita conexiones con varios sistemas activos (es decir,
con destinos finales o
puntos finales adelantados), sin conocer el tráfico existente en dichas
conexiones, es escuchar en otro puerto para cada sistema activo al que permite conectarse y mantener la
información relativa a la correspondencia entre sus números de puerto y cada punto final adelantado. El cliente se
configurará con el puerto de proxy adecuado correspondiente a cada sistema activo con el que tenga que
comunicarse. Los puertos de proxy TCP en los que escuchar y sus puntos finales adelantados correspondientes se configuran en
las sentencias
<forward> en el archivo de configuración del proxy,
dir_instalación_QualityServer/httptcp/registration.xml.
En el siguiente ejemplo, 198.51.100.1
es la dirección IP del proxy.
Todo el tráfico enviado al puerto 3333 en el proxy se reenvía al puerto 80 en www.example.com:
<forward bind ="198.51.100.1:3333" destination="www.example.com:80"/>
Por tanto, debe cambiar el archivo de configuración del cliente siempre que añada un nuevo destino para el tráfico del
proxy. Esta restricción no se aplica a los proxies HTTP.
Para comprender cómo se manejan los números de puerto de forma distinta en el proxy HTTP y el proxy TCP, suponga que tiene dos servicios,
uno en 192.0.2.1:8080 y otro en 192.0.2.1:8081, y un proxy que se ejecuta en 198.51.100.1. (Si la diferencia
entre los dos servicios fuera una IP distinta en lugar del número de puerto, este ejemplo sería el
mismo asignando la IP correspondiente a cada servicio). Si estos dos servicios esperan tráfico HTTP, se abre un solo puerto de proxy
HTTP (por ejemplo, 3128) y las solicitudes de ambos puntos finales TCP pueden enviarse a dicho puerto. Cuando el proxy HTTP ve un
mensaje que va dirigido a 192.0.2.1:8080, el proxy lo redirige a dicha dirección o aplica
las reglas que tiene para dicho servicio. El mismo procedimiento se aplica a 192.0.2.1:8081, utilizando el mismo puerto de
proxy.
Si, por el contrario, estos dos servicios esperan tráfico TCP, deben abrirse ambos puertos de proxy definidos por dos
elementos
<forward> en el archivo de configuración:
<forward bind ="198.51.100.1:3333" destination="192.0.2.1:8080"/>
<forward bind ="198.51.100.1:3334" destination="192.0.2.1:8081"/>
La configuración de cliente para el primer servicio cambia
de "192.0.2.1:8080" a "198.51.100.1:3333" y para el segundo servicio de "192.0.2.1:8081" a
"198.51.100.1:3334". El cliente envía un mensaje (paquete TCP) al primer servicio en 198.51.100.1:3333. El proxy lo recibe en dicho puerto (3333),
pero no sabe qué datos se están enviando por dicha conexión TCP. Todo lo que sabe es que la conexión se realizó en
el puerto 3333.
Por tanto, el proxy consulta su configuración y observa que el tráfico con dicho puerto debe reenviarse a
192.0.2.1:8080 (o que debe aplicar una regla para dicho servicio).
Si no puede direccionar todo el tráfico HTTP a través de un servidor proxy porque la configuración del cliente no permite
utilizar la configuración de proxy HTTP, debe utilizar un proxy HTTP inverso. En un proxy HTTP inverso, se cambia el
URL de destino en lugar de configurar un proxy. Este proceso es parecido al de establecer un proxy TCP en cuanto que el proxy
se especifica como el punto final TCP para el mensaje en el sistema cliente y se crea una regla de reenvío en el
proxy. La diferencia es que se añade un atributo
type a la regla que especifica HTTP, como en el ejemplo
siguiente:
<forward bind ="198.51.100.1:3333" destination="192.0.2.1:8080" type="HTTP"/>
Ahora que el servidor proxy está configurado para recibir tráfico HTTP únicamente en el puerto designado (3333 en el ejemplo),
el servidor puede aplicar los filtros avanzados disponibles en el proxy HTTP para los mensajes
que se dirigen a apéndices. Por ejemplo, el servidor puede excluir parte del tráfico que se dirige al
apéndice si no incluye una determinada vía de acceso en su URL, o si no incluye un determinado
método HTTP, como por ejemplo, POST. No obstante, puesto que un apéndice no está siempre en ejecución, el servidor
todavía necesita que el destino del elemento
<forward> puede enviar
tráfico al sistema activo. Por ejemplo, suponga que un cliente necesita conectarse a un servicio en
192.0.2.1:8080 y utiliza un proxy HTTP inverso en 198.51.100.1:3333. Para que el cliente pueda utilizar el proxy,
debe cambiarse la configuración de cliente para dicho servicio, de un URL como http://192.0.2.1:8080/operation a
http://198.51.100.1:3333/operation.
Una solicitud que se envía a este nuevo URL llega al proxy. El mensaje
de solicitud contiene el punto final TCP del proxy (198.51.100.1:3333) en la cabecera "Host" en
lugar de la dirección del sistema activo, ya que el cliente no es consciente de que está enviando
el mensaje a un proxy y no a un servidor normal. Este rol de cliente simplificado define la naturaleza del
proxy inverso. Por ello, el proxy utiliza los elementos
<forward> para saber si una
solicitud que procede del puerto 3333 requiere que se lleve a cabo una de las siguientes acciones:
- La solicitud debe redirigirse al sistema activo en 192.0.2.1:8080 y la cabecera "Host" del mensaje debe
actualizarse para especificar dicho sistema activo.
- Todas las reglas de dicho servicio deben aplicarse al mensaje, como direccionarlo a un apéndice.
En conclusión, debido a su eficacia y facilidad de configuración, utilice el proxy HTTP estándar siempre que sea
posible. Si no lo es, utilice el proxy inverso. Utilice el proxy TCP cuando trabaje con tráfico TCP que no es HTTP.