O protocolo HTTP é executado por cima do protocolo TCP, mas fornece informações extras sobre
o destino da mensagem. Por esse motivo, os dois proxies são configurados de modo diferente.
O tráfego HTTP inclui o host e a porta de destino para a mensagem, e é enviado por uma conexão TCP
com um terminal TCP, ou seja, um host e porta específicos. Geralmente, a mensagem HTTP
especifica o mesmo terminal TCP que aquele com o qual a conexão TCP subjacente é feita. Se você mudar a configuração do cliente para usar um proxy HTTP, a conexão TCP será feita com um
host e porta diferentes daqueles nas URLs HTTP, o que significa que o terminal TCP na
mensagem é diferente do terminal ao qual está sendo conectado. Por exemplo, se uma solicitação de HTTP for enviada
para http://192.0.2.1:8080/operation, a solicitação incluirá "192.0.2.1:8080" no cabeçalho "Host" da
mensagem HTTP que é enviada para a porta TCP 8080 no host 192.0.2.1.
No entanto, se você configurar o cliente HTTP para usar um proxy, a conexão TCP subjacente acessará
o terminal TCP para o proxy, enquanto as mensagens ainda conterão o terminal TCP original. Por
exemplo, se você configurar o cliente para enviar suas mensagens para um proxy em 198.51.100.1, na porta 3128, e
o cliente enviar uma solicitação para http://192.0.2.1:8080/operation, a mensagem ainda conterá
"192.0.2.1:8080" no cabeçalho "Host" e agora no campo "Request-Line" também. No entanto, esta
mensagem agora é enviada sobre uma conexão TCP para o proxy em 198.51.100.1:3128.
Desta maneira, o
proxy HTTP pode receber mensagens em uma única porta e pode encaminhar essas mensagens a vários
serviços diferentes com base nas informações de destino na mensagem.
Nota: O cabeçalho "Host" foi incluído em HTTP/1.1. As conexões HTTP/1.0 não incluem este cabeçalho. Por
este motivo, conexões HTTP/1.0 que não passam por um proxy não incluem o host e a porta
para a mensagem. No entanto, mensagens HTTP/1.0 que são enviadas a um proxy ainda contêm o host e a porta
de destino no "Request-Line"; portanto, a ausência de um cabeçalho "Host" não causa um
problema para proxies.
Para ativar um proxy TCP, você muda a configuração do cliente a partir do terminal TCP do sistema
ativo para o terminal TCP para o proxy. Diferente de HTTP, TCP não fornece a capacidade integrada de usar
um proxy. Ou seja, se você conectar-se a um proxy por meio de TCP, nenhum mecanismo será definido para comunicar o
destino final desejado para o proxy. A única maneira para um proxy TCP permitir conexões com
vários sistemas ativos (ou seja, para destinos finais, ou
terminais avançados), sem
saber qual tráfego será enviado nessas conexões, é atender em uma porta diferente para cada
sistema ativo ao qual ele permite conexões, e para manter as informações sobre quais de seus
números de porta correspondem a cada terminal avançado. O cliente é, então, configurado com a porta de proxy
apropriada correspondente a cada sistema ativo com o qual ele precisa se comunicar. As portas de proxy TCP
nas quais atender, e seus terminais avançados correspondentes, são configurados em
instruções
<forward> no arquivo de configuração de proxy,
RTCP_install_dir/httptcp/registration.xml.
No exemplo
a seguir, 198.51.100.1 é o endereço IP do proxy.
Qualquer tráfego enviado à porta 3333 no proxy é
encaminhado para a porta 80 em
www.example.com:
<forward bind ="198.51.100.1:3333" destination="www.example.com:80"/>
Portanto, você deve mudar o arquivo de configuração do cliente sempre que incluir um novo destino para o
tráfego do proxy. Esta restrição não se aplica aos proxies HTTP.
Para entender como os números de porta são manipulados de modo diferente no proxy HTTP e no proxy TCP,
assuma que você possui dois serviços, um em 192.0.2.1:8080 e um em 192.0.2.1:8081, e um proxy que
está em execução em 198.51.100.1. (Se os dois serviços diferissem no endereço IP em vez de no número da porta,
este exemplo seria igual, exceto pelo endereço IP apropriado para cada serviço.) Se estes dois
serviços esperarem tráfego HTTP, uma única porta de proxy HTTP (tal como 3128) será aberta e solicitações
para ambos os terminais TCP poderão ser enviadas para essa porta. Quando o proxy HTTP vê que uma mensagem foi endereçada para
192.0.2.1:8080, ele redireciona a mensagem para esse endereço ou aplica qualquer regra que ele
possua para esse serviço. O mesmo procedimento se aplica a 192.0.2.1:8081, usando a mesma porta de proxy.
Se estes dois serviços, em vez disso, esperarem o tráfego TCP, duas portas de proxy TCP deverão ser abertas, definidas por
dois elementos
<forward> no arquivo de
configuração:
<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"/>
A
configuração do cliente para o primeiro serviço muda de "192.0.2.1:8080" para "198.51.100.1:3333" e,
para o segundo serviço, de "192.0.2.1:8081" para "198.51.100.1:3334". O cliente envia uma mensagem (pacote
TCP) ao primeiro serviço em 198.51.100.1:3333. O proxy a recebe nessa porta (3333), mas
não sabe quais dados estão sendo enviados por essa conexão TCP. Tudo o que ele sabe é que a conexão
foi feita na porta 3333.
Portanto, o proxy consulta sua configuração e vê que o tráfego para essa
porta deve ser encaminhado para 192.0.2.1:8080 (ou que uma regra para esse serviço deve ser aplicada a ele).
Se não puder rotear todo o seu tráfego HTTP por meio de um servidor proxy porque a configuração do
cliente não suporta configuração de proxy HTTP, você deverá usar um proxy HTTP reverso. Em um
proxy HTTP reverso, você muda a URL de destino em vez de configurar um proxy. Este processo é
semelhante àquele para configurar um proxy TCP pelo fato de que você especifica o proxy como o terminal TCP
para a mensagem no sistema do cliente e cria uma regra de encaminhamento no proxy. A diferença é que você
inclui um atributo
type na regra que especifica HTTP, como no exemplo
a seguir.
<forward bind ="198.51.100.1:3333" destination="192.0.2.1:8080" type="HTTP"/>
Agora que o servidor proxy está configurado para receber somente o tráfego HTTP na porta designada (3333
no exemplo), o servidor pode aplicar a filtragem mais rica que está disponível a partir do proxy HTTP nas
mensagens que são endereçadas aos stubs. Por exemplo, o servidor pode filtrar o tráfego no stub
que não possui um caminho determinado em sua URL ou que não usa um determinado método de HTTP, tal
como POST. No entanto, como um stub nem sempre está em execução, o servidor ainda precisa do destino do
elemento
<forward> para poder enviar o tráfego ao sistema ativo. Por exemplo,
assuma que um cliente precisa se conectar a um serviço em 192.0.2.1:8080 e usa um proxy HTTP reverso
em 198.51.100.1:3333. Antes que o cliente possa usar o proxy, a configuração do cliente para esse serviço
deve ser mudada de uma URL tal como http://192.0.2.1:8080/operation para
http://198.51.100.1:3333/operation.
Uma solicitação que é enviada a essa nova URL atinge o proxy. A
mensagem de solicitação contém o terminal TCP para o proxy (198.51.100.1:3333) no cabeçalho "Host"
em vez do endereço do sistema ativo porque o cliente não está ciente que ele está enviando a
mensagem para um proxy em vez de um servidor normal. Esta função do cliente simplificada define a natureza de um
proxy reverso. Portanto, o proxy usa os elementos
<forward> para saber se uma solicitação
que chega na porta 3333 requer uma das ações a seguir:
- A solicitação deve ser redirecionada para o sistema ativo em 192.0.2.1:8080 e o cabeçalho "Host"
na mensagem deve ser atualizado para especificar esse sistema ativo.
- Quaisquer regras para esse serviço devem ser aplicadas na mensagem, tal como roteá-lo para um stub
em substituição.
Na conclusão, para eficiência e facilidade de configuração, use o proxy HTTP padrão sempre que
possível. Quando não for possível, use o proxy reverso. Use o proxy TCP quando trabalhar com o tráfego TCP
que não é HTTP.