Я искал кэширующий HTTP-прокси для Linux со следующими свойствами:
Автономный: я бы предпочел не связываться, например, с моей существующей конфигурацией Apache или Squid.
Низкая задержка: то есть он должен пересылать любые данные по мере их извлечения, не дожидаясь, пока весь файл будет загружен сначала. Тем не менее, его общая производительность не вызывает особого беспокойства - обычно у него будет не более одного или двух клиентов, загружающих файлы размером от 1 до 100 МБ.
Кэширование с использованием формата, позволяющего напрямую использовать и/или изменять кэшированные файлы. Например, http://example.com/a/b/file.txt
может быть помещен в <cachedir>/http/example.com/a/b/file.txt
.
(Необязательно) Степень конфигурируемости, чтобы, например, все www*.example.com
URL-адреса отображались в один и тот же каталог, чтобы избежать дублирования зеркал. Программа Python, которую можно немного изменить, также может подойти...
Мне не нужно на самом деле изменять заголовки или содержимое файла — прокси-сервер в основном будет использоваться для обмена файлами обновления программного обеспечения между несколькими виртуальными машинами и физическими машинами без ненужной нагрузки на подключение к Интернету.
должно отвечать всем требованиям, с одной оговоркой.
Автономный: я бы предпочел не связываться, например, с моей существующей конфигурацией Apache или Squid.
Просто установите его (никаких зависимостей, кроме стандартной библиотеки) и настройте по мере необходимости (вы, вероятно, захотите изменить порт, если у вас уже есть Squid, прослушивающий 8123, и вы захотите разрешить клиентам, отличным от localhost . Также с учетом вашего требования вы можете отключить асинхронную запись .
Низкая задержка: то есть он должен пересылать любые данные по мере их извлечения, не дожидаясь, пока весь файл будет загружен сначала. Тем не менее, его общая производительность не вызывает особого беспокойства - обычно у него будет не более одного или двух клиентов, загружающих файлы размером от 1 до 100 МБ.
Проверять. (В отличие от wwwoffle , который мне очень нравится, но систематически буферизует страницы до тех пор, пока они не будут полностью загружены.)
Кэширование с использованием формата, позволяющего напрямую использовать и/или изменять кэшированные файлы. Например,
http://example.com/a/b/file.txt
может быть помещен в<cachedir>/http/example.com/a/b/file.txt
.
Закрывать. Прокси обычно не сохраняются file.txt
в файле с именем, file.txt
потому что URL-адреса не соответствуют синтаксису файла: например, для foo
и foo/
или foo/bar
и можно обслуживать различное содержимое. foo//bar
Polipo хранит по одному файлу на файл, но имя файла представляет собой хэш MD5 URL-адреса (закодированный в Base64) в каталоге с именем, подобным хосту.
Кроме того, содержимое файла включает заголовки. Если вам нужен фактический контент, вам нужно удалить заголовки, например, с помощью sed -e '1,/^\r\?$/d'
.
Я упоминаю Polipo, несмотря на эти ограничения, потому что большинство прокси-серверов, вероятно, будут работать так, если только они не предназначены для использования в ограниченных настройках, где они не могут получить верный доступ ко всем веб-страницам.
(Необязательно) Степень настраиваемости, чтобы, например, все URL-адреса www*.example.com отображались в один и тот же каталог, чтобы избежать дублирования зеркал. Программа Python, которую можно немного изменить, также может подойти...
Выполнимо с перенаправленными URL-адресами .
Я бы поспорил, что именно это существует, но на всякий случай это не так:
CernVM-FS ( docs , github ) интерпретирует фиксированный веб-сайт как файловую систему с долгосрочным кэшированием. Если вы хотите снова получить к нему доступ как к веб-сайту, вы можете запустить локальный HTTP-сервер в этом каталоге.
Это решение не автономное и работает только с одним веб-сайтом, но, возможно, все еще актуально.
ткала