Реализовал алгоритм сжатия LZ Prediction (LZP) из протокола PPP, изменив хеш-функцию эмпирическим путём. Prediction-байты сохраняются отдельно от данных, в base64-переменную, которая еще дополнительно обрабатывается существующим RLE-сжатием.
Приличную часть времени потратил на поддержку Internet Explorer 8 и Firefox 52: последним сёрфят как минимум 400 пользователей сервиса (кто-то «чистым» FF, кто-то K-Meleon/PaleMoon/SeaMonkey).
Визуально скорость не пострадала, но детально не измерял.
Сильно это, увы, не помогло. Файл опять едва вписывается в лимиты (но хотя бы обновляется).
1007799 proxy.pac
Принимаются другие идеи. Можно сконцентрироваться на исключении мусорных доменов.
Здравствуйте. Со вчерашнего дня софт pacproxy перестал работать с новым pac файлом. При этом браузер работает нормально. Могу я попросить ссылку на предыдущую версию рас файла, если таковая имеется? Также присоединяюсь к предложнению из предыдущего поста о распространении двух версий файлов. И извините если немного не в тему.
Можно так сделать. Взять все эти домены и пройтись по ним CURLом. Если там нет ответа, ошибка http или прочая ерунда, а так же заглушки паркингов или какие-то стандартные странички (надо изучать) , то в помойку.
Переделывать этот список, скажем, раз в неделю или 2. Лучше сделать так, что не сразу в помойку, а если 2 раза подряд в проверках он плохой, то надолго его в бан. А то мало ли временная проблема
Держать 2 последних плохих листа и в бан заносить только их пересечение.
Запускать по 50 тхредов, чтобы было быстрее.
Можно не париться на счет обиды кого-то. С точки зрения хостера это просто трафик определенного обьема, а для конечных сайтов это всего лишь 1 запрос. Нагрузки на CPU так же особо не усматривается.
Применять подмену user-agent на броузерный, иначе некоторые сайты могут неправильно себя повести.
Как вариант можно не курлами это делать из шелла, а на питоне что-то написать не очень сложное
Еще можно взять тот список и посмотреть на счет зеркал. Составить список regexp, чтобы резать многочисленные зеркала.
Пример : maxbet*, pinup* pin-up*, sex0*, solcasino*
проституток, наркоту и дипломы можно сразу убивать, возможно так же и казино
Это и сейчас реализовано с поиском по паттернам. У себя отбрасываю все вхождения с числом больше 1100 и результирующий файл получается ~800кб.
На счет ливнесс пробы в скрипте есть чекинг nxdomains. Он уменьшает размер на 400кб.
Может подойти к проблеме с другой стороны - составить частотную характеристику запрашиваемых на стороне прокси доменов? И не включать в pac домены с популярностью менее определенного порога. Технические способы помогут только отсрочить проблему, но не решить ее кардинально, ибо данный список будет только увеличиваться. Я сильно сомневаюсь, что оставшиеся после фильтрации какие-нибудь *azino также востребованы, как и топовые новостные ресурсы в известной зоне. Так зачем тащить этот мертвый груз? А порог можно сделать плавающим, на основе собираемой статистики, чтобы укладываться в лимиты. Если конечно ведется такая статистика.
а дайте пожалуйста референсный исходник, не обязательно ркновский. давайте сделаем референсный файл на 10000 строк и будем смотреть на его примере что лучше сжимает. я сделал для себя lzw компрессию и минификацию. https://p.thenewone.lol:8443/proxy.pac тут на одних переносах строки можно не слабо сэкономить. еще можно миллиард азино превратить в один *.азино
Что конкретно непонятно? Все ссылки есть в первом сообщении. В указанном бранче не выполняется обновление листа, и списки заморожены на дату коммита бранча, на них и тестируйте.
вот именно что списки, их поди еще там найди. а нужно один референсный исходный файл. типа “вот вам файл, задача сделать из него pac минимального размера без потери данных”.
Можно ли проверять User-Agent браузера? К примеру, пользователям IE и старых браузеров возвращать усечённый по объёму файл с наиболее популярными сайтами, а пользователям современных браузеров - полный?
Ещё вариант - некоторые зоны вынести сразу на прокси, к примеру, .com.ua и .co.il (новостные порталы Украины и Израиля), т.к. в этих зонах такое чувство, что гораздо больше заблоченных сайтов, чем не заблоченных.
Мы у себя не один год пользовались файлом https://antizapret.prostovpn.org/proxy.pac, заменяя в нем прокси-сервер на свой. Но antizapret.prostovpn.org заблокировали, поэтому прямой доступ стал невозможен. А через VPN предсказуемо получается “Your geoip is not RU, contact antizapret@prostovpn.org if you believe this is an error. THE SERVICE WORKS ONLY IN RUSSIA! Do not forget to include your IP address in the message.”
Ладно, решили делать proxy.pac сами, скачали/запустили Bitbucket. Но вот только результат 1.5Mb - нерабочий.
Что же касается исходной проблемы, мне кажется надо активнее пользоваться списками исключений. Например отдельным скриптом составлять списки того, чего нет в whois, коммитить исключения в репозиторий (чтобы скрипт обновления не тормозил). Да и зеркала всяких казино в какой-то момент можно будет начать исключать.