передаваемые на клиент данные на уровне ODBC драйвера? Ну то есть чтоб они прозрачно для клиентского ПО сжимались на сервере и разжимались на клиенте?
Одно время ssl compression работало, но сейчас включить его для openssl не так просто вроде. А как вы добились того, чтобы это предположытельно было полезно? Обычно постгрес настолько тормознее любой сети, что это всё прямо неинтересные мелочи.
а может онимеет в виду, что на сервере хранятся сжатыми и распаковываются на клиенте?
ну любая сеть как оказалось, понятие очень растяжимое. Просто гоняются справочники по воздуху 4G сети, которая может падать до скорости 2G, а содежимое справочников весьма компрессабельно - тексты и нулловые значения полей
не-не, место не вопрос, нужна максимальная скорость скачивания на клиента справочников, тут уже и денормализацию, и оперативы в 128 гигов на серваке впихнули, лишь бы поднять скорость, чтоб поменьше джоинов делать.
openvpn+compression. И не только для этого сжатия, да. Возможно, не openvpn, а не знаю, l2tp или tinc. Но вот реально, при такой физике без vpn никуда — а компрессия в vpn обычно есть.
если есть сервер приложений — на нём и пакуйте
компрессию из всяких впнов сейчас активно выпиливают за ради секурити
В openvpn он не-SSLный, что ужэ не так влияет на безопасность.
ну вот видел вроде в МССКЛ есть сжатие на уровне протокола, думал, мож и для постгри есть такое
Но почему? Вроде компрессия наоборот должна увеличивать энтропию сообщения?
опенвпн при включении компресси ругается в лог, что не сеурно :)
Если там сжымает сразу ключ и какой-то текст — то по длинне можно вычислить суммарную энтропию и оцэнить значения ключа. При этом текст часто известен (всякие заголовки протоколов).
ну вот хотя бы https://openvpn.net/security-advisory/the-voracle-attack-vulnerability/
Ну, то есть понятно, что это в любом случае side-channel... Но тогда вообще надо добивать до фиксированной скорости канала, чтобы вообще от него избавиться. В общем, всё хорошо в меру.
Обсуждают сегодня