Нужна помощь программистов с оптимизацией PAC-файла

Пока есть идея сжать просто по модулю. Всего 39 символов то есть в 128 бит ASCII можно вместить 3 символа в одном. И сейчас те 2 мегабайта как 700 килобайт представить + алгоритм разжатия довольно простой. Тьфу в 128 возможных чисел. Взять по модулю. И будет сжатие в 3 раза по сути. Нужно конечно проскипать символы закрывающих кавычек, экранироваия и перевода строки.

Реализовал алгоритм сжатия LZ Prediction (LZP) из протокола PPP, изменив хеш-функцию империческим путём. Prediction-байты сохраняются отдельно от данных, в base64-переменную, которая еще дополнительно обрабатывается существующим RLE-сжатием.

Приличную часть времени потратил на поддержку Internet Explorer 8 и Firefox 52: последним сёрфят как минимум 400 пользователей сервиса (кто-то «чистым» FF, кто-то K-Meleon/PaleMoon/SeaMonkey).
Визуально скорость не пострадала, но детально не измерял.

Сильно это, увы, не помогло. Файл опять едва вписывается в лимиты (но хотя бы обновляется).

1007799 proxy.pac

Принимаются другие идеи. Можно сконцентрироваться на исключении мусорных доменов.

Раздавать два PAC-скрипта: с ограничением в 1МБ и без этого ограничения.

Здравствуйте. Со вчерашнего дня софт pacproxy перестал работать с новым pac файлом. При этом браузер работает нормально. Могу я попросить ссылку на предыдущую версию рас файла, если таковая имеется? Также присоединяюсь к предложнению из предыдущего поста о распространении двух версий файлов. И извините если немного не в тему.

Можно так сделать. Взять все эти домены и пройтись по ним CURLом. Если там нет ответа, ошибка http или прочая ерунда, а так же заглушки паркингов или какие-то стандартные странички (надо изучать) , то в помойку.
Переделывать этот список, скажем, раз в неделю или 2. Лучше сделать так, что не сразу в помойку, а если 2 раза подряд в проверках он плохой, то надолго его в бан. А то мало ли временная проблема
Держать 2 последних плохих листа и в бан заносить только их пересечение.
Запускать по 50 тхредов, чтобы было быстрее.
Можно не париться на счет обиды кого-то. С точки зрения хостера это просто трафик определенного обьема, а для конечных сайтов это всего лишь 1 запрос. Нагрузки на CPU так же особо не усматривается.
Применять подмену user-agent на броузерный, иначе некоторые сайты могут неправильно себя повести.

Как вариант можно не курлами это делать из шелла, а на питоне что-то написать не очень сложное

Много так, увы, не вырезать. У меня есть список ресолвящихся доменов тут : https://raw.githubusercontent.com/bol-van/rulist/main/reestr_hostname_resolvable.txt
и в основном там есть какой-то сайт

Еще можно взять тот список и посмотреть на счет зеркал. Составить список regexp, чтобы резать многочисленные зеркала.
Пример : maxbet*, pinup* pin-up*, sex0*, solcasino*
проституток, наркоту и дипломы можно сразу убивать, возможно так же и казино

Это и сейчас реализовано с поиском по паттернам. У себя отбрасываю все вхождения с числом больше 1100 и результирующий файл получается ~800кб.
На счет ливнесс пробы в скрипте есть чекинг nxdomains. Он уменьшает размер на 400кб.

wc -l reestr_hostname_resolvable.txt
347090
grep  casino reestr_hostname_resolvable.txt  | wc -l
48700
grep bet reestr_hostname_resolvable.txt  | wc -l
18121
grep  prostitut reestr_hostname_resolvable.txt  | wc -l
4486
grep  diplom reestr_hostname_resolvable.txt  | wc -l
3904
grep  spravk reestr_hostname_resolvable.txt  | wc -l
963
grep pinup reestr_hostname_resolvable.txt  | wc -l
3441
grep pin-up reestr_hostname_resolvable.txt  | wc -l
2264

Это уже около 25%

Это уже всё используется
https://bitbucket.org/anticensority/antizapret-pac-generator-light/src/master/config/exclude-regexp-dist.awk

Может подойти к проблеме с другой стороны - составить частотную характеристику запрашиваемых на стороне прокси доменов? И не включать в pac домены с популярностью менее определенного порога. Технические способы помогут только отсрочить проблему, но не решить ее кардинально, ибо данный список будет только увеличиваться. Я сильно сомневаюсь, что оставшиеся после фильтрации какие-нибудь *azino также востребованы, как и топовые новостные ресурсы в известной зоне. Так зачем тащить этот мертвый груз? А порог можно сделать плавающим, на основе собираемой статистики, чтобы укладываться в лимиты. Если конечно ведется такая статистика.

а дайте пожалуйста референсный исходник, не обязательно ркновский. давайте сделаем референсный файл на 10000 строк и будем смотреть на его примере что лучше сжимает. я сделал для себя lzw компрессию и минификацию. https://p.thenewone.lol:8443/proxy.pac тут на одних переносах строки можно не слабо сэкономить. еще можно миллиард азино превратить в один *.азино

Референс есть в репозитории.

ну нет, угадывать репо и файл в нем такое. как говорится, какое тз такое и хз

Что конкретно непонятно? Все ссылки есть в первом сообщении. В указанном бранче не выполняется обновление листа, и списки заморожены на дату коммита бранча, на них и тестируйте.

вот именно что списки, их поди еще там найди. а нужно один референсный исходный файл. типа “вот вам файл, задача сделать из него pac минимального размера без потери данных”.

Исходный файл списка, чтобы сделать другой PAC-файл с нуля?
Списки вот и вот, но эта другая задача, не по теме.

понял, вы не ищите способы минификации рас, вам нужно чтоб именно ваш файл оптимизировали.

Можно ли проверять User-Agent браузера? К примеру, пользователям IE и старых браузеров возвращать усечённый по объёму файл с наиболее популярными сайтами, а пользователям современных браузеров - полный?
Ещё вариант - некоторые зоны вынести сразу на прокси, к примеру, .com.ua и .co.il (новостные порталы Украины и Израиля), т.к. в этих зонах такое чувство, что гораздо больше заблоченных сайтов, чем не заблоченных.

Ограничение на размер файла есть только в Chrome и браузерах, основанных на нём. Выходит наоборот.