Последнее изменение файла: 2017.08.30
Скопировано с www.bog.pp.ru: 2024.04.24

Bog BOS: HTTP proxy/кеш

HTTP proxy (посредник) - программа, выполняющая HTTP-запросы от имени клиентской программы. Используется при необходимости доступа к Интернет из-за firewall. Кеш - средство ускорения доступа за счет локального хранения часто используемых данных. Локальный HTTP кеш встраивается в броузер. Кеширующий HTTP proxy - программа, позволяющая ускорить доступ к WWW и FTP сайтам за счет кеширования данных, запрошенных различными клиентами в одном месте; для общения с броузером использует протокол, предназначенный для proxy. Может также использоваться для прокси без кеширования.

Используется для:

• уменьшения времени доступа к сайтам (среднее время доступа при попадании в кеш - 0.04 сек.; при промахе - 1.7 сек.)
• уменьшения нагрузки на канал связи (удешевления доступа: HTTP-пакеты составляют 70-80% трафика и кешируются процентов на 20)
• выхода за firewall
• уменьшения нагрузки на http-сервер (при работе в обратном режиме)

Иерархия кеш-серверов. Клиент может обращаться не к одному кешу, а к нескольким серверам, образующим целую иерархию. Связи в иерархии: сосед и родитель. Если документа нет в кеше, он может запросить о наличии у соседей (через ICP, запрос делается в параллель через UDP, кто раньше ответит, тот считается самым быстрым, данный алгоритм обеспечивает автомадический поиск и балансировку загрузки). Если ни у кого из соседей нет, то выдается запрос к родительскому кешу. При запросах могут использоваться URL-шаблоны для выбора предпочтительного пути или некешируемых документов.

• RFC 2187 Application of Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997
• RFC 2186 Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997

• Squid, freeware, развитие Harvest, используется в большинстве случаев
• apache имеет встроенный модуль кеш-сервера, freeware, не так эффективен как специализированная система
• OOPS
• IETF-RD: harvest 1.4pl3, закрыт в 1996, freeware, эффективен
• Harvest 2, коммерческое развитие
• W3C: CERN proxy/server, поддерживаемые протоколы: HTTP, FTP, gopher, WAIS, не развивается с 1996, не эффективен, freeware
• W3C: Jigsaw (на Java), freeware
• Spinner

1. на подходящий (доступный клиентам напрямую) web-сервер положить PAC файл (Proxy Auto-configuration file), который описывает настройки прокси сервера на языке типа JavaScript (имя сервера должно быть "wpad", имя файла - "/wpad.dat"; некоторые клиенты пытаются получать файл "/WPAD.DAT")
2. определить в описании DNS домена по умолчанию адрес или CNAME для имени wpad; некоторые клиенты (Windows-Update-Agent) получают IP адрес из имени и используют этот IP адрес в качестве имени сервера
3. настроить браузер на автоматическое определение настроек прокси (возможно, что придётся что-нибудь перезапустить или перезагрузить, чтобы очистить кеш):
   • Firefox 2.0: настройки, дополнительно, сеть, соединение, автоматически
   • Firefox 1.5: правка, настройки, основные, параметры соединения, автоматическое определение настроек
   • IE 6.0: сервис, свойства, подключениея, настройка LAN, автоматическое определение параметров

Пример PAC файла:

function FindProxyForURL(url, host)
{
     if (
// приводит к DNS-запросам о целевом домене
          isInNet(host, "10.0.0.0", "255.0.0.0") ||
          isInNet(host, "172.16.0.0", "255.240.0.0") ||
          isInNet(host, "192.168.0.0", "255.255.0.0") ||
          isPlainHostName(host) ||
          localHostOrDomainIs(host, "127.0.0.1") ||
          dnsDomainIs(host, ".company.ru")
       )
         return "DIRECT";
     else if (
// приводит к DNS запросам для определения своего адреса
          isInNet(myIpAddress(), "10.0.0.0", "255.0.0.0") ||
          isInNet(myIpAddress(), "192.168.0.0", "255.255.0.0") ||
          isInNet(myIpAddress(), "169.254.0.0", "255.255.0.0") ||
          isInNet(myIpAddress(), "172.16.199.0", "255.255.255.0")
     )
     return "PROXY proxy.company.ru:3128;" +
            "PROXY proxy-a.company.ruu:3128";
     else return "DIRECT";
}

• проект TERENA "WWW Cache services in Europe" (1998)
• российская часть проекта (очень старое)
• HENSA 1996: 6 SGI R4400 170 Mhz, 128MB RAM, 2x6 GB дисковой памяти каждая, более миллиона обращений в день (до 100 в секунду), 15% принципиально некешируемы, 55% удачных попаданий, 30% неудачных.
• NZGate 1996: 128MB RAM, 10GB hard, 100000 обращений в день, 15% удачных.
• NLARN 1996 (National Laboratory for Advanced Networking Research, USA): 128MB RAM, 10GB hard. Потрясающей открытости сайт вплоть до файлов с конфигурацией и журналов.
• NLARN 1999: 512MB RAM, 16-32GB hard, реально используется не более 200 MB RAM и 10ГБ HD при миллионе запросов в день и от 25% до 68% успешных попаданий, 2 миллиона объектов, из них 2000 в VM (средний размер - 15 КБ), 500 fd
• SingNet - 650000 запросов в день, 53% успешных.

