Почему Firefox является настолько медленным по SSH?

Chrome не является открытым исходным кодом...

Если Вы хотите установить Хром на F17, необходимо использовать этот repo:

http://repos.fedorapeople.org/repos/spot/chromium-stable/

Вот полный tuto: https://fedoraproject.org/wiki/Chromium

Ps: почему хром не находится в Fedora: http://ostatic.com/blog/making-projects-easier-to-package-why-chromium-isnt-in-fedora

Приятного отдыха

39
01.03.2015, 01:28
8 ответов

Настройки SSH по умолчанию делают для довольно медленного подключения. Вместомодайте следующее:

ssh -YC4c arcfour,blowfish-cbc user@hostname firefox -no-remote

Используемые параметры:

-Y      Enables trusted X11 forwarding.  Trusted X11 forwardings are not
         subjected to the X11 SECURITY extension controls.
 -C      Requests compression of all data (including stdin, stdout,
         stderr, and data for forwarded X11 and TCP connections).  The
         compression algorithm is the same used by gzip(1), and the
         “level” can be controlled by the CompressionLevel option for pro‐
         tocol version 1.  Compression is desirable on modem lines and
         other slow connections, but will only slow down things on fast
         networks.  The default value can be set on a host-by-host basis
         in the configuration files; see the Compression option.
 -4      Forces ssh to use IPv4 addresses only.
 -c cipher_spec
         Selects the cipher specification for encrypting the session.

         For protocol version 2, cipher_spec is a comma-separated list of
         ciphers listed in order of preference.  See the Ciphers keyword
         in ssh_config(5) for more information.

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


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

25
27.01.2020, 19:35

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

ssh -vv -ND 8080 user@yourserver

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

В Firefox , перейдите к предпочтениям -> Advanced -> Network -> Соединение: Настройки.

Выберите Ручная конфигурация прокси и добавьте SOCKS V5 Proxy:

 SOCKS Host:   localhost    Port 8080

Проверьте свой новый IP, навигацию на E.g. http://whatismyipaddres.com/ .

Вы можете использовать дополнение Firefox, подобное Poxy Proxy , чтобы динамически переключать прокси.

17
27.01.2020, 19:35

Еще одна вещь, которая улучшит ваш просмотр по ssh, это включение трубопроводов в Firefox. Откройте about:config и измените параметр network.http.pipelining на true.

0
27.01.2020, 19:35

Хорошо, поэтому вся моя установка была беспорядком. PostConf все еще был настроен для записи почты на / var / mail / имя пользователя Отказ Довекот «Отправлено» и «Проект» Письма были сохранены в / Home / имя пользователя / почта / с использованием Mbox

, поэтому я повторно перенастроил все это и решил использовать Maildir Для этого я перенастроил постфикс, делая

postconf -e "home_mailbox = Maildir/"
postconf -e "mailbox_command ="

и изменил переменную Dovecot Mail_location (в Dovecot.conf)

mail_location = maildir:~/Maildir

и все, кажется, хорошо, «почта» больше не беспокоит с бесполезными заметками и конверсией. Похоже, он только ищет почту в / var / mail / username. Я мог бы неправиться, я не эксперт по почте.

, надеюсь, когда-нибудь это может помочь кому-то.

-121--244237-

Firefox Так медленно по SSH, потому что новые сборки Firefox позволяют несколько экземпляров. Если у вас проблемы пропускной способности, используйте светлый браузер, такой как DILLO, и вы не замечаете скорость соединения.

2
27.01.2020, 19:35

Одна из самых больших проблем при удаленном запуске некоторых X-клиентов - это X-протокол, а не накладные расходы! X-протокол требует много пинг-понга между клиентом и сервером, что абсолютно убивает производительность в случае удаленных приложений.

Попробуйте что-нибудь вроде "x2go" (который также идет по ssh с настройками по умолчанию) в сравнении с этим firefox "летает"!

