Protokół HTTP działa na podstawie protokołu TCP, ale zawiera dodatkowe informacje o miejscu docelowym komunikatu. Z tego powodu te dwa typy proxy są konfigurowane w odmienny sposób.
Ruch HTTP zawiera docelowy host i port komunikatu. Jest on wysyłany przez połączenie TCP do punktu końcowego TCP, czyli określonego hosta i portu. Zwykle komunikat HTTP jest kierowany do tego samego punktu końcowego TCP, z którym nawiązywane jest bazowe połączenie TCP.
Jeśli konfiguracja klienta zostanie zmieniona w taki sposób, aby używane było proxy HTTP, nawiązywane jest połączenie z innym hostem i portem, niż ten, który znajdują się w adresie URL HTTP, co oznacza, że punkt końcowy TCP określony w komunikacie różni się od punktu końcowego, z którym nawiązano połączenie. Jeśli na przykład żądanie HTTP jest wysyłane na adres http://192.0.2.1:8080/operation, zawiera ono wartość 192.0.2.1:8080 w nagłówku Host komunikatu HTTP, który jest wysyłany na port TCP 8080 i host 192.0.2.1.
Jednak jeśli klient HTTP zostanie skonfigurowany tak, aby używał proxy, bazowe połączenie TCP jest nawiązywane z punktem końcowym TCP proxy, a komunikat nadal zawiera oryginalny punkt końcowy TCP. Jeśli na przykład klient zostanie skonfigurowany do wysyłania komunikatów do proxy o hoście 198.51.100.1 i porcie 3128, a żądanie zostanie wysłane na adres http://192.0.2.1:8080/operation, komunikat będzie zawierał wartość 192.0.2.1:8080 nie tylko w nagłówku Host, ale także w polu Request-Line. Jednak ten komunikat zostanie teraz wysłany przez połączenie TCP do proxy znajdującego się pod adresem 198.51.100.1:3128. W ten sposób proxy HTTP może odbierać komunikaty na pojedynczym porcie i przekazywać je do wielu różnych usług na podstawie informacji o miejscu docelowym zawartych w komunikacie.
Uwaga: Nagłówek Host został dodany w wersji HTTP/1.1. Połączenia HTTP/1.0 nie zawierają tego nagłówka. Z tego powodu połączenia HTTP/1.0, które nie przechodzą przez proxy, nie zawierają hosta i portu komunikatu. Jednak komunikaty HTTP/1.0, które są wysyłane do proxy, nadal zawierają host i port miejsca docelowego w polu Request-Line. Dlatego brak nagłówka Host nie powoduje problemów w przypadku używania proxy.
Aby włączyć proxy TCP, należy zmienić w konfiguracji klienta punkt końcowy TCP aktywnego systemu na punkt końcowy TCP proxy. W przeciwieństwie do protokołu HTTP, protokół TCP nie zawiera wbudowanej możliwości używania proxy. Oznacza to, że jeśli połączenie z proxy zostanie nawiązane za pośrednictwem protokołu TCP, nie zostanie zdefiniowany żaden mechanizm pozwalający na komunikację ostatecznego miejsca docelowego z proxy. Jedyny sposób pozwalający proxy TCP na nawiązywanie połączeń z wieloma aktywnymi systemami (ostatecznymi miejscami docelowymi lub
kolejnymi punktami końcowymi), bez wiedzy o typie ruchu wysyłanym za pośrednictwem tych połączeń, to nasłuchiwanie każdego aktywnego systemu na innym porcie i utrzymywanie informacji o numerze portu, który odpowiada każdemu kolejnemu punktowi końcowemu. W kliencie muszą zostać skonfigurowane porty proxy dla każdego aktywnego systemu, z którym się on komunikuje. Nasłuchiwane porty proxy TCP i odpowiadające im kolejne punkty końcowe są konfigurowane za pomocą instrukcji
<forward> w pliku konfiguracyjnym proxy
katalog_instalacyjny_RTCP/httptcp/registration.xml. W poniższym przykładzie adres IP proxy to 198.51.100.1. Wszelki ruch wysyłany na port 3333 na serwerze proxy jest przekazywany do portu 80 hosta www.przyklad.com:
<forward bind ="198.51.100.1:3333" destination="www.example.com:80"/>
Plik konfiguracyjny klienta należy zmieniać za każdym razem, gdy dodawane jest nowe miejsce docelowe ruchu proxy. To ograniczenie nie dotyczy proxy HTTP.
Aby zrozumieć, czym różni się obsługa numerów portów w przypadku proxy HTTP i proxy TCP, można założyć, że użytkownik korzysta z dwóch usług, jednej pod adresem 192.0.2.1:8080 i drugiej pod adresem 192.0.2.1:8081, a proxy działa pod adresem 198.51.100.1. Jeśli te dwie usługi różniłyby się adresem IP, a nie numerem portu, ten przykład wyglądałby podobnie, z tym że każda usługa miałaby inny adres IP. Jeśli te dwie usługi oczekują ruchu HTTP, otwierany jest pojedynczy port proxy HTTP (np. 3128), na który można wysyłać żądania dla obu punktów końcowych TCP. Jeśli proxy HTTP odbierze informację, że komunikat ma zostać przesłany na adres 192.0.2.1:8080, przekieruje komunikat na ten adres lub zastosuje wszystkie reguły, które dotyczą danej usługi. Ta sama procedura dotyczy adresu 192.0.2.1:8081, przy użyciu tego samego portu proxy.
Jeśli te dwie usługi oczekują ruchu TCP, należy otworzyć dwa porty proxy TCP, definiując je za pomocą dwóch elementów
<forward> w pliku konfiguracyjnym:
<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"/>
Konfiguracja klienta dla pierwszej usługi zmienia się z 192.0.2.1:8080 na 198.51.100.1:3333, a dla drugiej usługi z 192.0.2.1:8081 na 198.51.100.1:3334. Klient wysyła komunikat (pakiet TCP) do pierwszej usługi na adres 198.51.100.1:3333. Proxy odbiera go na porcie 3333, ale nie wiadomo, jakie dane zostały wysyłane za pośrednictwem tego połączenia TCP. Wiadomo jedynie, że połączenie zostało nawiązane z portem 3333. Oznacza to, że proxy sprawdza swoją konfigurację i przekazuje ruch do tego portu na adres 192.0.2.1:8080 (lub stosuje regułę dla tej usługi).
Jeśli nie można skierować całego ruchu HTTP przez serwer proxy, ponieważ konfiguracja klienta nie obsługuje konfiguracji proxy HTTP, należy użyć odwrotnego proxy HTTP. W przypadku odwrotnego proxy HTTP należy zmienić adres URL miejsca docelowego zamiast konfigurowania proxy. Ten proces jest podobny do procesu przeprowadzanego w celu skonfigurowania proxy TCP. Należy określić proxy jako punkt końcowy TCP dla komunikatu w systemie klienta i utworzyć regułę przekazywania na serwerze proxy. Różnica polega na tym, że należy dodać do reguły atrybut
type o wartości HTTP, tak jak w następującym przykładzie:
<forward bind ="198.51.100.1:3333" destination="192.0.2.1:8080" type="HTTP"/>
Teraz, gdy serwer proxy został skonfigurowany do odbierania wyłącznie ruchu HTTP na określonym porcie (w przykładzie jest to port 3333), serwer może zastosować bogatszą funkcjonalność filtrowania, która jest dostępna na serwerze proxy HTTP dla komunikatów, które są adresowane do kodów pośredniczących. Na przykład serwer może filtrować ruch do kodu pośredniczącego, który nie zawiera konkretnej ścieżki w swoim adresie URL lub który nie używa określonej metody HTTP, takiej jak POST. Ponieważ jednak kod pośredniczący nie zawsze działa, serwer nadal potrzebuje miejsca docelowego określonego w elemencie
<forward> do przesłania ruchu do aktywnego systemu. Na przykład można założyć, że klient musi nawiązać połączenie z usługą pod adresem 192.0.2.1:8080 i używa odwrotnego proxy HTTP pod adresem 198.51.100.1:3333. Aby klient mógł używać proxy, konfiguracja klienta dla tej usługi musi zostać zmieniona z adresu URL, takiego jak http://192.0.2.1:8080/operation, na http://198.51.100.1:3333/operation. Żądanie, które jest wysyłane na ten nowy adres URL, jest odbierane przez proxy. Komunikat żądania zawiera punkt końcowy TCP dla proxy (198.51.100.1:3333) w nagłówku Host zamiast adresu aktywnego systemu, ponieważ klient nie wie, że wysyła komunikat do serwera proxy, a nie do normalnego serwera. Ta uproszczona rola klienta definiuje naturę odwrotnego proxy. W związku z tym proxy używa elementów
<forward>, aby stwierdzić, że żądanie przychodzące na porcie 3333 wymaga wykonania jednej z następujących czynności:
- Żądanie musi zostać przekierowywane do aktywnego systemu pod adresem 192.0.2.1:8080, a nagłówek Host w komunikacie musi zostać zaktualizowany, aby określić ten aktywny system.
- Należy zastosować do komunikatu wszystkie reguły danej usługi, takie jak na przykład skierowanie komunikatu do kodu pośredniczącego.
Podsumowując, ze względu na efektywność i łatwość konfiguracji należy używać standardowego proxy HTTP, jeśli tylko jest to możliwe. W przeciwnym razie można użyć odwrotnego proxy. Proxy TCP należy używać w przypadku pracy z ruchem TCP, który nie jest ruchem HTTP.