• Увы! Эффективность кеширования падает с каждым годом. Данные за начало марта 2001: кеш - 7 ГБ; ОП - 120 МБ; 4 запроса/секунду; 22 КБ/секунду; вероятность попадания в кеш - 38%; экономия трафика - 16%.
• 700 MB на диске, 8 МБ лимит оперативной памяти (реально занимал 40МБ), 2-месячный тестовый прогон, настройки почти стандартные, никаких соседей, процедуры обработки статистики еще неправленные (увы):

                                               TCP COUNTS          TCP BYTES
  Protocol                                  counts %all %hit   Mbytes %all %hit
  ---------------------------------------- ----------------- ------------------ --
  http                                     3097562 100%  34% 17559.36  92%  14%
  ftp                                         9575   0%   8%  1464.17   8%   7%
  ssl                                         5187   0%    -    18.00   0%    -
  gopher                                        34   0%    -     0.07   0%    -
  https                                         10   0%    -     0.01   0%    -
  

• 3.5ГБ на диске, 14МБ лимит ОП (реально 55МБ), максимальный размер объекта - 4МБ, реальная загрузка (в среднем 40 одновременно работающих клиентов совершенно непредсказуемыми запросами - 5000 хостов в день - верхние 100 обеспечивают 40% трафика; 3 обращения в секунду; 10% CPU P100), настройки почти стандартные, никаких соседей, процедуры сбора статистик переориентированы на подсчет трафика:
  1. к моменту заполнения кеша (неделя) за сутки получалась следующая картина:

                                                  TCP COUNTS          TCP BYTES
     Protocol                                  counts %all %hit   Mbytes %all %hit
     ---------------------------------------- ----------------- ------------------ --
     http                                      291772 100%  39%  1555.28  99%  23%
     ftp                                           74   0%   5%    10.82   1%   5%
     ssl                                           68   0%    -     0.24   0%    -
     ---------------------------------------- ----------------- ------------------ --

     таким образом экономия - 350MB/сутки (грубо прикидывая стоимость 1МБ в 4 цента- $420/месяц)
  2. в устоявшемся режиме (статистика за месяц), почти то же самое:

                                                  TCP COUNTS          TCP BYTES
     Protocol                                  counts %all %hit   Mbytes %all %hit
     ---------------------------------------- ----------------- ------------------ --
     http                                     7986894 100%  43% 43925.27  98%  23% 
     ftp                                         4793   0%   8%   747.21   2%   4% 
     ssl                                         1961   0%    -     7.90   0%    - 
     

• Web caching on Janet, 1996 (UK education network)
• Моделирование поведения прокси-кеш в зависимости от нагрузки и размера кеша (апр 1997, replay журнала реальной нагрузки).

  программа моделирования

  Некоторые выводы:

  • Идеальный размер кеша - от 2 до 10 ГБ в зависимости от числа клиентов. Приблизительно 1 ГБ кеша на каждые 100 тысяч запросов/день.
  • Исследования на минимальный размер кеша. При размере кеша 100 МБ трешинг начинался при 100 тысячах запросов в день.
  • При 100 тысячах запросов в день заполненная часть кеша не превышает 15 GB (остальное вымывается).
  • Для 300 000 запросов/день и 8ГБ д.б. hit rate = 52% (при 20ГБ - 60%) В реальности 38%. Что это - разница в методике? в контингенте пользователей? или у некоторых клиентов стоит свой прокси-кеш и наш частично выступает как кеш 3го уровня? времена настолько изменились? byte hit/rate д.б. 33% (для 10 ГБ - 35%), в реальности 16%

• Напрасных IMS-запросов (срок годности объекта истек и кеш сделал IMS-запрос, получив ответ, что объект не изменился): 5%. Чем более избыточен размер кеша, тем больше напрасных запросов.
• a one-thousand client cache with 70,000 requests/day had a hit rate no higher than 28%, while a two-thousand client cache with 250,000 requests/day achieved a 45% hit rate. client connected to a three-level hierarchy such as NLANR might see hits rates as high as 55%.
• We have about 800 000 transactions per day and With 12GB cache we have 48% transaction hitrate and 33% byte hitrate.
• oct 1998: 1 000 000/day (hit rate 46%), 8.2GB (byte hit rate 38%)

• netscape
• Proxy Auto-Detect (IE and Firefox)
• IE
• Web Proxy Auto-Discovery Protocol (draft)
• Десять примеров того, как не нужно писать PAC-файлы