Зачастую у людей возникают проблемы с понимаем принципа акселерирования и и кешируюего проксирования, которые обычно связаны с путаницей в определениях "входящих" и ``исходящих" данных. Я имею ввиду определение запросов (т.е. исходящий запрос от локального сайта в большой плохой Интернет). Данные, полученные в ответ естественно являются входящими. Другие подразумевают обратное ``запрос для входящих данных".
An accelerator caches incoming requests for outgoing data (i.e., that which you publish to the world). It takes load away from your HTTP server and internal network. You move the server away from port 80 (or whatever your published port is), and substitute the accelerator, which then pulls the HTTP data from the ``real" HTTP server (only the accelerator needs to know where the real server is). The outside world sees no difference (apart from an increase in speed, with luck).
Quite apart from taking the load of a site's normal web server, accelerators can also sit outside firewalls or other network bottlenecks and talk to HTTP servers inside, reducing traffic across the bottleneck and simplifying the configuration. Two or more accelerators communicating via ICP can increase the speed and resilience of a web service to any single failure.
The Squid redirector can make one accelerator act as a single front-end for multiple servers. If you need to move parts of your filesystem from one server to another, or if separately administered HTTP servers should logically appear under a single URL hierarchy, the accelerator makes the right thing happen.
If you wish only to cache the ``rest of the world" to improve local users browsing performance, then accelerator mode is irrelevant. Sites which own and publish a URL hierarchy use an accelerator to improve other sites' access to it. Sites wishing to improve their local users' access to other sites' URLs use proxy caches. Many sites, like us, do both and hence run both.
Measurement of the Squid cache and its Harvest counterpart suggest an order of magnitude performance improvement over CERN or other widely available caching software. This order of magnitude performance improvement on hits suggests that the cache can serve as an httpd accelerator, a cache configured to act as a site's primary httpd server (on port 80), forwarding references that miss to the site's real httpd (on port 81).
In such a configuration, the web administrator renames all non-cachable URLs to the httpd's port (81). The cache serves references to cachable objects, such as HTML pages and GIFs, and the true httpd (on port 81) serves references to non-cachable objects, such as queries and cgi-bin programs. If a site's usage characteristics tend toward cachable objects, this configuration can dramatically reduce the site's web workload.
Заметьте, что лучше не запускать один процесс squid и как
httpd-акселератор и как проксирующий кеш, т.к. эти два режима будут иметь
различные рабочие установки. Вы получите лучшую производительность,
запустив два отдельных кеша на разных машинах. However, for
compatability with how administrators are accustomed to running
other servers that provide both proxy and Web serving capability
(eg, CERN), Squid поддерживает supports operation as both a proxy and
an accelerator, if you set the httpd_accel_with_proxy
variable to on inside your squid.conf
configuration file.
Прежде всего вам необходимо заставить Squid прослушивать 80-й порт (как правило), установив опцию 'http_port':
http_port 80
Далее вам необходимо переместить ваш обычный HTTP-сервер на другой порт и/или на другую машину. Если вы хотите запустить ваш HTTP-сервер на той же машине, то он не должен использовать порт 80 (исключением является описанное ниже). Обычно выбирается порт 81. Настройте squid следующим образом:
httpd_accel_host localhost
httpd_accel_port 81
Другой вариант - перенести HTTP-сервер на другую машину, оставив его на 80-м порту:
httpd_accel_host otherhost.foo.com
httpd_accel_port 80
Теперь вам необходимо запустить Squid и он будет обрабатывать запросы как HTTP-сервер.
Если вы используете Squid как акселератор для системы с виртуальными хостами, то вам необходимо указать
httpd_accel_host virtual
И наконец, если вы хотите, чтобы Squid принимал и proxy-запросы (подобно тому как кон работал то того, как вы сделали его акселератором), то вам необходимо включить опцию:
httpd_accel_with_proxy on
Скорее всего вы запустили ваш реальный httpd на порту 81. Когда ваш httpd-сервер исползует сообщения пренаправления (типа 302 Moved Temporarily), он знает, что запущен на нестандартном порту ( не 80-м), поэтому вставляет :81 в перенаправленный URL. Далее, когда клиент запрашивает перенаправленный URL, то запрос проходит через акселератор.
Как мне это исправить?
Один из путей - оставить ваш httpd-сервер на 80-м порту 80, но привязать httpd-сокет к специфическому интерфейсу, а именно к интерфейсу обратной петли. Для Apache вы можете сделать это, указав в файле httpd.conf следующее:
Port 80
BindAddress 127.0.0.1
Далее в вашем squid.conf вы должны указать адрес интерфейса обратной
петли как акселератор:
httpd_accel_host 127.0.0.1
httpd_accel_port 80
Заметьте, что вам возмжоно тажке необходимо добавить имя вашего хоста для адреса 127.0.0.1 в /etc/hosts. В противном случае Squid may get stuck in a forwarding loop.