From 22694c46f2ca1c5e6b4b1787fc4d9667c62a3ce9 Mon Sep 17 00:00:00 2001 From: Jim Jagielski Date: Wed, 10 Feb 2016 19:46:10 +0000 Subject: [PATCH] xform git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1729703 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/howto/reverse_proxy.html.en | 213 ++++++++++++++++++------ 1 file changed, 163 insertions(+), 50 deletions(-) diff --git a/docs/manual/howto/reverse_proxy.html.en b/docs/manual/howto/reverse_proxy.html.en index 99df1762a4..b788095bbb 100644 --- a/docs/manual/howto/reverse_proxy.html.en +++ b/docs/manual/howto/reverse_proxy.html.en @@ -30,72 +30,185 @@  tr 

-

In addition to being a "basic" web server, and providing static and - dynamic content to end-users, Apache httpd (as well as most other web - servers) can also act as a reverse proxy server, also-known-as a - "gateway" server.

- -

In such scenarios, httpd itself does not generate or host the data, - but rather the content is obtained by one or several backend servers, - which normally have no direct connection to the external network. As - httpd receives a request from a client, the request itself is proxied - to one of these backend servers, which then handles the request, generates - the content and then sends this content back to httpd, which then - generates the actual HTTP response back to the client.

- -

There are numerous reasons for such an implementation, but generally - the typical rationales are due to security, high-availability, load-balancing - and centralized authentication/authorization. It is critical in these - implementations that the layout, design and architecture of the backend - infrastructure (those servers which actually handle the requests) are - insulated and protected from the outside; as far as the client is concerned, - the reverse proxy server is the sole source of all content.

- -

A typical implementation is below:

-

reverse-proxy-arch

- - +

In addition to being a "basic" web server, and providing static and + dynamic content to end-users, Apache httpd (as well as most other web + servers) can also act as a reverse proxy server, also-known-as a + "gateway" server.

+ +

In such scenarios, httpd itself does not generate or host the data, + but rather the content is obtained by one or several backend servers, + which normally have no direct connection to the external network. As + httpd receives a request from a client, the request itself is proxied + to one of these backend servers, which then handles the request, generates + the content and then sends this content back to httpd, which then + generates the actual HTTP response back to the client.

+ +

There are numerous reasons for such an implementation, but generally + the typical rationales are due to security, high-availability, load-balancing + and centralized authentication/authorization. It is critical in these + implementations that the layout, design and architecture of the backend + infrastructure (those servers which actually handle the requests) are + insulated and protected from the outside; as far as the client is concerned, + the reverse proxy server is the sole source of all content.

+ +

A typical implementation is below:

+

reverse-proxy-arch

+ +
top

Reverse Proxy

- -
Related ModulesRelated Directives
-
top
+ +
Related ModulesRelated Directives
+
top
-

Simple reverse proxying

- +

Simple reverse proxying

+ + +

+ The ProxyPass + directive specifies the mapping of incoming requests to the backend + server (or a cluster of servers known as a Balancer + group). The simpliest example proxies all requests ("/") + to a single backend: +

+ + 
ProxyPass "/"  "http://www.example.com"
+ -

The ProxyPass - directive specifies the mapping of incoming requests to the backend - server (or a cluster of servers known as a Balancer - group). The simpliest example proxies all requests ("/") - to a single backend:

+

+ To ensure that and Location: headers generated from + the backend are modified to point to the reverse proxy, instead of + back to itself, the ProxyPassReverse + directive is most often required: +

- 
ProxyPass "/"  "http://www.example.com"
+ 
      ProxyPass "/"  "http://www.example.com"
+      ProxyPassReverse "/"  "http://www.example.com"
+ + +

Only specific URIs can be proxied, as shown in this example:

+ + 
      ProxyPass "/images"  "http://www.example.com"
+      ProxyPassReverse "/images"  "http://www.example.com"
+ + +

