HandyCache форум

Главная категория => Новые предложения => Тема начата: Сергей от 20 января 2007, 09:59:09



Название: Управление загрузкой по Заголовкам
Отправлено: Сергей от 20 января 2007, 09:59:09
Если будут обрабатываться заголовки, то это будет делать отдельный список?



:good: Реализовано в версии HC 1.0 RC1 с помощью скриптов Lua (http://handycache.ru/component/option,com_smf/Itemid,10/topic,1120.0/) !


Название: Re: Управление загрузкой по Заголовкам
Отправлено: DenZzz от 20 января 2007, 12:32:13
Сергей

Цитировать
Если будут обрабатываться заголовки, то это будет делать отдельный список?

Удобнее сделать отдельным списком, т.к. для новых файлов он будет обрабатываться уже после начала загрузки (получения заголовков), когда списки по URL уже отработали!

Тогда сюда можно будет перенести и блокировку "больших файлов", и блокировку файлов по типу "Content-Type", и сохранение в кэш по типу и многое другое!
Реализовать все это можно будет через универсальный список "Управление по заголовкам". Например, такой:

   Заголовок        Условие   Правило                URL                     Действие              Приоритет  
Content-Length>300000.*-1
Content-Type=.*image.*.*Блокировать1
Content-Type=.*image.*handycache\.ruТолько из кэша2
Content-Type=.*image.*.*Запись в кэш3

Строки с равным приоритетом объединять по "И".
Список проверять сверху вниз до первого срабатывания строки (группы строк, объединенных одним приоритетом).

Действия могут быть такими: Блокировать, Не обновлять, Только из кэша, Запись в кэш.

Хранить заголовки на диске для файлов неизвестных типов можно в одном индексном файле, либо в файлах типа #h .
Либо вообще не хранить заголовки, а сделать, как сейчас работает блокировка "больших файлов":
  • Сначала проверяем обычные списки по URL;
  • Если решено качать из Инета, то получаем заголовки и принимаем окончательное решение.

Над составом столбцов, действий и логикой еще надо подумать. Давайте обсудим...


Название: Re: Управление загрузкой по Заголовкам
Отправлено: NothingAnother от 20 января 2007, 15:35:01
Имхо, действия "Блокировать" и "Только из кэша" смысла не имеют, т.к. заголовки берутся из уже загруженного (за исключением "Chunked") объекта - что же тут блокировать?
А вот для контента неинформационного характера, определяемого по полю "Content-Type" весьма полезным будет действие "Переместить объект в каталог..."


Название: Re: Управление загрузкой по Заголовкам
Отправлено: DenZzz от 20 января 2007, 20:47:45
NothingAnother

Цитировать
Имхо, действия "Блокировать" и "Только из кэша" смысла не имеют, т.к. заголовки берутся из уже загруженного (за исключением "Chunked") объекта - что же тут блокировать?

Имеют! Мы можем начать качать объект (получить заголовки и первые килобайты) и после этого заблокировать дальнейшую загрузку! Это не имеет смысла, конечно, для маленьких объектов, а больших - вполне разумно! Именно так сейчас работает опция "Не загружать большие файлы"!

Цитировать
А вот для контента неинформационного характера, определяемого по полю "Content-Type" весьма полезным будет действие "Переместить объект в каталог..."

Поясни смысл.  Что за объекты "неинформационного характера", в какой каталог перемещать и для чего?


Название: Re: Управление загрузкой по Заголовкам
Отправлено: NothingAnother от 20 января 2007, 21:19:48
Мы можем начать качать объект (получить заголовки и первые килобайты)...skipped...Именно так сейчас работает опция "Не загружать большие файлы"
Сумневаюсь... ::)
Цитировать
Что за объекты "неинформационного характера", в какой каталог перемещать и для чего?
application/zip, audio/mp3, video/mpeg, etc.


Название: Re: Управление загрузкой по Заголовкам
Отправлено: DenZzz от 20 января 2007, 21:32:49
NothingAnother

Цитировать
Сумневаюсь...

В чем сомневаешься, что именно так и работает? А как ты думал? ;)

