The HTTP protocol runs on top of the TCP protocol, but
provides extra information about the message destination. For that
reason, the two proxies are configured differently.
HTTP traffic includes the destination host and port for the message,
and is sent over a TCP connection to a TCP endpoint,
that is, a specific host and port. Typically, the HTTP message specifies
the same TCP endpoint as the one to which the underlying TCP connection
is made. If you change the client configuration to use an HTTP proxy,
the TCP connection is made to a different host and port than the one
in the HTTP URLs, which means that the TCP endpoint in the message
is different from the endpoint being connected to. For example, if
an HTTP request is sent to http://192.0.2.1:8080/operation, the request
includes "192.0.2.1:8080" in the "Host" header of the HTTP message
that is sent to the TCP port 8080 on host 192.0.2.1.
However, if you configure the HTTP client to use a proxy, the underlying
TCP connection goes to the TCP endpoint for the proxy, while the messages
still contain the original TCP endpoint. For example, if you configure
the client to send its messages to a proxy at 198.51.100.1 port 3128,
and the client sends a request for http://192.0.2.1:8080/operation,
the message still contains "192.0.2.1:8080" in the "Host" header,
and now in the "Request-Line" field also. However, this message is
now sent over a TCP connection to the proxy at 198.51.100.1:3128.
In this way, the HTTP proxy can receive messages on a single port
and can forward those messages to many different services based on
the destination information in the message.
Note: The "Host" header was added in HTTP/1.1. HTTP/1.0 connections
do not include this header. For this reason, HTTP/1.0 connections
that do not pass through a proxy do not include the host and port
for the message. However, HTTP/1.0 messages that are sent to a proxy
still contain the destination host and port in the "Request-Line";
therefore, the absence of a "Host" header does not cause a problem
for proxies.
To enable a TCP proxy, you change the client configuration from
the live system TCP endpoint to the TCP endpoint for the proxy. Unlike
HTTP, TCP does not provide the built-in ability to use a proxy. That
is, if you connect to a proxy through TCP, no mechanism is defined
to communicate the intended final destination to the proxy. The only
way for a TCP proxy to allow connections to multiple live systems
(that is, to final destinations, or
onward endpoints),
without knowing what traffic will be sent over those connections,
is to listen on a different port for each live system it allows connections
to, and to maintain the information about which of its port numbers
corresponds to each onward endpoint. The client is then configured
with the appropriate proxy port corresponding to each live system
that it needs to communicate with. The TCP proxy ports to listen on,
and their corresponding onward endpoints, are configured in
<forward> statements
in the proxy configuration file,
QualityServer_install_dir/httptcp/registration.xml.
In the following example, 198.51.100.1 is the IP address of the proxy.
Any traffic sent to port 3333 on the proxy is forwarded to port 80
at www.example.com:
<forward bind ="198.51.100.1:3333" destination="www.example.com:80"/>
You must therefore change the client configuration file whenever
you add a new destination for proxy traffic. This restriction does
not apply to HTTP proxies.
To understand how port numbers are handled differently in the HTTP
proxy and the TCP proxy, assume that you have two services, one at
192.0.2.1:8080 and one at 192.0.2.1:8081, and a proxy that is running
on 198.51.100.1. (If the two services differed in IP address rather
than in port number, this example would be the same except for the
appropriate IP address for each service.) If these two services expect
HTTP traffic, a single HTTP proxy port (such as 3128) is opened, and
requests for both TCP endpoints can be sent to that port. When the
HTTP proxy sees that a message is addressed to 192.0.2.1:8080, the
proxy either redirects the message to that address or applies any
rules that it has for that service. The same procedure applies to
192.0.2.1:8081, using the same proxy port.
If these two services instead expect TCP traffic, two TCP proxy
ports must be opened, defined by two
<forward> elements
in the configuration file:
<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"/>
The
client configuration for the first service changes from "192.0.2.1:8080"
to "198.51.100.1:3333" and for the second service from "192.0.2.1:8081"
to "198.51.100.1:3334". The client sends a message (TCP packet) to
the first service at 198.51.100.1:3333. The proxy receives it on that
port (3333), but does not know what data is being sent over that TCP
connection. All it knows is that the connection was made to port 3333.
Therefore the proxy consults its configuration and sees that traffic
to that port must be forwarded to 192.0.2.1:8080 (or that a rule for
that service must be applied to it).
If you cannot route all of your HTTP traffic through a proxy server
because the client configuration does not support HTTP proxy configuration,
you must use a reverse HTTP proxy. In a reverse HTTP proxy, you change
the destination URL instead of configuring a proxy. This process is
similar to that for setting up a TCP proxy in that you specify the
proxy as the TCP endpoint for the message in the client system and
create a forwarding rule in the proxy. The difference is that you
add a
type attribute to the rule that specifies HTTP,
as in the following example:
<forward bind ="198.51.100.1:3333" destination="192.0.2.1:8080" type="HTTP"/>
Now that the proxy server is configured to receive only HTTP traffic
on the designated port (3333 in the example), the server can apply
the richer filtering that is available from the HTTP proxy to messages
that are addressed to stubs. For example, the server can filter out
traffic to the stub that does not have a certain path in its URL,
or that does not use a certain HTTP method, such as POST. However,
because a stub is not always running, the server still needs the destination
from the
<forward> element to be able to send
traffic to the live system. For example, assume a client needs to
connect to a service on 192.0.2.1:8080 and uses a reverse HTTP proxy
on 198.51.100.1:3333. Before the client can use the proxy, the client
configuration for that service must be changed from a URL such as
http://192.0.2.1:8080/operation to http://198.51.100.1:3333/operation.
A request that is sent to that new URL reaches the proxy. The request
message contains the TCP endpoint for the proxy (198.51.100.1:3333)
in the "Host" header rather than the address of the live system because
the client is not aware that it is sending the message to a proxy
rather than a normal server. This simplified client role defines the
nature of a reverse proxy. Thus the proxy uses the
<forward> elements
to know that a request that comes in on port 3333 requires one of
the following actions:
- The request must be redirected to the live system at 192.0.2.1:8080,
and the "Host" header in the message must be updated to specify that
live system.
- Any rules for that service must be applied to the message, such
as routing it to a stub instead.
In conclusion, for efficiency and ease of configuration, use the
standard HTTP proxy whenever possible. When you cannot, use the reverse
proxy. Use the TCP proxy when you work with TCP traffic that is not
HTTP.