Если у вас есть сервер с большим, чем на вашей машине, лимитом трафика, а вы много скачиваете на свою локальную машину, то для экономии трафика при загрузках используйте coproxy. Файл будет качаться сервером и передаваться сжатым на клиент, где будет декомпрессироваться. Все подробности в README в архиве.
Далеко не каждый фильм хорошо пожат.
Архиватором ты его все равно не поймёшь, там же сжатие с потерями - архиватору там делать нечего. Я даже сомневаюсь что пару килобайт выиграешь, скорее наоборот архив будет больше за счёт накладных расходов на сам архив. Дома буду даже проверю.
Ну, есть еще образы систем, они жирные.
Сильно специфичное применение тогда у твоей тулзы. На границе с полным ненужно все равно. Если что и нужно, то прокся а ля Опера/Опера мини, но все равно сильно ограничено
Если выключить HTTPS в браузере, то не такое уж и сильно специфичное.
Лучше бы делал проксю которая вообще весь трафик жмёт, навроде того что в мобильной Опере, но для любого браузера. Такое норм на сильно лимитных тарифах, чисто выйти в интернет почитать без видео, или в роуминге
Вот тут люто поркчую, открытый аналог оперы мини, пригодился бы, тут аналоговнет. Только суть не только в сжатии трафика, и к любому браузеру прикрутить такое вряд ли получится, т.к. у оперы мини по сути браузерный движок на сервере работает (и tls там же терминируется, кстати), а клиенту передаётся уже итоговый отрендеренный результат в оптимизированном виде (со своим форматом разметки), такой вот тонкий клиент. Короче, надо запилить что-то типа browsh, где браузерный движок работает на сервере, а клиенту даётся итоговый результат, но только не в консольке, а с нормальными шрифтами (пусть из стандартной поставки) и картинками (опционально - пожатыми). Надо это даже не столько для экономии трафика, сколько чтобы не грузить и исполнять у себя сотни мегабайт js и прочий современный веб-содом, которому надо последний процессор, и десятки ГБ памяти для одного браузера. А просто сжатие было, например, в opera mobile, которая работала локально (на presto ещё), и она даже что-то жала (когда https не было повсеместно), но опера-мини была эффективней, и по потреблению трафика в том числе. Кстати и у гугла тоже было такое для мобильного хромога, можешь погуглить “Data Compression Proxy”, его к другим браузерам (десктопным) прикручивали, но опять же, по тем же причинам до оперы-мини такому далеко, да и с https в любом случае сошло на нет.
Мне лень было реализовывать SOCKS и заботиться о большем кол-ве вещей, ибо это не запрос-ответ HTTP. Большая часть трафика в Интернете — HTTP, что у меня и реализовано. Если сайт редиректает HTTP на HTTPS, то будет прекрасно работать всё, но надо именно URL с HTTP использовать, ибо иначе я не смогу понять, какой сайт запрашивает клиент.
Тем более, сжатия даже в том случае, если сайт редиректает HTTP на HTTPS, можно добиться только на 7-м уровне.
В современном вебе почти весь трафик уже передается сжатым, веб-серверы отдают данные сжатые gzip/deflate, deflate нынче даже в websocket поддерживается, веб-кодерам ничего не нужно делать, потому как это фишка сервера и включается параметром.
Мобильная опера времен JavaME погоняла DOM под мобильные устройства с малым объемом памяти и пережимала картинки в шакальное качество, и наверное даже делала Server-Side Rendering чтоб не перекладывать на дохлое мобильное устройство исполнение JS для отображения сайта. Короч, опера делала много всякой работы.
Ну так вот с этим самым функционалом и было бы неплохо. Разве что server-side рендеринг лишний по причине достаточной мощности устройств. А пережимание в шакала весьма было бы неплохо, с религулировкой количества шакалов в изображении