Несколько дистрибутивов предоставляют пакеты x2go из коробки, например, для тестирования Debian или в Stable-Backports. Но если нет, см. http://wiki.x2go.org/doku.php/download:start , они предоставляют готовые бинарные пакеты/репозитории для многих дистрибутивов. Вы должны установить x2goclient (на компьютер, где вы хотите "использовать" Firefox) и x2goserver (на компьютере, где должен работать Firefox), затем вы можете настроить сеансы для приложений single X для полного просмотра рабочего стола и т.д. Само соединение происходит по ssh. Это действительно замечательный инструмент :)

Чтобы использовать его, вы запускаете "x2goclient", он запускает графический интерфейс, где вы можете создать новую сессию: вы предоставляете dns имя сервера, порт, данные ssh и т.д., а затем вы выбираете "тип сессии", т.е., если вы хотите полный удалённый рабочий стол KDE или GNOME, например, или просто "единственное приложение", и там вы вводите "firefox".

33
27.01.2020, 19:35

Я знаю, что этот пост очень старый, но он помог мне преодолеть медлительность Firefox из-за SSH, установив следующее вabout:config

gfx.xrender.enabled = true

Примечание.:Начиная с Firefox 47 значение по умолчанию стало False.

12
20.08.2021, 12:37

X11 — устаревший протокол. Например, если программа снова и снова записывает букву «А» в одно и то же место, она будет передаваться снова и снова. Многие современные графические интерфейсы имеют тенденцию перерисовывать то, что не изменилось, и X11 с радостью ретранслирует каждый вывод атомарного экрана -. Другими словами, он передает не пиксели, а команды. Это противоположно тому, как работают VNC и Teamviewer, которые в основном передают пиксели. Это также приводит к частично синхронной операции, когда одна команда должна ждать завершения другой команды.

SSH потребляет огромное количество ресурсов ЦП и не поддерживает многопоточность.Например, мой сервер использует SSH на одном ядре на 100%, но это соответствует примерно 20 МБ/с несжатых данных и около 5 МБ/с сжатых данных для X11.

Firefox крайне недружелюбен к X11. Он редко использует команды -, которые X11 мог бы эффективно обрабатывать -, но в основном это небольшие и плохо сжимаемые растровые изображения, которые он упаковывает в операции с битовыми плоскостями X11. Сочетание двух вещей, которые никогда не должны сближаться в любом случае. В худшем случае :Любая небольшая анимация. Даже анимированный GIF размером 64x64 пикселей может буквально заморозить ваше соединение с Firefox.

Тем не менее, давайте погрузимся глубже.

На высокоскоростной линии -, например. Сжатие 100 Мбит или выше -обычно больше бремя, чем кость. Ваш пробег может отличаться. Попробуйте ssh с "-C". С SSH2 больше нет ручного выбора уровня сжатия, вы застряли с чем-то сравнимым с «gzip -3» или должны выполнить какое-то хитрое туннелирование. Можно получить более быстрое сжатие, используя довольно быстрое «lzop -1», или лучшее сжатие, используя «xz -9e». Я играл с "lzop -1" около десяти лет назад, и результаты были невпечатляющими.

Скорость вашего криптовещания во многом зависит от вашего процессора. См.https://possiblelossofprecision.net/?p=2255для простого способа проверить, какой шифр работает быстрее всего в вашей системе. Ожидайте двукратное увеличение скорости между самым быстрым и самым медленным. Хотя за последние 20 лет я никогда не видел медленных шифров в качестве стандарта, шифры обычно по умолчанию используют что-то близкое к самому быстрому.

Лучшее решение: :Отключить аппаратное ускорение -Ускорение в Firefox. Это редко требуется, так как Firefox все равно отключает его по сети, но в некоторых случаях он не может этого сделать, и именно здесь Firefox становится очень, очень, очень медленным.

Это все, что можно сказать о Firefox, SSH и X11.Если это не поможет, попробуйте что-нибудь другое:

Запустите X11 без SSH, выполнив что-то подобное на сервере X11 -

startx -- -listen tcp &
sleep 5
export DISPLAY=:0
xhost +yourx11client +yourx11client.local

и на клиенте X11 -:

export DISPLAY=yourx11server:0

Подсказка: сервер и клиент X11 "перепутаны". Сервер — это дисплей, клиент — приложение.