Может, Документация (http://handycache.ru/content/view/8/5/1/1/) тебя убедит (правда, ее я писал): :)
Цитировать
Здесь вы можете запретить загрузку определенных файлов, размер которых превышает заданный размер. При проверке размера происходит запрос файла в Интернете и анализ HTTP-заголовка "Content-Length". Если размер файла больше предельного, то загрузка прерывается. Если сервер передает файл без заголовка "Content-Length", то он будет загружен полностью независимо от конечного размера.


Цитировать
application/zip, audio/mp3, video/mpeg, etc.

Предлагаешь их перемещать не в кэш HC, а куда-то в другое место?


Название: Re: Управление загрузкой по Заголовкам
Отправлено: NothingAnother от 20 января 2007, 21:51:18
В чем сомневаешься, что именно так и работает?
Признаться - да, в этом...
Цитировать
А как ты думал?
Надеялся, что с помощью "HEAD". Если всё действительно происходит именно так - не буду далее пользоваться этой опцией :(
Цитировать
Предлагаешь их перемещать не в кэш HC, а куда-то в другое место?
Ну да, на усмотрение юзера, что-то типа "download-root". И не только их, а иже с ними есть ещё немало...


Название: Re: Управление загрузкой по Заголовкам
Отправлено: DenZzz от 20 января 2007, 22:28:17
NothingAnother

Цитировать
Надеялся, что с помощью "HEAD". Если всё действительно происходит именно так - не буду далее пользоваться этой опцией


Нет, когда создавалась эта опция, было решено не терять время на HEAD, а сразу начинать закачку GET, а потом уже принимать окончательное решение.
Лично у меня на медленном канале HC успевает скачать только 1-2 кб, а потом срабатывает блокировка! А у тебя как и почему тебя это пугает? ;)


Название: Re: Управление загрузкой по Заголовкам
Отправлено: NothingAnother от 20 января 2007, 23:05:18
Лично у меня на медленном канале HC успевает скачать только 1-2 кб, а потом срабатывает блокировка! А у тебя как и почему тебя это пугает?
У меня DSL, реальная скорость ко мне - где-то около 2.5 мегабайт. Но вряд ли это имеет значение - если даже для приёма первой порции данных через сокет просто выделяется достаточно малый буфер, так он же в свою очередь сам заполняется из другого буфера - сетевого (они находятся на разных уровнях OSI, соотв. на 4-ом - транспортном и на 3-ем - сетевом). Размер (оптимизированный) сетевого буфера у меня - 256 KB, так что меньше не ограничить...


Название: Re: Управление загрузкой по Заголовкам
Отправлено: DenZzz от 20 января 2007, 23:22:53
NothingAnother

Цитировать
Размер (оптимизированный) сетевого буфера у меня - 256 KB, так что меньше не ограничить...

Хм, тогда в будущем для получения заголовков есть смысл задуматься об опции "Использовать HEAD-метод для быстрых каналов"... ;)


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Дем от 21 января 2007, 12:09:56
Лично у меня на медленном канале HC успевает скачать только 1-2 кб, а потом срабатывает блокировка! А у тебя как и почему тебя это пугает?
У меня DSL, реальная скорость ко мне - где-то около 2.5 мегабайт. Но вряд ли это имеет значение - если даже для приёма первой порции данных через сокет просто выделяется достаточно малый буфер, так он же в свою очередь сам заполняется из другого буфера - сетевого (они находятся на разных уровнях OSI, соотв. на 4-ом - транспортном и на 3-ем - сетевом). Размер (оптимизированный) сетевого буфера у меня - 256 KB, так что меньше не ограничить...
А почему ты думаешь, что данные сначала заполняют буфер доверху, и только потом попадают в НС?
Такое происходит только в случае, если программа не успевает или сознательно ограничивает скорость приёма.
Первый же прибежавший пакет (~1400 байт) попадает в НС и приводит к нужной реакции, так как как правило заголовок в него влезает полностью.
Разумеется, пока соединение рвётся, сервак успеет передать ещё некое количество информации - но не так уж и много. Надо реально смотреть сколько.


Название: Re: Управление загрузкой по Заголовкам
Отправлено: DenZzz от 21 января 2007, 12:28:43
NothingAnother

Да, собственно, ты проводил "полевые испытания"? :)
Сколько реально успевает скачать HC на твоем DSL до срабатывания блокировки "больших файлов"?


Название: Re: Управление загрузкой по Заголовкам
Отправлено: NothingAnother от 21 января 2007, 19:50:53
ты проводил "полевые испытания"?
Нет