In the above, any requests which start with the /images + path with be proxied to the specified backend, otherwise it will be handled + locally. +

+
top
+
+

Clusters and Balancers

+ +

+ As useful as the above is, it still has the deficiencies that should + the (single) backend node go down, or become heavily loaded, that proxying + those requests provides no real advantage. What is needed is the ability + to define a set or group of backend servers which can handle such + requests and for the reverse proxy to load balance and failover among + them. This group is sometimes called a cluster but Apache httpd's + term is a balancer. One defines a balancer by leveraging the + Proxy and + BalancerMember directives as + shown: +

-

To ensure that and Location: headers generated from - the backend are modified to point to the reverse proxy, instead of - back to itself, the ProxyPassReverse - directive is most often required:

+ 
      <Proxy balancer://myset>
+        BalancerMember http://www2.example.com:8080
+        BalancerMember http://www3.example.com:8080
+        ProxySet lbmethod=bytraffic
+      </Proxy>
+
+      ProxyPass "/images"  "balancer://myset"
+      ProxyPassReverse "/images"  "balancer://myset"
+ + +

+ The balancer:// scheme is what tells httpd that we are creating + a balancer set, with the name myset. It includes 2 backend servers, + which httpd calls BalancerMembers. In this case, any requests for + /images will be proxied to one of the 2 backends. + The ProxySet directive + specifies that the myset Balancer use a load balancing algorithm + that balances based on I/O bytes. +

+ +

Hint

+

+ BalancerMembers are also sometimes referred to as workers. +

+
+ +
top
+
+

Balancer and BalancerMember configuration

+ + +

+ You can adjust numerous configuration details of the balancers + and the workers via the various parameters defined in + ProxyPass. For example, + assuming we would want http://www3.example.com:8080 to + handle 3x the traffic with a timeout of 1 second, we would adjust the + configuration as follows: +

+ + 
      <Proxy balancer://myset>
+        BalancerMember http://www2.example.com:8080
+        BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+        ProxySet lbmethod=bytraffic
+      </Proxy>
+
+      ProxyPass "/images"  "balancer://myset"
+      ProxyPassReverse "/images"  "balancer://myset"
+ + +
top
+
+

Failover

+ - 
		ProxyPass "/"  "http://www.example.com"
-		ProxyPassReverse "/"  "http://www.example.com"
+

+ You can also fine-tune various failover scenarios, detailing which + workers and even which balancers should accessed in such cases. For + example, the below setup implements 2 failover cases: In the first, + http://hstandby.example.com:8080 is only sent traffic + if all other workers in the myset balancer are not available. + If that worker itself is not available, only then will the + http://bkup1.example.com:8080 and http://bkup2.example.com:8080 + workers be brought into rotation: +

+ 
      <Proxy balancer://myset>
+        BalancerMember http://www2.example.com:8080
+        BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+        BalancerMember http://hstandby.example.com:8080 status=+H
+        BalancerMember http://bkup1.example.com:8080 lbset=1
+        BalancerMember http://bkup2.example.com:8080 lbset=1
+        ProxySet lbmethod=byrequests
+      </Proxy>
 
-		
Only specific URIs can be proxied, as shown in this example:

+      ProxyPass "/images"  "balancer://myset"
+      ProxyPassReverse "/images"  "balancer://myset"
- 
		ProxyPass "/images"  "http://www.example.com"
-		ProxyPassReverse "/images"  "http://www.example.com"
+

+ The magic of this failover setup is setting http://hstandby.example.com:8080 + with the +H status flag, which puts it in hot standby mode, + and making the 2 bkup# servers part of the #1 load balancer set (the + default set is 0); for failover, hot standbys (if they exist) are used 1st, when all regular + workers are unavailable; load balancer sets are always tried lowest number first. +

-

In the above, any requests which start with the /images - path with be proxied to the specified backend, otherwise it will be handled - locally.

-
+

Available Languages:  en  |  fr  | -- 2.40.0