Это легко ускорит работу Firefox в десять раз. Хотя некоторые страницы по-прежнему будут очень вялыми и невосприимчивыми, например. ролики.

Еще более решительный шаг. :Отключите X11 в качестве сетевого протокола, используйте VNC. Либо с помощью удаленного экрана, либо полностью виртуализированного сеанса VNC :

.
vncserver :1 -name VNC1 -geometry 1024x768 -depth 15

и в $HOME/.vnc/xstartup что-то вроде:

#!/bin/sh
# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x30

Я настоятельно рекомендую использовать команду xsetroot, так как фон X11 по умолчанию выглядит ужасно и его трудно сжать.

Подключитесь к любому клиенту VNC -, который вам нравится.

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

Это, безусловно, самая отзывчивая удаленная система.

2
20.08.2021, 12:37

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

Для меня включение сжатия(-C)улучшило время отклика от непригодного до едва заметного отставания.

Выбор шифра тоже может иметь значение, вопреки тому, что говорят некоторые люди. Вы можете найти людей, которые делятся эталонными тестами в Интернете, но не думайте, что ваши результаты будут такими же. Какой шифр лучше для вас, зависит от оборудования. Для меня мой шифр по умолчанию (chacha20 -poly1305@openssh.com )уже был привязан к самому быстрому.

Я написал быстрый скрипт для сравнительного анализа соответствующих шифров в довольно реалистичных условиях. Пояснения в комментариях:

#!/usr/bin/bash

# Ciphers available to you depends on the intersection of ciphers compiled 
# into your client and the ciphers compiled into your host.
# Should be manually copied from "Ciphers:" section in your `man ssh_config`
# The script will try all ciphers specified here and will gracefully skip
# ciphers unavailable in the host.
#ciphers=""
# Example:
ciphers="3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com chacha20-poly1305@openssh.com"

tmp_file=tmp.bin

# Recommend to use an identity file without a passphrase.
# That way you won't have to retype the password at each iteration.
ssh_identity_file=~/.ssh/tmp_id_no_passphrase

ssh_host="user@host"

# Size of test file, before encryption.
test_file_size_megabytes=8

# Only create test file if it doesn't yet exists.
# Doesn't check if relevant variables changed, so you'll have to delete
# the $tmp_file to regenerate it.
if test ! -f $tmp_file; then
  echo "Creating random data file" \
    "(size $test_file_size_megabytes MB): $tmp_file"

  # Not the same format as the ssh ciphers.
  # Can be left as is, unless this cipher is not supported by your openssl.
  tmp_file_cipher=aes-128-cbc

  # The purpose of encrypting the $tmp_file is to make it uncompressable.
  # I do not know if that is a concern in this scenario,
  # but better safe than sorry.

  dd if=/dev/zero bs=1M count=$test_file_size_megabytes \
    | openssl enc -$tmp_file_cipher -pass pass:123 \
    > $tmp_file
fi

for cipher in $ciphers ; do
  # Benchmark each $cipher multiple times
  for i in 1 2 3 ; do
    echo
    echo "Cipher: $cipher (try $i)"
    # Time piping the $tmp_file via SSH to $ssh_host using $cipher.
    # At destination received data is discarded.
    cat $tmp_file \
      | /usr/bin/time -p \
      ssh -i $ssh_identity_file -c "$cipher" $ssh_host 'cat > /dev/null'
  done
done

# Sample output:

# Creating random data file (size 8 MB): tmp.bin
# *** WARNING : deprecated key derivation used.                                   Using -iter or -pbkdf2 would be better.                                         8+0 records in
# 8+0 records out
# 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0567188 s, 148 MB/s

## [redacted]

# Cipher: aes256-cbc (try 3)
# Unable to negotiate with 192.168.99.99 port 22: no matching cipher found. Their offer: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
# real 0.12
# user 0.03
# sys 0.03

# Cipher: aes128-ctr (try 1)
# real 9.68
# user 0.28
# sys 0.51

# Cipher: aes128-ctr (try 2)
# real 10.85
# user 0.26
# sys 0.29

## [redacted]

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

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

0
20.08.2021, 12:37

Теги

Похожие вопросы