Режим компрессии данных что это?

Скоростная отказоустойчивая компрессия (Продолжение)

Данная статья уже вторая в теме о скоростной компрессии данных. В первой статье был описан компрессор работающий со скоростью 10Гбайт/сек. на одно процессорное ядро (минимальное сжатие, RTT-Min). Этот компрессор, уже внедрен в оборудование криминалистических дубликаторов для скоростного сжатия дампов носителей информации и усиления стойкости криптографии, также он может применяться для сжатия образов виртуальных машин и своп файлов оперативной памяти при сохранении их на быстродействующих SSD накопителях.

В первой статье также анонсировалась разработка алгоритма компрессии для сжатия резервных копий HDD и SSD дисковых накопителей (среднее сжатие, RTT-Mid) с существенно улучшенными параметрами сжатия данных. К настоящему времени этот компрессор полностью готов и данная статья именно о нем. Компрессор, реализующий алгоритм RTT-Mid обеспечивает степень сжатия сравнимую со стандартными архиваторами типа WinRar, 7-Zip, работающих в скоростном режиме. При этом скорость его работы как минимум на порядок выше.

Скорость упаковки/распаковки данных является критическим параметром определяющим область применения технологий компрессии. Вряд ли кому придет в голову сжимать терабайт данных со скоростью 10-15 МегаБайт в секунду (именно такая скорость архиваторов в стандартном режиме компрессии), ведь на это придется затратить почти двадцать часов при полной загрузке процессора… С другой стороны тот же терабайт можно скопировать на скоростях порядка 2-3ГигаБайт в секунду минут за десять. Поэтому сжатие информации большого обьема актуально если его производить со скоростью не ниже скорости реального ввода/вывода.

Для современных систем это не менее 100МегаБайт в секунду. Такие скорости современные компрессоры могут выдавать только в режиме «fast». Вот в этом актуальном режиме и будем проводить сравнение алгоритма RTT-Mid с традиционными компрессорами.

Сравнительное тестирование нового алгоритма компрессии

Компрессор RTT-Mid работал в составе тестовой программы. В реальном «рабочем» приложении он работает значительно быстрее, там грамотно используется многопоточность и применяется «нормальный» компилятор, а не С#.

Поскольку используемые в сравнительном тесте компрессоры построены на разных принципах и различные типы данных сжимают по разному, то для объективности теста использовался метод замера «средней температуры по больнице»… Был создан файл посекторного дампа логического диска с операционной системой Windows 10, это наиболее естественная смесь различных структур данных реально имеющаяся на каждом компьютере.

Сжатие этого файла позволит провести сравнение по скорости и степени компрессии нового алгоритма с самыми продвинутыми компрессорами используемыми в современных архиваторах. Вот этот файл дампа: Файл дампа сжимался компрессорами РТТ-Mid, 7-zip, WinRar. Компрессор WinRar и 7-zip были выставлены на максимальную скорость работы.

Работает компрессор 7-zip:

Он грузит процессор на 100%, при этом средняя скорость чтения исходного дампа около 60 МегаБайт/сек.

Работает компрессор WinRar:

Ситуация аналогичная, загрузка процессора практически 100%, средняя скорость чтения дампа около 125 МегаБайт/сек. Как и в предыдущем случае, скорость работы архиватора ограничена возможностями процессора.

Теперь работает тестовая программа компрессора RTT-Mid:

Скриншот показывает, что процессор загружен на 50% и простаивает остальное время, потому как некуда выгружать скомпрессированные данные. Диск выгрузки данных (Диск 0) загружен практически полностью. Скорость чтения данных (Диск 1) сильно скачет, но в среднем более 200 МегаБайт/сек. Скорость работы компрессора ограничивается в данном случае возможностью записи сжатых данных на Диск 0. Теперь степень сжатия получившихся архивов: Видно, что компрессор RTT-Mid лучше всех справился с компрессией, архив созданный им на 1,3 ГигаБайта меньше архива WinRar и на 2,1ГигаБайта меньше архива 7z. Время затраченное на создание архива:

• 7-zip – 26минут 10 секунд;
• WinRar – 17минут 40 секунд;
• RTT-Mid – 7 минут 30 секунд.

