У меня медленное коммутируемое соединение, но у меня есть root-доступ к быстрому серверу.
В настоящее время я использую ssh v2 для подключения к серверу с включенным сжатием в ~/.ssh/config. Однако это использует только уровень gzip 6 (как упомянуто здесь https://serverfault.com/questions/388658/ssh-compression/.
Однако можно использовать лучшие алгоритмы (например, xzip с -e9 или 7zip с -mx=9), используя каналы, как указано здесь [https://serverfault.com/a/586739/506887]. Пример в этом ответе:
ssh ${SSH_USER}@${SSH_HOST} "
echo 'string to be compressed' | gzip -9
" | zcat | echo -
сжимает одну строку, используя xzip и каналы на удаленном сервере.
1) Я хотел бы сделать это (сжать с помощью xzip) для всего трафика. Как это можно сделать.
2) Чтобы сохранить данные, когда я запускаю Firefox на своем клиенте, я использую прокси-сервер socks v5 с ssh, чтобы воспользоваться сжатием.
ssh -D 8123 -C -v -N root@myserver
и я указываю firefox на socks://localhost:8123. Опять же, это с использованием gzip уровня 6. Можно ли аналогичным образом изменить этот пример, чтобы использовать xzip или 7zip.
Я знаю, что преимущество в пропускной способности при использовании xzip по сравнению с gzip может быть незначительным для одного соединения. Но я надеюсь, что экономия пропускной способности со временем достигнет значительной суммы.
Спасибо
это кажется верным. В таком случае есть ли альтернатива использованию труб? Я попробовал mosh, но это не сильно помогло с пропускной способностью (хотя соединение дает более надежное). Это правда, что https можно значительно сжать, и в настоящее время это большая часть веб-трафика. Но мне все равно было бы полезно сжать сеансы входа в систему vanilla ssh, так как мой носитель данных взимает плату за Мб.





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