39 replies to this topic

[Danil Biruykov-Romanov]

Проверил на файле размером 4Gb - netcheck потребляет максимум 15% от ядра и то в максимуме, в среднем цифра куда меньше.
 

[plintapy]

 

Доступа к beta ещё нет? У меня squid 3.5.25 из репозитария squid, если это важно.

Нет, Beta еще не открыта. Откроется на этой или на следующей неделе.
Как только будет открыта - появится ветка в соответствующем разделе форума - https://forum.drweb.com/index.php?showforum=18

Так же, скорее всего я отпишусь в эту ветку.

Касательно таймаутов, уточнил у разработки:
Схема проверки файла через icap выглядит следующим образом:
1. Squid полностью загружает файл
2. Этот файл передается на проверку через протокол icap
3. Тут уже идет проверка файла антивирусом

В случае с Internet-gateways, второй шаг выполняется drweb-icapd (получение файла от Squid и передача его на проверку), и только в третьем пункте таймауты начинают работать.


По проверке больших файлов - сейчас проверю на файле в несколько GB, скорость интернета тут в целом роли не играет - все равно файл в начале полностью загружается и только после идет на проверку.
 

 

 

Если сквид сначала скачивает файл полностью, а потом передаёт его на проверку через icap, то что в этот момент видит пользователь: "Соединение с сервером"? А скачивание может занять минуты или часы и пользователь, не получив ожидаемого результата, ещё раз жмакнет на закачку файла.

Я вижу, что размер скачиваемого файла растёт в tmp-каталоге Dr.web, т.е. проверка как бы должна уже идти.

Какое-то временное решение есть? Напоминаю, что я использую icap_preview

[plintapy]

Какое-то временное решение есть?

 

Вставлю ответ тех.поддержки.

 

имеет смысл средствами Squid ограничивать по Content-Length размер проверяемого контента 


acl to_pass rep_header content-length ^[0-9]{7,}$ 
icap_service i_req reqmod_precache icap://ip:port/reqmod bypass=0 
icap_service i_res respmod_precache icap://ip:port/respmod bypass=0 
adaptation_access i_req allow all 
adaptation_access i_res deny to_pass 

[Danil Biruykov-Romanov]

Если сквид сначала скачивает файл полностью, а потом передаёт его на проверку через icap, то что в этот момент видит пользователь: "Соединение с сервером"? А скачивание может занять минуты или часы и пользователь, не получив ожидаемого результата, ещё раз жмакнет на закачку файла.

Я вижу, что размер скачиваемого файла растёт в tmp-каталоге Dr.web, т.е. проверка как бы должна уже идти.

Какое-то временное решение есть? Напоминаю, что я использую icap_preview

 

 

Только как уже показал саппорт - ограничить проверку определенных файлов по размеру, по типу (например iso как правило весьма крупны) или любым другим образом.
 

[amorozov]

Если сквид сначала скачивает файл полностью, а потом передаёт его на проверку через icap, то что в этот момент видит пользователь: "Соединение с сервером"? А скачивание может занять минуты или часы и пользователь, не получив ожидаемого результата, ещё раз жмакнет на закачку файла.

 

Ну, Squid его сразу льёт в сторону ICAPD. А дальше имеем ограничение протокола ICAP. ICAPD должен отдать либо контент, либо страницу блокировки. Если начать отдавать контент, то потом уже не получится заблокировать. Поэтому он ждёт, когда получит всё полностью, потом это сканирует и отвечает.

[Danil Biruykov-Romanov]

https://forum.drweb.com/index.php?showtopic=327757#entry830014

 

Вот тут есть deb и rpm репозитории из них можно установить в том числе и internet-gateways.

[mrrc]

Если сквид сначала скачивает файл полностью, а потом передаёт его на проверку через icap, то что в этот момент видит пользователь: "Соединение с сервером"? А скачивание может занять минуты или часы и пользователь, не получив ожидаемого результата, ещё раз жмакнет на закачку файла.

 

В 6-й линейки продукта в icapd имелась замечательная возможность задать размер подлежащих проверки объектов mime-type, в том числе и размер в целом для всех объектов, все прекрасно работало и не вызывало проблем. Все объекты, что больше мегабайта, сразу отдавались после жмака, меньше - практически мгновенно скачивались, проверялись и отдавались, пользовательское юзабилити не страдало.

В 11-й версии усе, подобной реализации более не видать?

[Danil Biruykov-Romanov]

 

Если сквид сначала скачивает файл полностью, а потом передаёт его на проверку через icap, то что в этот момент видит пользователь: "Соединение с сервером"? А скачивание может занять минуты или часы и пользователь, не получив ожидаемого результата, ещё раз жмакнет на закачку файла.

 

В 6-й линейки продукта в icapd имелась замечательная возможность задать размер подлежащих проверки объектов mime-type, в том числе и размер в целом для всех объектов, все прекрасно работало и не вызывало проблем. Все объекты, что больше мегабайта, сразу отдавались после жмака, меньше - практически мгновенно скачивались, проверялись и отдавались, пользовательское юзабилити не страдало.

В 11-й версии усе, подобной реализации более не видать?

 

Этот функционал есть в самом Squid:

acl to_pass rep_header content-length ^[0-9]{7,}$
icap_service i_req reqmod_precache icap://ip:port/reqmod bypass=0 
icap_service i_res respmod_precache icap://ip:port/respmod bypass=0 
adaptation_access i_req allow all 
adaptation_access i_res deny to_pass
 

Edited by Danil Biruykov-Romanov, 23 June 2017 - 12:02.

[mrrc]

Возможность задать размер и тип проверяемых объектов один из ключевых элементов настройки продукта и должна настраиваться непосредственно в ICAPD, а не в конфигурациях используемых прокси-серверов, ИМХО.

После многих лет пользования предыдущими версиями продукта и ознакомления с 11-й версией сложилось впечатление, что все писалось другой командой и с ноля, а имевшиеся наработанные годами механизмы настройки и функциональности не перенеслись в актуальный релиз.

[plintapy]

В 11-й версии усе, подобной реализации более не видать?

 

Я не знаю как было в 6 версии, но в 11 надо в настройках прокси делать. Может быть это и логично.

[mrrc]

В 6.х данная настройка выполнялась весьма логично и просто drweb-icapd.ini:

# Set of rules for processing of files depending on their mime-type.
MimeStart
  *                                scan 1M pass
  application                      scan 1M pass
  image                            scan 1M pass
  message                          scan 1M pass
  multipart                        scan 1M pass
  text                             scan 1M pass
  audio                            pass all
  video                            pass all
  application/x-mms-framed         pass all
MimeEnd

Главное, работала исправно.

[amorozov]

В 6.х данная настройка выполнялась весьма логично и просто drweb-icapd.ini:

# Set of rules for processing of files depending on their mime-type.
MimeStart
  *                                scan 1M pass
  application                      scan 1M pass
  image                            scan 1M pass
  message                          scan 1M pass
  multipart                        scan 1M pass
  text                             scan 1M pass
  audio                            pass all
  video                            pass all
  application/x-mms-framed         pass all
MimeEnd

Главное, работала исправно.

PASS можно сделать с помощью content_type в правилах.
Модифицировать поведение в зависимости от размера контента сейчас нельзя.

[plintapy]

Появилась ещё одна проблема с net-checker'ом - проверка каждого файла занимает 5 сек.

Я добавил в лог squid параметр  icap::tt (Total ICAP processing time for the HTTP transaction. The timer ticks when ICAP ACLs are checked and when ICAP transaction is in progress) и это значение в районе ~5000мс.

Включив дебаг net-checker'а вижу такую картину:

2017-Aug-01 09:21:07 [8673] Debug: LocalJob 0x7539a: File "/tmp/com.drweb.ncheck/cb7a-dc76-174f-b4ee"
2017-Aug-01 09:21:07 [8673] Debug: Client 0x1: INIT 480154 as LocalJob 0x7539a
2017-Aug-01 09:21:07 [8673] Debug: LocalJob 0x7539a: Scan
2017-Aug-01 09:21:07 [8673] Debug: LocalJob 0x7539a: Scan report received
2017-Aug-01 09:21:12 [8673] Debug: LocalJob 0x7539a: Destroyed

И вот это время между Scan и Destroyed тоже составляет 5с. Проверил другие задания - везде 5с.

Нагрузки на диск почти нет (iowait < 1%), кэш squid находится на другом диске.

 

В связи с этим у меня вопрос: ICAP сообщат результат проверки после события Destroyed?

 

Как избавиться от этой задержки в 5с? Пока из идей только вынести  /tmp/com.drweb.ncheck/ в RAM, но я не вижу проблем с диском. Может есть какая-то проблема с engine?

[amorozov]

Включив дебаг net-checker'а вижу такую картину:

Логи лучше смотреть всех компонентов сразу.
 

В связи с этим у меня вопрос: ICAP сообщат результат проверки после события Destroyed?

Нет. Destroyed происходит, когда Squid вычитал ответ от ICAPD (или закрыл соединение).

[plintapy]

Логи остальных компонентов ничего не говорят.

Ну т.е. это squid медленно читает, а не drweb медленно пишет?

 

Проблема была из-за трафика до серверов обновлений Касперского. Может быть такое, что сигнатуры антивирусов дольше проверяются? Пока просто не отправляю запросы до их серверов в icap.

 

 

 

 

[amorozov]

Ну т.е. это squid медленно читает, а не drweb медленно пишет?

Тормозить может любой элемент цепочки HTTP-клиент - Squid - ICAPD - NetCheck.

Может быть такое, что сигнатуры антивирусов дольше проверяются?

Видимо, может.

[plintapy]

 

Ну т.е. это squid медленно читает, а не drweb медленно пишет?

Тормозить может любой элемент цепочки HTTP-клиент - Squid - ICAPD - NetCheck.

 

 

 

 

Я же написал, что добавил в лог squid параметр   icap::tt. Это время проверки icap-acl и  icap-проверки. Т.е. клиент тут не участвует. Может быть drweb загибается от количества запросов, т.к. не хватает ресурсов. Но вот постоянство задержки в 5с меня смущает.

[skameykin]

И что в итоге?

[Boris Savelev]

11.0.3 вышла, предлагаю попробовать. Должно стать лучше

[plintapy]

11.0.3 вышла, предлагаю попробовать. Должно стать лучше

 

А changelog есть?