Таким образом, даже тестовая, не оптимизированная программа, используя алгоритм RTT-Mid, смогла более чем в два с половиной раза быстрее создать архив, при этом архив оказался существенно меньшим нежели у конкурентов…

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

Но только на процессорах с поддержкой AVX-2, без поддержки этих инструкций компрессор не работает, и не тестируйте алгоритм на старых процессорах AMD, они медленные в части выполнения AVX команд…

Используемый метод компрессии

В алгоритме используется метод индексирования повторяющихся фрагментов текста в байтовой грануляции. Такой метод сжатия известен давно, но не использовался, поскольку операция поиска совпадений была очень затратна по необходимым ресурсам и требовала гораздо более времени нежели построение словаря. Так что алгоритм RTT-Mid является классическим примером движения «назад в будущее»… В компрессоре РТТ используется уникальный скоростной сканер поиска совпадений, именно он позволил ускорить процесс компрессии.

Сканер собственного изготовления, это «моя прелесть…», «цены он немалой, потому как полностью ручной работы» (написан на ассемблере). Сканер поиска совпадений выполнен по двухуровневой вероятностной схеме, сначала сканируется наличие «признака» совпадения, и только после выявления «признака» в этом месте запускается процедура обнаружения реального совпадения. Окно поиска совпадений имеет непредсказуемый размер, зависящий от степени энтропии в обрабатываемом блоке данных.

Для полностью случайных (несжимемых) данных оно имеет размер мегабайт, для данных имеющих повторы всегда имеет размер больше мегабайта. Но многие современные форматы данных несжимаемы и «гонять» по ним ресурсоемкий сканер бесполезно и расточительно, поэтому в сканере используется два режима работы. Сначала ищутся участки исходного текста с возможными повторами, эта операция проводится тоже вероятностным методом и выполняется очень быстро (на скорости 4-6 ГигаБайт/сек). Затем участки с возможными совпадениями обрабатываются основным сканером.

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

Все это позволило получить в компрессоре РТТ-Mid степень сжатия, сопоставимую с компрессорами выполненными по словарному методу, но работающий гораздо быстрее.

Скорость работы нового алгоритма компрессии

Если компрессор работает с монопольным использованием кеш памяти (на один поток требуется 4 МегаБайта), то скорость работы колеблется в диапазоне 700-2000 Мегабайт/сек. на одно процессорное ядро в зависимости от типа сжимаемых данных и мало зависит от рабочей частоты процессора. При многопоточной реализации компрессора эффективная масштабируемость определяется обьемом кеш-памяти третьего уровня. К примеру, имея «на борту» 9 МегаБайт кеш-памяти запускать более двух потоков компрессии нет смысла, скорость расти от этого не будет.

Но при кеше в 20 МегаБайт можно уже запускать пять потоков компрессии. Также существенным параметром определяющим скорость работы компрессора становится латентность оперативной памяти. Алгоритм использует рандомные обращения к ОП, часть из которых не попадает в кеш память (около 10%) и ему приходится простаивать, ожидая данные из ОП, что снижает скорость работы. Существенно влияет на скорость компрессора и работа системы ввода/вывода данных. Запросы к ОП от ввода/вывода блокируют обращения за данными со стороны ЦП, что также снижает скорость компрессии.

Эта проблема существенна для ноутбуков и десктопов, для серверов она менее существенна благодаря более продвинутому блоку управления доступом к системной шине и многоканальной оперативной памяти. Везде по тексту в статье идет речь об компрессии, декомпрессия остается за рамками этой статьи поскольку там «все в шоколаде». Декомпрессия проводится значительно быстрее, и ограничивается скоростью ввода/вывода. Одно физическое ядро в одном потоке спокойно обеспечивает скорости распаковки на уровне 3-4 Гигабайта/сек.

Это связано с отсутствием в процессе распаковки операции поиска совпадений, которая «сжирает» основные ресурсы процессора и кеш-памяти при компрессии.

Надежность хранения сжатых данных

