Сжатие данных при передаче от браузера к серверу

[Jakeroid]

Есть ли смысл сжимать вышеописанными способами, если от браузера на сервер передаются изображения?

[CrazyAngel]

Jpg, Gif, PNG уже же сжаты

[SamDark]

По идее, нет. Большинство изображений и так пожаты.

[Fesor]

Имеет смысл передавать в бинарном виде, а не в виде Base64 строки. А вот пережимать там уже нечего будет.

[Nodge]

Как верно ответил Fesor, нужно передавать как бинарные данные. Вот небольшой пример для canvas.

[lleo_aha]

Если вы пытаетесь несколько изображений передать, то сейчас с этим отлично справляются HTML5 и FIleApi. Просто файлы надо отправлять по одному, а не пачкой (собственно «очередь» загрузки реализуется на JavaScript без проблем).

[WEBIVAN]

Как-то грустно получается у.15% Рунета (Opera 12, IE8,9), это работать не будет.
15%, ИМХО, это слишком много, что бы использовать в продакшн.

Часто данные не умещаются в один post запрос из-за ограничений nginx/apache/php/etc.

ИМХО, стоит, в первую очередь, решать увеличением максимального размера запроса на сервере. Сжали в 2 раза это хорошо, но станет данных больше и опять упретесь в эти же лимиты

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

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

[Fesor]

Ну для 15% можно сделать фэлбэк в виде стандартного POST запроса, а на остальных 85% экономить трафик и пользователя и сервера.

[Nodge]

15% Рунета могут загружать несжатые данные. В нашем проекте старые браузеры все равно пролетают из-за скорости работы, поэтому вопрос совместимости не стоял.
Нет проблемы увеличить максимальный размер запроса. Сжимая мы экономим трафик и ускоряем загрузку данных, особенно для пользователей с медленным соединением.

А приведенная цитата про алгоритм относится к обработке ключевых слов в нашем проекте. Само сжатие вносит относительно незаметный overhead.

[sneer]

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

[Abyasov]

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

[achekalin]

Есть подозрение, что подобный сервис не особо посещаем «всем Рунетом». Это не Вконтакт, и не mail.ru…

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

Ну а уж сделать fallback в что-то более обычное (чистый POST) — это уж просто вежливость, как ни крути )

[nzeemin]

помещалось в один http запрос

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

[spmbt]

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

[Nodge]

Спасибо за наводку, не знал.
В таком случае, если есть подписанный ssl сертификат, то действительно выгоднее использовать сжатие на уровне протокола. Работать должно быстрее и эффективнее.

[novoselov]

А можете сравнить финальный размер с lz4 в режиме hc
Javascript — github.com/pierrec/node-lz4
PHP — github.com/kjdev/php-ext-lz4

[novoselov]

Или github.com/chondl/lz4-js

[Nodge]

Для php не ставил, а рабочей реализации на браузерном javascript не видел. По ссылкам выше: первая для node.js, вторую можно запустить в браузере, но она не работает: lz4.uncompress(lz4.compress('test')) выдаст ошибку.

[consumer]

Попробуйте вместо base64 кодировать в шестнадцатиричную запись в виде строки, например, «ABC» -> байты с кодами 65 (0x41), 66 (0x42), 67 (0x43) -> шестнадцатиричная строка «414243», так чтобы каждому байту на входе соответствовало два символа на выходе.

Base64 кодирует каждые 3 байта на входе 4-мя на выходе. Это будет нарушать повторения во входных данных для алгоритма сжатия (на основе которых он и сжимает). Используя base64, вы понижаете качество сжатия. Например:

данные:«12345678901234567890»
base64: MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= (повторение потерялось)
hex: 3132333435363738393031323334353637383930 (повторение сохранилось)

данные:«123456789123456789»
base64: MTIzNDU2Nzg5MTIzNDU2Nzg5 (повторение сохранилось, потому что период кратен трем)
hex: 313233343536373839313233343536373839 (повторение сохранилось)

Или еще пример:
данные:12341234
base64: MTIzNDEyMzQ= (повторение потерялось)

данные:1234_1234
base64: MTIzNF8xMjM0 (повторение потерялось)

данные:1234__1234
base64: MTIzNF9fMTIzNA== (повторение сохранилось)

[Nodge]

Обновил статью и код примера. Экранировать unicode оказалось эффективнее, чем hex. И, тем более, чем base64. Спасибо за подсказку.

[achekalin]

> 7872 Кб (сжатие 84%)

Сжатие от исходных 9402 Кб будет не 84% (точнее, 83,73%), а как раз 100-83,73%=16,27%. Мы же говорим о сжатии, т.е. о величине, на которую размер уменьшается.

[Nodge]

Имеется ввиду сколько осталось от первоначального объема, как пишут в архиваторах.

[seriyPS]

Вы закодировали unicode строку в base64 и затем её сжимаете компрессором? Но это же жесть какая то… Зачем base64? Сразу 33% оверхед. Закодируйте какой-нибудь кодировкой и потом сразу в компрессор.

Ну и саму задачу на мой взгляд можно эффективнее чем за O(n^2) решить. Не могли бы кратко описать алгоритм?

[Nodge]

Обновил статью и код примера, заменил base64 на экранирование unicode символов. Получилось действительно намного эффективнее. Спасибо за подсказку.

Сам алгоритм обработки ключевиков выходит за рамки данной статьи. Возможно напишу о нем позже.

[seriyPS]

Попробуйте тогда уж вместо stringEscape такую конструкцию unescape(encodeURIComponent(data)).
Если интернет не врёт, то это самый простой способ получить UTF-8 из Unicode.
Если сконвертишь в cp1251, то можно ещё сэкономить.

[Nodge]

Функции escape и unescape обозначены как deprecated. Стоит ли их использовать в новых проектах?

[dimzon541]

рукалицо
github.com/beatgammit/gzip-js

[seriyPS]

github.com/beatgammit/gzip-js/blob/3bfba104cd3a678111e2bece04b31ae34416c2d3/package.json#L24 зависит от deflate

[dimzon541]

github.com/beatgammit/deflate-js

[dimzon541]

в догонку
npmjs.org/package/compressjs
на стороне php можно прикрутить
php.net/manual/en/book.v8js.php

[dimzon541]

ну и совсем напоследок
stuk.github.io/jszip/
www.php.net/manual/en/class.ziparchive.php

[dimzon541]

никак не остановлюсь ;)
github.com/imaya/zlib.js
www.php.net/manual/en/ref.zlib.php

минимальный оверхед
на стороне сервера нативная реализация (нефиг велосипед выдумывать)
использовать raw_deflate на клиенте
на сервере zlib_decode, параметр $max_decoded_len спасет от «gzip-бомбы»

собственно 20 минут гугления — думаю это меньше чем изобретать велосипед. надеюсь моя «рукалицо» теперь понятны.

[radist2s]

Может быть вы знаете, как такое детектить на стороне сервера?

[remal]

Что мешает воспользоваться готовым бинарным протоколом, который ко всему прочему еще и тормозить на сжатии не будет? Тем же Thrift, например?