|
1 | 1 | --- |
2 | 2 | FaqSection: operation |
3 | 3 | --- |
4 | | -# Reverse Proxy Mode |
| 4 | +# Reverse Proxy |
5 | 5 |
|
6 | | -## What is the Reverse Proxy (httpd-accelerator) mode? |
| 6 | + * ## What is a Reverse Proxy? |
| 7 | + * ## What is the Reverse Proxy Mode? |
| 8 | + * ## What is the `httpd-accelerator` mode? (in Squid v2) |
| 9 | + * ## What is the Accelerator (`accel`) mode? (in Squid v3-v6) |
7 | 10 |
|
8 | | -Occasionally people have trouble understanding accelerators and proxy |
9 | | -caches, usually resulting from mixed up interpretations of "incoming" |
10 | | -and "outgoing" data. I think in terms of requests (i.e., an outgoing |
11 | | -request is from the local site out to the big bad Internet). The data |
12 | | -received in reply is incoming, of course. Others think in the opposite |
13 | | -sense of "a request for incoming data". |
14 | | - |
15 | | -An accelerator caches incoming requests for outgoing data (i.e., that |
16 | | -which you publish to the world). It takes load away from your HTTP |
17 | | -server and internal network. You move the server away from port 80 (or |
18 | | -whatever your published port is), and substitute the accelerator, which |
19 | | -then pulls the HTTP data from the "real" HTTP server (only the |
20 | | -accelerator needs to know where the real server is). The outside world |
21 | | -sees no difference (apart from an increase in speed, with luck). |
22 | | - |
23 | | -Quite apart from taking the load of a site's normal web server, |
24 | | -accelerators can also sit outside firewalls or other network bottlenecks |
25 | | -and talk to HTTP servers inside, reducing traffic across the bottleneck |
26 | | -and simplifying the configuration. Two or more accelerators |
27 | | -communicating via ICP can increase the speed and resilience of a web |
28 | | -service to any single failure. |
29 | | - |
30 | | -The Squid redirector can make one accelerator act as a single front-end |
31 | | -for multiple servers. If you need to move parts of your filesystem from |
32 | | -one server to another, or if separately administered HTTP servers should |
33 | | -logically appear under a single URL hierarchy, the accelerator makes the |
34 | | -right thing happen. |
35 | | - |
36 | | -If you wish only to cache the "rest of the world" to improve local users |
37 | | -browsing performance, then accelerator mode is irrelevant. Sites which |
38 | | -own and publish a URL hierarchy use an accelerator to improve access to |
39 | | -it from the Internet. Sites wishing to improve their local users' access |
40 | | -to other sites' URLs use proxy caches. Many sites, like us, do both and |
41 | | -hence run both. |
42 | | - |
43 | | -Measurement of the Squid cache and its Harvest counterpart suggest an |
44 | | -order of magnitude performance improvement over CERN or other widely |
45 | | -available caching software. This order of magnitude performance |
46 | | -improvement on hits suggests that the cache can serve as an httpd |
47 | | -accelerator, a cache configured to act as a site's primary httpd server |
48 | | -(on port 80), forwarding references that miss to the site's real httpd |
49 | | -(on port 81). |
50 | | - |
51 | | -In such a configuration, the web administrator renames all non-cachable |
52 | | -URLs to the httpd's port (81). The cache serves references to cachable |
53 | | -objects, such as HTML pages and GIFs, and the true httpd (on port 81) |
54 | | -serves references to non-cachable objects, such as queries and cgi-bin |
55 | | -programs. If a site's usage characteristics tend toward cachable |
56 | | -objects, this configuration can dramatically reduce the site's web |
57 | | -workload. |
58 | | - |
59 | | -## How do I set it up? |
60 | | - |
61 | | -Several configurations are possible. The |
62 | | -[ConfigExamples](/ConfigExamples) |
63 | | -section details several variations of Reverse Proxy. |
64 | | - |
65 | | -{% include pages-list-by-path.html dir="/ConfigExamples/Reverse"%} |
66 | | - |
67 | | -## Running the web server on the same server |
68 | | - |
69 | | -While not generally recommended it is possible to run both the |
70 | | -accelerator and the backend web server on the same host. To do this you |
71 | | -need to make them listen on different IP addresses. Usually the loopback |
72 | | -address (127.0.0.1 or ::1) is used for the web server. |
73 | | - |
74 | | -In Squid this is done by specifying the public IP address in |
75 | | -[http_port](http://www.squid-cache.org/Doc/config/http_port), and |
76 | | -using loopback address for the web server |
77 | | - |
78 | | - http_port the.public.ip.address:80 accel defaultsite=your.main.website |
79 | | - cache_peer 127.0.0.1 parent 80 0 no-query originserver |
80 | | - |
81 | | -And [Apache](http://www.apache.org/) may be configured like in |
82 | | -*httpd.conf*to listen on the loopback address: |
83 | | - |
84 | | - Port 80 |
85 | | - BindAddress 127.0.0.1 |
86 | | - |
87 | | -Other web servers uses similar directives specifying the address where |
88 | | -it should listen for requests. See the manual to your web server for |
89 | | -details. |
90 | | - |
91 | | -## Load balancing of backend servers |
92 | | - |
93 | | -To load balance requests among a set of backend servers allow requests |
94 | | -to be forwarded to more than one |
95 | | -[cache_peer](http://www.squid-cache.org/Doc/config/cache_peer), and |
96 | | -use one of the load balancing options in the |
97 | | -[cache_peer](http://www.squid-cache.org/Doc/config/cache_peer) lines. |
98 | | -I.e. the round-robin option. |
99 | | - |
100 | | - cache_peer ip.of.server1 parent 80 0 no-query originserver round-robin |
101 | | - cache_peer ip.of.server2 parent 80 0 no-query originserver round-robin |
102 | | - |
103 | | -Other load balancing methods is also available. See squid.conf.default |
104 | | -for the full the description of the |
105 | | -[cache_peer](http://www.squid-cache.org/Doc/config/cache_peer) |
106 | | -directive options. |
107 | | - |
108 | | -## Common Problems |
109 | | - |
110 | | -### When using an httpd-accelerator, the port number or host name for redirects or CGI-generated content is wrong |
111 | | - |
112 | | -This happens if the port or domain name of the accelerated content is |
113 | | -different from what the client requested. When your httpd issues a |
114 | | -redirect message (e.g. 302 Moved Temporarily) or generates absolute |
115 | | -URLs, it only knows the port it's configured on and uses this to build |
116 | | -the URL. Then, when the client requests the redirected URL, it bypasses |
117 | | -the accelerator. |
118 | | - |
119 | | -To fix this make sure that defaultsite is the site name requested by |
120 | | -clients, and that the port number of |
121 | | -[http_port](http://www.squid-cache.org/Doc/config/http_port) and the |
122 | | -backent web server is the same. You may also need to configure the |
123 | | -official site name on the web server. |
124 | | - |
125 | | -Alternatively you can also use the location_rewrite helper interface to |
126 | | -Squid to fixup redirects on the way out to the client, but this only |
127 | | -works for the Location header, not URLs dynamically embedded in the |
128 | | -returned content. |
129 | | - |
130 | | -### Access to password protected content fails via the reverse proxy |
131 | | - |
132 | | -If the content on the web servers is password protected then you need to |
133 | | -tell the proxy to trust your web server with authentication credentials. |
134 | | -This is done via the login= option to |
135 | | -[cache_peer](http://www.squid-cache.org/Doc/config/cache_peer). |
136 | | -Normally you would use login=PASS to have the login information |
137 | | -forwarded. The other alternatives is meant to be used when it's the |
138 | | -reverse proxy which processes the authentication as such but you like to |
139 | | -have information about the authenticated account forwarded to the |
140 | | -backend web server. |
141 | | - |
142 | | - cache_peer ip.of.server parent 80 0 no-query originserver login=PASS |
143 | | - |
144 | | -> :information_source: |
145 | | - To pass details back as given **login=PASS** is an exact string |
146 | | - |
147 | | -### Visitor requests can force fetching new objects from the back-end server |
148 | | - |
149 | | -Client requests can contain *Cache-Control:* settings specifying |
150 | | -no-cache, must-revalidate, or low max-age which cause Squid to |
151 | | -revalidate or fetch new content from the backend web server rather |
152 | | -earlier than needed. This raises load on the delivery system which can |
153 | | -lead to bandwidth problems and rising costs. |
154 | | - |
155 | | -In [Squid-3.1](/Releases/Squid-3.1) |
156 | | -and later the [http_port](http://www.squid-cache.org/Doc/config/http_port) |
157 | | -**ignore-cc** options is available on accel ports. This option informs |
158 | | -Squid to ignore the visitors control headers and depend solely on the |
159 | | -headers provided by backend servers. |
160 | | - |
161 | | - http_port 80 accel ignore-cc |
| 11 | +The terms **Accelerator Proxy**, **httpd-accelerator**, and **Reverse Proxy** |
| 12 | +were all used in the past to describe what the HTTP Standard now officially |
| 13 | +defines as a [**Gateway Proxy**](GatewayProxy). |
0 commit comments