Скорость SSH значительно улучшилась с помощью ProxyCommand - но почему?

Вы можете использовать GNU find , чтобы вывести список файлов с измененным временем, выраженным как время эпохи, а затем использовать sort , чтобы отсортировать список, наконец, head и tail , чтобы получить желаемое пронумерованное имя файла:

find . -maxdepth 1 -type f -printf '%T@ %p\n' | sort -k1,1nr | head -5 | tail -1
13
08.04.2018, 13:23
1 ответ

Большое спасибо людям, присылавшим идеи в комментариях. Я прошел их все:

Запись пакетов с помощью tcpdump и сравнение содержимого в WireShark

# tcpdump -i wlan0 -w good.ssh & \
     cat signature | ssh -o "ProxyCommand nc %h %p" \
        root@192.168.1.150 'cat | md5sum' ; \
     killall tcpdump
# tcpdump -i wlan0 -w bad.ssh & \
     cat signature | ssh root@192.168.1.150 'cat | md5sum' ; \
     killall tcpdump

В записанных пакетах не было никаких существенных различий.

Проверка формирования трафика

Понятия не имел об этом -, но после просмотра справочной страницы "tc" я смог убедиться, что

  • tc filter showничего не возвращает
  • tc class showничего не возвращает
  • tc qdisc show

...возвращает эти:

qdisc noqueue 0: dev lo root refcnt 2
qdisc noqueue 0: dev docker0 root refcnt 2
qdisc fq_codel 0: dev wlan0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 

...которые, кажется, не различают "ssh" и "nc" -на самом деле, я даже не уверен, может ли формирование трафика работать на уровне процесса (Я ожидаю, что это работа с полем адресов/портов/дифференцированных услуг в заголовке IP ).

Debian Chroot, чтобы избежать потенциальной «хитрости» в SSH-клиенте Arch Linux

Нет, те же результаты.

Наконец -Нэгл

Выполнение трассировки в отправителе...

pv data | strace -T -ttt -f ssh 192.168.1.150 'cat | md5sum' 2>bad.log

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

1522665534.007805 getsockopt(3, SOL_TCP, TCP_NODELAY, [0], [4]) = 0 <0.000025>
1522665534.007899 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000021>

Это настраивает сокет SSH для отключения алгоритма Нэгла. Вы можете прочитать в Google и прочитать все об этом -, но это означает, что SSH отдает приоритет скорости отклика над пропускной способностью -он дает указание ядру немедленно передавать все, что написано в этом сокете, а не «задерживать» ожидание подтверждений от пульт.

Проще говоря, это означает, что в конфигурации по умолчанию SSH НЕ является хорошим способом передачи данных через -не тогда, когда используется медленный канал (, что характерно для многих сетей WiFi. ссылки ). Если мы отправляем по воздуху пакеты, которые «в основном являются заголовками», полоса пропускания тратится впустую!

Чтобы доказать, что это действительно был преступник,Я использовал LD _PRELOAD, чтобы «отбросить» этот конкретный системный вызов :

.
$ cat force_nagle.c

#include <stdio.h>
#include <dlfcn.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <sys/socket.h>

int (*osetsockopt) (int socket, int level, int option_name,
           const void *option_value, socklen_t option_len) = NULL;

int setsockopt(int socket, int level, int option_name,
           const void *option_value, socklen_t option_len)
{
    int ret;
    if (!osetsockopt) {
        osetsockopt = dlsym(RTLD_NEXT, "setsockopt");
    }

    if (option_name == TCP_NODELAY) {
        puts("No, Mr Nagle stays.");
        return 0;
    }
    ret = osetsockopt(socket, level, option_name, option_value, option_len);
    return ret;
}

$ gcc -fPIC -D_GNU_SOURCE -shared -o force_nagle.so force_nagle.c -ldl

$ pv /dev/shm/data | LD_PRELOAD=./force_nagle.so ssh root@192.168.1.150 'cat >/dev/null'
No, Mr Nagle stays.
No, Mr Nagle stays.
 100MiB 0:00:29 [3.38MiB/s] [3.38MiB/s] [================================>] 100%   

Там -идеальная скорость (ну так же быстро как и iperf3 ).

Мораль рассказа

Никогда не сдавайся:-)

И если вы используете такие инструменты, как rsyncили borgbackup, которые передают свои данные по SSH, и ваш канал медленный, попробуйте остановить SSH, отключив Nagle (, как показано выше )-, или используя ProxyCommand, чтобы переключить SSH для подключения через nc. Это можно автоматизировать в вашем файле $HOME/.ssh/config :

.
$ cat.ssh/config
...
Host orangepi
    Hostname 192.168.1.150
    User root
    Port 22
    # Compression no
    # Cipher None
    ProxyCommand nc %h %p
...

... так что все будущие использования "orangepi" в качестве целевого хоста в ssh/rsync/borgbackup отныне будут использовать ncдля подключения (и поэтому оставят Nagle в покое ).

15
27.01.2020, 19:53

Теги

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