Как следует из названия всего класса программных средств использующих компрессию данных (архиваторы), они предназначены для длительного хранения информации, не годами, а столетиями и тысячелетиями… За время хранения носители информации теряют часть данных, вот пример: Этому «аналоговому» носителю информации тысяча лет, некоторые фрагменты утеряны, но в целом информация «читаема»… Ни один из ответственных производителей современных цифровых систем хранения данных и цифровых носителей к ним не дает гарантий полной сохранности данных более чем на 75 лет. И это проблема, но проблема отложенная, решать ее будут наши потомки… Системы хранения цифровых данных могут терять данные не только через 75 лет, ошибки в данных могут появиться в любое время, даже во время их записи, эти искажения пытаются минимизировать, используя избыточность и корректируя системами коррекции ошибок. Избыточность и системы коррекции могут восстановить утраченную информацию далеко не всегда, а если и восстанавливают, то нет гарантий, что операция восстановления прошла корректно. И это тоже большая проблема, но не отложенная, а текущая. Современные компрессоры используемые для архивации цифровых данных построены на различных модификациях словарного метода и для таких архивов утеря фрагмента информации будет фатальным событием, существует даже устоявшийся термин для такой ситуации — «битый» архив… Низкая надежность хранения информации в архивах со словарным сжатием связана со структурой сжатых данных. Информация в таком архиве не содержат исходный текст, там хранятся номера записей в словаре, сам же словарь динамически модифицируется текущим сжимаемым текстом. При утере или искажении фрагмента архива все последующие записи архива невозможно идентифицировать ни по содержимому, ни по длине записи в словаре, поскольку непонятно чему соответствует номер словарной записи. Восстановить информацию из такого «битого» архива невозможно. Алгоритм RTT построен на основе более надежного метода хранения сжатых данных. В нем применяется индексный метод учета повторяющихся фрагментов. Такой подход к компрессии позволяет минимизировать последствия искажения информации на носителе, и во многих случаях автоматически корректировать искажения возникшие при хранении информации. Это связано с тем, что архивный файл в случае индексного сжатия содержит два поля:

• поле исходного текста с удаленными из него участками повтора;
• поле индексов.

Критически важное для восстановления информации поле индексов, не велико по размеру и его можно дублировать для надежности хранения данных. Поэтому даже если будет утерян фрагмент исходного текста или индексного массива, то вся остальная информация будет восстанавливаться без проблем, как на картинке с «аналоговым» носителем информации.

Недостатки алгоритма

Достоинств не бывает без недостатков. Индексный метод компрессии не сжимает повторяющиеся последовательности малой длины. Это связано с ограничениями индексного метода. Индексы имеют размер не менее 3 байт и могут быть размером до 12байт. Если встречается повтор с меньшим размером чем описывающий его индекс, то он не учитывается, как бы часто такие повторы не выявлялись в сжимаемом файле. Традиционный, словарный метод компрессии, эффективно сжимает множественные повторы малой длины и поэтому достигает большего коэффициента сжатия нежели индексная компрессия.

Правда это достигается за счет высокой загруженности центрального процессора, чтобы словарный метод начал сжимать данные эффективнее индексного метода ему приходится снижать скорость обработки данных до 10-20 мегабайт в секунду на реальных вычислительных установках при полной загрузке ЦП. Такие низкие скорости неприемлемы для современных систем хранения данных и представляют больше «академический» интерес, нежели практический. Степень сжатия информации будет существенно повышена в следующей модификации алгоритма РТТ (RТТ- Max), он уже в разработке.

Так что как всегда, продолжение следует…

• сжатие данных
• алгоритмы сжатия
• компрессия данных

Хабы:

• Программирование
• IT-инфраструктура
• Алгоритмы
• Сжатие данных

Источник: https://habr.com/ru/post/479888/

Сжатие трафика на Андроид — как улучшить обмен данными при низкой скорости соединения?

Несмотря на развитие сетей третьего и четвертого поколений (3G и 4G), бывают такие ситуации, когда интернет нужен позарез, а вы находитесь в дороге или вдали от цивилизации, где нет соты, обеспечивающей мощный и стабильный сигнал.

Что же предпринять в таком случае? Одно из решений – использовать браузер с режимом сжатия трафика (другими словами, компрессией). Благодаря ему, можно пользоваться интернетом даже при слабом и нестабильном EDGE-подключении с передачей трафика в несколько десятков килобайт/сек.

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

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

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

