ProxyCommandを使用してSSH速度を劇的に向上させます。しかし、その理由は何ですか？

Question

コメントでアイデアを提供してくださった方々に心から感謝します。私はこれらすべてを経験しました：

tcpdump を使用してパケットを記録し、WireShark の内容を比較します。

# tcpdump -i wlan0 -w good.ssh & \
     cat signature | ssh -o "ProxyCommand nc %h %p" \
        [email protected] 'cat | md5sum' ; \
     killall tcpdump
# tcpdump -i wlan0 -w bad.ssh & \
     cat signature | ssh [email protected] '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ヘッダーサービスフィールド。

Arch Linux SSHクライアントの潜在的な「賢さ」を避けるためのDebian Chroot

いいえ、結果は同じです。

最後に - Nagel

送信者からstraceを実行します...

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>

Nagleのアルゴリズムを無効にするように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 [email protected] 'cat >/dev/null'
No, Mr Nagle stays.
No, Mr Nagle stays.
 100MiB 0:00:29 [3.38MiB/s] [3.38MiB/s] [================================>] 100%

そこには完璧な速度があります（iperf3ほど高速です）。

ストーリー詐欺

決してあきらめないでください:-)

rsyncSSH経由でデータを転送するなどのツールを使用していて、borgbackupリンクが遅い場合は、Nagleを無効にしてSSHをブロックするか（上記を参照）、Nagleを使用してProxyCommandSSHを切り替えてみてくださいnc。これは$ HOME /で自動的に実行できます。 SSH/構成から:

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

nc...以降、ssh / rsync / borgbackupでターゲットホストとして "orangepi"を使用するすべての操作が接続に使用されます（したがってNagleを気にしないでください）。

Answer 1