HTTP 协议在 TCP 协议之上运行，但提供关于消息目标的额外信息。出于该原因，两个代理的配置方式不同。
HTTP 流量包含消息的目标主机和端口，并将通过 TCP 连接发送到 TCP 端点，即特定主机和端口。通常，HTTP 消息指定与底层 TCP 连接所用相同的 TCP 端点。 如果更改客户机配置以使用 HTTP 代理，将建立与 HTTP URL 中的主机和端口不同的其他主机和端口的 TCP 连接，这意味着消息中的 TCP 端点与正在连接到的端点不同。例如，如果将 HTTP 请求发送到 http://192.0.2.1:8080/operation，那么请求在发送到主机 192.0.2.1 上 TCP 端口 8080 的 HTTP 消息的“Host”头中包含“192.0.2.1:8080”。
但是，如果您将 HTTP 客户机配置为使用代理，那么底层 TCP 连接将转至代理的 TCP 端点，而消息仍将包含原始 TCP 端点。例如，如果配置客户机将其消息发送到位于 198.51.100.1 端口 3128 上的代理，而且客户机发送针对 http://192.0.2.1:8080/operation 的请求，那么消息仍将在“Host”头中以及在“Request-Line”字段中包含“192.0.2.1:8080”。但是，该消息现在通过 TCP 连接发送到位于 198.51.100.1:3128 的代理。这样一来，HTTP 代理可接收单个端口上的消息，并可根据消息中的目标信息将这些消息转发到多个不同服务。
注： HTTP/1.1 中添加了“Host”头。HTTP/1.0 连接不包含该头。出于该原因，不通过代理传递的 HTTP/1.0 连接不包含消息的主机和端口。但是，发送到代理的 HTTP/1.0 消息仍在“Request-Line”中包含目标主机和端口；因此，缺少“Host”头不会导致代理出现问题。
要启用 TCP 代理，请将客户机配置从实时系统 TCP 端点更改为代理的 TCP 端点。与 HTTP 不同，TCP 不提供内置功能来使用代理。即，如果您通过 TCP 连接到代理，那么不会定义任何机制来向代理传达预期的最终目标。要使 TCP 代理允许连接到多个实时系统（即最终目标或
前向端点），在不知道将通过这些连接发送哪些流量的情况下，唯一方法是在该代理允许连接到的每个实时系统的不同端口上侦听，并维护其对应于各前向端点的相关端口号信息。然后，为客户机配置适当的代理端口，以对应于需要与之进行通信的每个实时系统。要侦听的 TCP 代理端口及其对应前向端点在代理配置文件
RTCP_install_dir/httptcp/registration.xml 的
<forward> 语句中配置。在以下示例中，198.51.100.1 是代理的 IP 地址。发送到代理上端口 3333 的任何流量都将转发到 www.example.com 上的端口 80：
<forward bind ="198.51.100.1:3333" destination="www.example.com:80"/>
因此，每当您为代理流量添加新目标时都必须更改客户机配置文件。该限制不适用于 HTTP 代理。
要了解在 HTTP 代理和 TCP 代理中如何以不同方式处理端口号，假定您有两个服务（一个服务位于 192.0.2.1:8080，另一个服务位于 192.0.2.1:8081），并有一个在 198.51.100.1 上运行的代理。（如果两个服务的 IP 地址不同而不是端口号不同，那么该示例应相同，但每个服务的相应 IP 地址不同。）如果这两个服务期望 HTTP 流量，那么将打开单个 HTTP 代理端口（例如 3128），并可将针对两个 TCP 端点的请求发送到该端口。当 HTTP 代理看到消息发往 192.0.2.1:8080 时，会将消息重定向到该地址，或应用针对该服务的任何规则。相同过程适用于 192.0.2.1:8081，并使用相同代理端口。
如果这两个服务转而期望 TCP 流量，那么必须打开两个 TCP 代理端口，由配置文件中的两个
<forward> 元素定义：
<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"/>
第一个服务的客户机配置从“192.0.2.1:8080”更改为“198.51.100.1:3333”，第二个服务的配置从“192.0.2.1:8081”更改为“198.51.100.1:3334”。客户机将消息（TCP 包）发送到位于 198.51.100.1:3333 的第一个服务。代理在该端口 (3333) 上接收消息，但不知道通过该 TCP 连接发送的数据的内容。它只知道建立了与端口 3333 的连接。因此，代理将查询其配置，发现发送到该端口的流量必须转发到 192.0.2.1:8080（或者必须向其应用针对该服务的规则）。
如果因为客户机配置不支持 HTTP 代理配置而无法通过代理服务器路由所有 HTTP 流量，必须使用逆向 HTTP 代理。在逆向 HTTP 代理中，您需要更改目标 URL 而不是配置代理。该过程与设置 TCP 代理的过程类似之处在于，您指定代理作为客户机系统中消息的 TCP 端点，并在代理中创建转发规则。区别在于您向规则添加了指定 HTTP 的
type 属性，如以下示例中所示：
<forward bind ="198.51.100.1:3333" destination="192.0.2.1:8080" type="HTTP"/>
既然代理服务器已配置为在指定端口（本示例中为 3333）上仅接收 HTTP 流量，服务器可向发往存根的消息应用 HTTP 代理中提供的更丰富的过滤功能。例如，服务器可过滤掉针对其 URL 中没有特定路径或不使用特定 HTTP 方法（例如 POST）的存根的流量。但是，因为存根并非会始终运行，服务器仍需要来自
<forward> 元素的目标才能将流量发送到实时系统。例如，假定客户机需要连接到 192.0.2.1:8080 上的服务并使用 198.51.100.1:3333 上的逆向 HTTP 代理。该服务的客户机配置必须变更其 URL（例如从 http://192.0.2.1:8080/operation 改为 http://198.51.100.1:3333/operation），客户机才能使用代理。发送到这一新 URL 的请求将到达代理。请求消息在“Host”头中包含的是代理 (198.51.100.1:3333) 的 TCP 端点而不是实时系统的地址，因为客户机不知道它是将消息发送到代理而不是普通服务器。这个简化的客户机角色定义逆向代理的本质。因此，代理使用
<forward> 元素来了解端口 3333 上进入的请求需要以下某个操作：
- 请求必须重定向到位于 192.0.2.1:8080 的实时系统，并且消息中的“Host”头必须更新以指定该实时系统。
- 该服务的任何规则必须应用于该消息，例如将其转而路由至存根。
综上所述，要实现配置的高效性和易用性，请尽可能使用标准 HTTP 代理。如果无法使用标准 HTTP 代理，请使用逆向代理。当您处理非 HTTP 的 TCP 流量时，请使用 TCP 代理。