Отличный способ выйти из такого неудобного положения, – это использовать сжатие трафика. Ниже мы поделимся с вами некоторыми нюансами, как использовать данный механизм при работе в сети.

Браузеры, в которых доступно сжатие трафика (компрессия)

Функция компрессии данных при обмене входящим и исходящим трафиком встроена лишь в 3 актуальных программных продуктах для веб-серфинга, а именно в Google Chrome, Opera и Opera Mini. Режим компрессии в каждом из этих приложений имеет свои особенности, на них мы подробно и остановимся в дальнейшем.

Google Chrome

Этот навигатор по праву считается одним из лучших. Среди массы прочих достоинств он обладает одной очень полезной для нас функцией, а именно, — сжатием трафика. Как ее активировать? Установим приложение на смартфон.

Официальная страница в Google Play

Зайдем на веб-страницу проекта в магазине Google и нажмем кнопку «Установить».

Дальше все, как обычно: соглашаемся с разрешениями, ждем пару минут и запускаем программу.

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

В следующей форме нужно выбрать аккаунт, для которого будет выполнена синхронизация Chrome, а именно: закладок, вкладок, истории посещений, настроек и пр. Отмечаем соответствующий аккаунт, с которым вы будете работать. При желании этот пункт можно и пропустить.

Если вы хотите понаблюдать за тем, как происходит процесс синхронизации, кликните кнопку «Настройки».

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

В ниспадающем списке выберите пункт «Настройки».

В нижней части меню параметров обратите внимание на пункт «Экономия трафика». По умолчанию он выключен.

Активируйте эту функцию.

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

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

По существу, механизм сжатия работает довольно хорошо: в результате получаем более 50% объема трафика от исходного. Также все страницы отображаются правильно, контролы на своих местах, скрипты тоже работают корректно. Но поговорим о других браузерах, обладающих аналогичной функциональностью.

Opera

Официальная страница на Google Play

Мобильная версия Opera ни в чем не уступает, а в некоторых аспектах даже превосходит свой десктопный вариант. Установим браузер на устройство. Процедура абсолютно такая же.

При первом запуске появляется форма с приглашением начать работу. Следуем дальше, нажав кнопку «Продолжить».

После небольшого введения попадаем на главную форму программы. Щелкнем на логотип компании-производителя в правом нижнем углу.

Чтобы детально настроить этот режим, перейдите в меню Настройки и выберите пункт «Экономия трафика».