почему ты думаешь, что данные сначала заполняют буфер доверху, и только потом попадают в НС?
Уже не думаю, вспомнил, что структура итерфейсного буфера - стек типа FIFO
Цитировать
Первый же прибежавший пакет (~1400 байт) попадает в НС и приводит к нужной реакции, так как как правило заголовок в него влезает полностью
Не совсем так. Если HC не читает из буфера сокета побайтно (надеюсь, что - нет, это вешает процессор), а реагирует на завершение операции WinSockAPI асинхронно посредством callback-функции, то данные станут доступны в двух случаях - буфер сокета заполнен или все данные из интерфейсного буфера считаны. При создании объекта сокета ему выделяется буфер размером по умолчанию 4K, но это можно изменить в зависимости от задачи. Если буфер уменьшить - увеличится нагрузка на процессор, если увеличить - увеличится расход памяти. Оптимум находится, как возможность уместить статистически усреднённый сетевой ресурс в буфер "за один заход". В своё время я считал статистику своего серфинга для 40000 файлов. "Загрузоки" - контент больше 1M не учитывался. Получилось, что 50% умещаются в 8K, 90% - 16K, 95% - 32K, 98% - 64K. Для себя я выбрал 16K ("за один заход" принимаются 9 из 10 ресурсов), у mai62, естественно, свои резоны... Но к чему я веду - "...приводит к нужной реакции..." вовсе не "Первый же прибежавший пакет..."
Цитировать
пока соединение рвётся, сервак успеет передать ещё некое количество информации - но не так уж и много. Надо реально смотреть сколько
Надо. Неохота. Лениво...


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Дем от 22 января 2007, 02:43:21
Цитировать
Если HC не читает из буфера сокета побайтно (надеюсь, что - нет, это вешает процессор), а реагирует на завершение операции WinSockAPI асинхронно посредством callback-функции, то данные станут доступны в двух случаях - буфер сокета заполнен или все данные из интерфейсного буфера считаны.
Немножко не так. callback происходит по появлению информации в буфере. Любого количества. Но - данные по сетке ходят пакетами. И меньше пакета в буфер попасть не может.
Типичная длина пакета - 1420 байт, заголовок порядка килобайта...


Название: Re: Управление загрузкой по Заголовкам
Отправлено: NothingAnother от 22 января 2007, 08:07:51
Типичная длина пакета - 1420 байт
Минимальная длина, гарантирующая пакет от фрагментации при проходе его по любому маршруту в WWW - 576B, и реально таких пакетов в инете немало
Цитировать
заголовок порядка килобайта
Не учитывая куки 150-300B, c куками ессно поболее, но они, как правило, находятся в конце заголовков. Это просто уточнение, всё равно информация о размере (Content-length), скорее всего действительно доступна уже в первом пакете. Но!:
Цитировать
callback происходит по появлению информации в буфере. Любого количества
Глубоко сумневаюсь. ::) Это выхолащивает суть асинхронного буферированного чтения входного потока и становится эквивалентно побайтному приёму. Попав в интерфейсный буфер, пакеты исчезают как сущность и превращаются в "поток". И объект сокета в свой буфер считывает уже не пакеты, а этот самый поток до завершения операции чтения по событию наполнения буфера или достижению конца потока. Смысл callback-вызовов - реакция приложения на завершение операции API. А в этом случае какой операции? Чтению байта? Тогда и буфер не нужен ;)


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Дем от 22 января 2007, 09:53:55
Цитировать
Минимальная длина, гарантирующая пакет от фрагментации при проходе его по любому маршруту в WWW - 576B, и реально таких пакетов в инете немало
Угу. Хватает. Но, тем не менее, 1420 байт тоже частое явление...

Цитировать
Смысл callback-вызовов - реакция приложения на завершение операции API.
Вопрос в том, завершение какой операции мы хотим увидеть. И какие настройки выдаём сокету в связи с этим.
Поэтому возможен вызов callback (в соответствии с параметрами открытия сокета)  в трёх ситуациях:
1) завершение приёма/наполнение буфера
2) приход пакета данных
3) приход фрагмента пакета

И какой режим выбран у автора - вопрос к нему :)


Название: Re: Управление загрузкой по Заголовкам
Отправлено: DenZzz от 22 января 2007, 10:14:16
NothingAnother

Цитировать
Надо. Неохота. Лениво...

Может, все-таки, пересилишь лень и проведешь "полевые испытания"!?
Время на это уйдет гораздо меньше, чем на теоретические споры в этой теме! ;)


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Rick от 22 января 2007, 12:19:33
Минимальная длина, гарантирующая пакет от фрагментации при проходе его по любому маршруту в WWW - 576B, и реально таких пакетов в инете немало
Статистики на глаза не попадалось, но думаю, что таковых крайне мало - "пережиток старины".

