Medir a latência total da sessão SSH

Existe uma maneira de medir / relatar a latência geral em uma sessão SSH encapsulada?

Minha configuração particular é:

• Cliente (OS X + roteador wifi + modem ADSL)
• Servidor SSH do gateway exposto à Internet
• Alvo SSH interno para o qual estou encapsulando

Estou interessado em ver a latência entre o console na minha máquina local e a máquina final na qual tenho a sessão aberta.

Estava tentando fazer isso sozinho e veio com isso. Provavelmente, existe uma maneira mais simples, mas é isso que eu criei.

Primeiro, prepare os tubos que serão usados ​​para fazer o programa de benchmarking se comunicar através da conexão SSH.

$ mkfifo /tmp/up /tmp/down

Em seguida, estabeleça uma conexão no modo ControlMaster sem executar nenhum comando remoto. Isso nos permite autenticar interativamente o host. Depois que a conexão for estabelecida, o SSH simplesmente "travará" aqui em primeiro plano.

$ ssh $HOST -N -M -S /tmp/control

Em um terminal paralelo, execute o controle remoto catem segundo plano. Será o nosso servidor de eco cuja latência mediremos. As entradas e saídas estão conectadas aos FIFOs:

$ ssh $HOST -S /tmp/control cat </tmp/up >/tmp/down &

E, em seguida, avalie um programa pequeno (envie um byte para o upFIFO, receba um byte do downFIFO):

$ python -m timeit -s 'import os' \
    'os.write(3, "z"); z=os.read(4, 1); assert z=="z", "got %s" % z' \
    3>/tmp/up 4</tmp/down
10 loops, best of 3: 24.6 msec per loop

A medida obviamente mostra a latência de ida e volta. Se você precisar repetir o experimento, execute os dois últimos comandos ( sshe python) novamente.

Se algo parece dar errado, use o -vsinalizador SSH para obter mais resultados de depuração.

Eu pulei alguns passos sugeridos por @ nicht-verstehen:

python -m timeit --setup 'import subprocess; p = subprocess.Popen(["ssh", "user@host", "cat"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, bufsize=0)' 'p.stdin.write(b"z"); assert p.stdout.read(1) == b"z"'

Onde

python -m timeitexecuta o timeitmódulo Python.

A -s/--setupopção informa timeitquais instruções executar antes de cada repetição.

subprocess.Popen(["ssh", "user@host", "cat"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, bufsize=0)lança ssh- executando catem seu host - como filho / subprocesso, redirecionando seus fluxos de E / S para objetos semelhantes a arquivos Python. bufsize=0garante que nenhum IO seja armazenado em buffer, o que pode causar esperas de IO.

E para cada loop:
p.stdin.write(b"z")escreve um único byte para o filho (por sua vez, através de ssh para cat).
p.stdout.read(1)lê um único byte da criança. A afirmação em torno dele testa se esse byte é igual ao que você escreveu para ele.

Tudo se resume à mesma coisa, mas pula a criação dos pipes nomeados ( mkfifo). Percebi que quanto mais loops você executa, mais rápido é o loop. Controle usando -n/--number:python -m timeit --number 50 ...

Veja o sshpingutilitário: https://github.com/spook/sshping

Exemplo:

# sshping 172.16.47.143
--- Login: 1725 msec
--- Minimum Latency: 4046 nsec
---  Median Latency: 11026 nsec  +/- 0 std dev
--- Average Latency: 178105 nsec
--- Maximum Latency: 8584886 nsec
---      Echo count: 1000 Bytes
---  Transfer Speed: 11694919 Bytes/second

# sshping --help
Usage: sshping [options] [user@]addr[:port]

  SSH-based ping that measures interactive character echo latency
  and file transfer throughput.  Pronounced "shipping".

Options:
  -c  --count NCHARS   Number of characters to echo, default 1000
  -e  --echocmd CMD    Use CMD for echo command; default: cat > /dev/null
  -h  --help           Print usage and exit
  -i  --identity FILE  Identity file, ie ssh private keyfile
  -p  --password PWD   Use password PWD (can be seen, use with care)
  -r  --runtime SECS   Run for SECS seconds, instead of count limit
  -t  --tests e|s      Run tests e=echo s=speed; default es=both
  -v  --verbose        Show more output, use twice for more: -vv

Minha idéia era usar seqüências de consulta de terminal para isso; a vantagem é que isso pode ser simplesmente executado no servidor, a desvantagem é que ele mede a latência do terminal, não apenas a latência da conexão (mas acho que, geralmente, o tempo de resposta do seu terminal será insignificante em comparação com os atrasos da rede) - talvez é isso que você quer dizer com latência geral

#!/usr/bin/env python3
# Measure terminal latency (round-trip time) using "Query device code" command
from sys import stdin, stdout
import tty, termios, time

oldtty = termios.tcgetattr(stdin)
try:
    tty.setcbreak(stdout)

    runs = 10
    results = []
    for _ in range(runs):
        stdout.write("\x1b[c")
        stdout.flush()
        t1 = time.time()
        ch = stdin.read(1)
        assert(ch == '\x1b')
        t2 = time.time()
        while stdin.read(1) != 'c': # swallow rest of report
            continue
        latency = (t2 - t1) * 1000
        print('%.1fms' % (latency))
        results.append(latency)

    print()
    print('avg: %.1fms min: %.1fms max: %.1fms' % (
        sum(results) / runs,
        min(results),
        max(results)))
finally:
    termios.tcsetattr(stdin, termios.TCSADRAIN, oldtty)

(Ele usa "Device Code Query", todos os terminais que eu tentei responder a isso: xterm, alacritty, gnome-terminal. Eu não posso tentar isso no MacOS. Então YMMV, se esse não for, outro dos pedidos para interrogar algumas informações sobre o terminal, consulte http://www.termsys.demon.co.uk/vtansi.htm )