Какие настройки нам доступны? Прежде всего, мы можем изменить качество загружаемых картинок от низкого до высокого. Хардкорщики вправе отключить отображение картинок на сайтах вовсе. Еще одна опция – это сжатие видео (отличный способ сэкономить деньги и трафик любителям стриминговых сервисов и потокового видео (Twitch, ).

После тестирования технологии компрессии в Opera, можно сделать вывод, что в сравнении с Хромом норвежский веб-навигатор более успешно справляется с данной задачей. Процент сжатых данных доходит до 60-65 процентов, что нисколько не сказывается на корректной HTML-разметке и поддержке стандартов для визуализации контента. Исполнение скриптов также не пострадало.

Opera Mini

Официальная страница на Google Play

Специально для тех, кто смотрит в сторону минимализма в вещах и технологиях, Opera Software создала облегченную версию своего флагманского продукта Opera Mini. Мало того, что он занимает мизерные 3 Мб, так еще и в интересующей нас функции компрессии данных обходит своего старшего брата.

Механизм сжатия трафика в этом приложении работает абсолютно другим образом. В Opera Mini обработка веб-контента (текста, графики, динамических вставок и роликов) происходит на удаленном прокси-сервере компании. Клиентское же устройство принимает поток данных уже полностью в обработанном виде. Такая схема позволяет использовать Opera Mini даже на наименее производительных смартфонах и планшетах, а экономия доходит до 90 процентов всей проходящей через девайс информации.

Чтобы воспользоваться этой функциональностью, нужно скачать Opera Mini на телефон и инсталлировать его.

После первой загрузки соглашаемся с лицензией и входим в браузер.

Нововведений здесь масса, но нас интересует исключительно процесс компрессии(сжатия). Как его активировать и настроить?

Щелкнем на логотипе в том же самом нижнем правом углу и нажмем на круговой диаграмме режима компрессии в верхней части ниспадающего меню.

При задействовании этого механизма уровень компрессии достигает тех самых обещанных 90%. Но так как весь процессинг осуществляется на сервере, пришлось пожертвовать точностью отображаемого на веб-странице контента. Не все контролы на сайтах находятся там, где надо, а поддержка HTML5, CSS и JS и вовсе не гарантируется.

Помимо этого, в экстремальном режиме можно гибко кастомизировать размер и перенос текста на новую строку, выбрать протокол для обмена данными, а также задать пару других параметров.

В эффективности алгоритма сжатия можно убедиться, посетив пару сайтов и взглянув на статистику еще раз.

Эксклюзивной фишкой Opera Mini является детализированная диаграмма с показателями обработки контента за последние 5 дней. Она вызывается по нажатию кнопки «Подробнее» в настройках компрессии. Здесь же можно переключать режимы.

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

Источник: https://livelenta.com/szhatie-trafika-na-android-kak-uluchshit-obmen-dannymi-pri-nizkoj-skorosti-soedineniya.html

Mozilla Janus — технология компрессии трафика от разработчиков Firefox

Длительное время без громких анонсов Mozilla работала над технологией компрессии трафика Janus, и хотя финальная версия этого сервиса все еще не готова, им уже можно воспользоваться, и посмотреть, что же он предлагает. Как и в случае с Opera Turbo, технология Mozilla в первую очередь предназначена для мобильных устройств и мобильного интернета, однако может быть использована и на обычных ПК.

Для того чтобы воспользоваться Mozilla Janus необходимо скачать и установить Firefox не ниже 33 версии на ПК (Nightly билд можно найти здесь), либо не ниже 32 версии на мобильное устройство, а также расширение Janus Proxy Configurator от Mozilla. Последнее не требует перезапуска браузера и работает сразу после инсталляции. Мы рассмотрим в статье десктопную версию Mozilla Janus.

Что такое Mozilla Janus

Janus, как и другие сервисы компрессии трафика, представляет собой прокси-сервер, принимающий от пользователя запросы по протоколу SPDY и передающий в браузер не оригинальный, а уже сжатый код страницы, изображений, анимации и т.д.

Основных задач, поставленных перед разработчиками Janus, было несколько. Это снижение времени загрузки страниц, снижение требований к пропускному каналу, увеличение защищенности пользователей и повышение отзывчивости сайтов.

Все это достигается благодаря некоторым модификациям, которые прокси-сервер проводит с содержимым страниц.

Компрессия изображений

Один из наиболее очевидных и популярных способов уменьшения страниц сводится к компрессии изображений. В этом Mozilla Janus работает несколько иначе по сравнению с Opera Turbo.

Эффективность сжатия Janus будет ниже чем у Turbo, однако на изображениях практически не будет видно артефактов, заметных практически на всех без исключения изображениях, обработанных прокси-серверами Opera.

Сжатие текста и кода

Компрессия текста (js, html) и потоков (gzip, bzip2, lzma) дает меньший выигрыш по сравнению с компрессией изображений, однако чистые страницы без картинок и других мультимедиа элементов могут быть уменьшены в несколько раз, что будет особенно заметно на медленных мобильных соединениях.

Кеширование

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

Префетчинг

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

Анонимность

Помимо этого, сервера Mozilla Janus также выступают в роли анонимизаторов, поскольку обращаются к сайтам из под собственного IP адреса, а не из под IP адреса пользователя.

Блокирование Flash

Janus также блокирует Flash элементы на странице, оставляя вместо них пустые прямоугольные области. Логично было бы предположить, что после клика на прямоугольниках их содержимое будет загружено, однако этого не происходит, в отличие от Opera Turbo.

Блокирование рекламы

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

Режим чтения

Последняя особенность, видимо, касается исключительно мобильной версии Firefox, поскольку не была замечена на ПК. Она заключается в том, что некоторые страницы Janus автоматически форматирует в простой стиль для более удобного чтения. Это значит, что страница будет оптимизирована: с нее уберут лишние элементы, увеличат размер шрифта и отформатируют содержимое таким образом, чтобы его можно было читать как книжную страницу. Подобный режим существует и в Opera, однако лишь в мобильном браузере Opera Mini.

Отличия от Opera Turbo

У Mozilla Janus есть несколько функций, отличающих этот проект от Opera Turbo. Это компрессия анимации, сжатие изображений на https страницах, и режим частичной передачи файлов.

Сжатие Анимации

Сжатие анимации одна из наиболее интересных возможностей Janus, позволяющая конвертировать gif изображения в видеофайлы, сжатые кодеком h264/webm. Посмотреть пример подобной конверсии можно на сайте gfycat.com, преобразующем gif анимации в html5 видео со значительной компрессией. Как правило коэфициент сжатия составляет приблизительно10:1, вследствие чего анимация загружается гораздо быстрее, а не покадрово, и требует на порядок меньше трафика для передачи. По умолчанию сжатие анимации отключено. Активировать его можно на в настройках Mozilla Janus.

Сжатие изображений на https страницах

Как известно, некоторые типы расширений не могут работать на защищенных https страницах. К ним относится и Opera Turbo, не умеющая сжимать https сайты. Объясняется это тем, что на прокси-сервера Opera в таком случае будет попадать содержимое страниц, что недопустимо для сайтов онлайн-банкинга, на которых пользователь передает свой пароль для работы с финансами.

Mozilla Janus частично обходит это ограничение. Само содержимое https страницы по-прежнему передается от веб-сайта к пользователю напрямую, а вот изображения на странице сжимаются по обычной процедуре, через сервера Janus, что позволяет экономить трафик даже при посещении защищенных сайтов.

Частичная передача ранее загруженных файлов

Режим частичной передачи файлов базирует на коде zsync. Если на компьютере пользователя находится устаревшая версия файла (как правило речь идет о css и js файлах), то zsync может отправить на компьютер не целый файл, а лишь обновленную часть, которая во многих случаях составляет лишь небольшую долю от общего размера файла..

Сравнение с Opera Turbo

Поскольку десктопная версия Opera Turbo не отображает статистику экономии трафика, в отличие от мобильной версии, то остановимся на тех моментах, которые можно сравнить.

Mozilla Janus, как и Opera Turbo, включается и выключается в два клика, после нажатия на иконке расположенной на панели браузера. Расширение Mozilla имеет несколько дополнительных, по умолчанию отключенных, настроек: блокирование рекламы, конвертацию анимации в видео, оптимизацию для снижения задержки, а не размера страницы. В последнем режиме Mozilla Janus избирательно компрессирует лишь те элементы страницы, на обработку которых тратится мало времени, что позволяет повысить приоритет времени загрузки страницы вместо экономии трафика.

https://www.youtube.com/watch?v=lzg8xAZpo_0

Как уже упоминалось, Opera Turbo сильнее сжимает изображения в связи с чем практически на всех изображениях заметны артефакты. Mozilla Janus почти не ухудшает качество изображений, однако и экономия трафика при этом достигается более скромная.

Что касается практического использования Mozilla Janus, то в среднем коэфициент экономии составляет 30%-40%, но может сильно увеличиваться в зависимости от содержимого веб-страниц. Например наличие gif анимаций позволяет Janus сжимать трафик вплоть до 5% от исходного размера.

Поскольку Mozilla Janus все еще находится в ранней стадии разработки, скорее всего Mozilla запустила не так много прокси-серверов, занимающихся компрессией трафика, по всему миру. Это заметно при открытии отечественных сайтов, которые видимо обрабатываются удаленными серверами вследствие чего открываются с очевидной задержкой. На иностранных сайтах задержка если и существует, то не столь заметна. Нет ее и при использовании Opera Turbo, поскольку сервера Opera видимо лучше распределены по континентам.

Итоги

Mozilla Janus — это интересный сервис компрессии данных от разработчиков Firefox. Благодаря некоторым нововведениям, например конвертированию анимации в видеофайлы и сжатию изображений на https страницах, Mozilla Janus может составить серьезную конкуренцию своим соперникам от Opera и Chrome, и на данный момент выглядит потенциально более перспективным решением.

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

Источник: https://itc.ua/articles/mozilla-janus-tehnologiya-kompressii-trafika-ot-razrabotchikov-firefox/