Цитировать
Глубоко сумневаюсь. ::) Это выхолащивает суть асинхронного буферированного чтения входного потока и становится эквивалентно побайтному приёму. Попав в интерфейсный буфер, пакеты исчезают как сущность и превращаются в "поток". И объект сокета в свой буфер считывает уже не пакеты, а этот самый поток до завершения операции чтения по событию наполнения буфера или достижению конца потока. Смысл callback-вызовов - реакция приложения на завершение операции API. А в этом случае какой операции? Чтению байта? Тогда и буфер не нужен ;)
Наполнение буфера означает, что продолжающие поступать пакеты будут отвергаться, затем запрашиваться вновь. Поэтому начало чтения с момента заполнения буфера - путь к ошибкам и многократным повторам.
Чтение из буфера начинается по факту появления в нем данных, однако система может быть не готова сделать это (занята) - для этого и нужен буфер и в этом же и ассинхронность: данные поступили, но считаны могут быть с задержкой - по готовности системы сделать это.

И мы ударились в теорию вместо того, чтобы оценить "цену вопроса": сколько "лишних" данных будет принято. И похоже кроме тебя некому провести такой эксперимент.


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Дем от 22 января 2007, 15:00:49
Раз уж вам лень - я у себя протестил. (канал 512К)
У большинства - в районе 1150 байта (±10)
у примерно 15% - в районе 2610
у примерно 2% - в районе 4070

Размер пакета прослеживается однозначно :)


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Rick от 22 января 2007, 15:15:41
Раз уж вам лень - я у себя протестил. (канал 512К)
У NothingAnother канал ~21Мбит/с - поэтому и хотелось бы, чтобы тест провел он.

Цитировать
У большинства - в районе 1150 байта (±10)
у примерно 15% - в районе 2610
у примерно 2% - в районе 4070
Это что? Размер заголовка, или объем поступивших данных до принятия решения об отказе загрузки этого файла? Интересует именно второе. И как измерял.


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Дем от 22 января 2007, 18:20:53
Цитировать
Это что? Размер заголовка, или объем поступивших данных до принятия решения об отказе загрузки этого файла? Интересует именно второе. И как измерял.
Именно второе - объём поступивших данных.
Просто поставил лимит размера для jpg в 16к и открыл страничку с фишек (сотня картинок где-то)

На индикаторе загрузки файла было 1-3%


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Дем от 22 января 2007, 18:40:27
ЗЫ.
Тут прогнал такую програмку:
Код:
Char[] read = new Char[4096];
int count = sr.Read( read, 0, 4096 );
while (count > 0) {
    Console.Write(count);
    count = sr.Read(read, 0, 4096);
}
sr - естественно сокет.
Результат слегка поразил:

3937 1460 1435 2645 1212 1110 1181 1291 4096 657 1630 1424 1416 1364 2831 732 515 1228 4096 2044 565 448 1439 4096 2195 584 1433 1387 877

Т.е. винда вообще читает как бог на душу положит...


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Rick от 22 января 2007, 19:07:22
Просто поставил лимит размера для jpg в 16к и открыл страничку с фишек (сотня картинок где-то)
На индикаторе загрузки файла было 1-3%
Это некоррекное измерение. В самом НС можно увидеть только то что он принял, но не то, что фактически пришло (и посчиталось как трафик) но было им не востребовано. Нужно смотреть, например, firewall'ом сколько было принято. Хотя и это не "чистый" результат, но куда больше похожий на правду.

Цитировать
Т.е. винда вообще читает как бог на душу положит...
Да, верно. Поэтому и нужны измерения. Поэтому и желательно измерять на быстром канале. Хотя 512Кбит - тоже не медленный. :)


Название: Re: Управление загрузкой по Заголовкам
Отправлено: NothingAnother от 23 января 2007, 00:34:55
винда вообще читает как бог на душу положит
А какие данные ты брал из сокета? Опиши условия,- как именно они попали в сокет

Наполнение буфера означает, что продолжающие поступать пакеты будут отвергаться, затем запрашиваться вновь. Поэтому начало чтения с момента заполнения буфера - путь к ошибкам и многократным повторам
Это не так, поскольку в системе имеются два буфера - интерфейсный (представляющий собой стек типа FIFO, или проще - "очередь", размер задаётся в реестре) и буфер сокета (обычный байтовый массив, размер задаётся при создании объекта сокета), из которого в свою очередь приложение читает уже в свой собственный буфер (rem: когда я писал о статистике, процентах, и оптимальном размере - речь шла о буфере сокета). Так вот эта входная очередь и позволяет избежать потерь данных при заполнении буфера сокета и вызываемой этим задержки для осуществления операции переброса данных приложением в собственный буфер, так что отвергаться пакеты не будут
Цитировать
похоже кроме тебя некому провести такой эксперимент
Сумневаюсь. На величину получаемого "мусорного хвоста" влияет не cтолько полоса канала, сколько размер интерфейсного буфера (RWIN). При установлении соединения TCP клиент сообщает серверу размер RWIN в двух байтах заголовка TCP (смещение 0x1C), и сервер формирует блоки данных для отправки клиенту именно такого размера (если не имеет собств. огранич.), после приёма которых клиент отправляет серверу сообщение об успешном приёме блока и готовности к следующему или (при ошибке) просьбу повторить отправку сбойного блока (т.н. "квитирование"). Поэтому, даже если HC и "не хочет больше кушать", первый блок длиной, равной размеру RWIN будет принят в любом случае. Термины "клиент" и "сервер" в данном контексте означают не HC и Апач, а стеки TCP запрашивающего и отвечающего компьютеров. У меня RWIN установлен в 252K. При установке у себя параметров сетевого доступа пользовался этим ресурсом (http://www.speedguide.net/faq_in.php?category=89)

Может, все-таки, пересилишь лень и проведешь "полевые испытания"!? Время на это уйдет гораздо меньше, чем на теоретические споры в этой теме!
Да, DenZzz, так и поступлю...

Убил вечер на эксперименты и поиски доп. инф., но выяснил новые подробности - всё вышесказанное справедливо в отношении использования модема в режиме бриджа, т.е. когда винда напрямую смотрит в сеть. У меня же роутер с хардварным фаером, эта штука "раздевает" мои IP-пакеты и формирует свои. Сетевой буфер там так же свой, и похоже весьма небольшой. С одной стороны это радует - "мусорные хвосты" будут меньше. С другой - небольшой напряг - надо будет пересмотреть свои сетевые настройки. Ну, да нет худа без добра - благодаря нашей дискуссии теперь смогу заново оптимизировать с учётом неожиданно (для меня) открывшихся новых "вводных"
Да, чуть не забыл главного ::) При установке в HC ограничения 1K хвост на разных ресурсах (испытывл на 5 URI) непостоянен, и плавает в пределах 6-40K. При этом, в мониторе HC "Получено" перемежаются только два значения - 4096 и 4109


Название: Re: Управление загрузкой по Заголовкам
Отправлено: Дем от 23 января 2007, 14:27:25
Цитировать
А какие данные ты брал из сокета? Опиши условия,- как именно они попали в сокет
Разобрался, почему таки странные цифири. Наш глобальный файрвол, получая сжатую инфу, её разжимает (анализирует/фильтрует) и уже в таком виде отдаёт клиенту.
А при разжатии у него достаточно странные размеры кусков получаются, и он их так и отдаёт.
Для бинарников результат гораздо стабильней 1420-1440-1460


Название: Анализ Content-Type
Отправлено: Colonel от 19 октября 2007, 13:57:52
...
3. Идея использовать "Content-Type" вместо расширения очень интересна. Если можно будет указывать ограничения основываясь и на "Content-Type", то я обеими руками "за". Но анализ URL-а не следует исключать, т.к. это позволит настроить разные правила для разных групп сайтов (например есть "доверенные" сайты и "остальные"). В общем, что-то в этом духе.

Что получается:
Набор строк вида
Маска URL-а + Список "Content-Type" = ограничение + признак прерывания закачки
позволит настроить большинство вариантов

Идея в принципе не плохая, и она должна сработать в моём случае.
Я не могу перекрыть доступ к потоковому видео и радио!!
Часть сайтов передают потоки без расширений и вычислить откуда появилась утечка, чтобы добавить в чёрный список, достаточно тяжело. Тем более я заметил что медиатрансляции в мониторе редко отображаются.


Название: Анализ Content-Type
Отправлено: DenZzz от 19 октября 2007, 14:12:44
Тем более я заметил что медиатрансляции в мониторе редко отображаются.

Не совсем так. Все, что идет через HC, в Мониторе обязательно отображается, если не включен фильтр!
Другой момент, что длительные соединения через несколько минут убираются из окна активных соединений, но они продолжают работать и в верхней таблице по-прежнему активны!


Название: Обработка заголовков в фильтрах
Отправлено: ivan386 от 15 мая 2008, 23:09:16
Интересует возможность работы с заголовками в фильтрах.
Меня конкретно интересует Content-Type: для принятия решения о записи в кеш. Но думаю не стоит ограничиваться только на этом параметре.


Название: Re: Обработка заголовков в фильтрах
Отправлено: DenZzz от 15 мая 2008, 23:32:23
Это уже реализовано! Читай тему: "Скрипты Lua в HandyCache (http://handycache.ru/component/option,com_smf/Itemid,10/topic,1120.0/)".