Pregunta ¿Por qué sería más rápido saltar SSH con pseudo-tty versus reenvío?


Me he dado cuenta de que en la red de mi oficina, las conexiones SSH multisalto que usan el método "pseudo-tty" funcionan mejor (ver la última nota) que utilizando el método "reenvío". Por qué sería este el caso?

En otras palabras, ¿por qué?

ssh -A -X -tt server1 ssh -X -tt server2  # pseudo-tty

da como resultado un rendimiento mucho mejor que:

ssh -o ‘ProxyCommand=ssh -A -X -W %h:%p server1’ -X server2  # forwarding

?

Otras notas:

  • Estoy en mi computadora portátil, y el servidor1 y el servidor2 tienen el mismo hardware.
  • En mi computadora portátil, tengo Windows 7 con ssh y xwin de Cygwin. Tiene un procesador decente (i7 4610M o similar).
  • Ambos servidor1 y servidor2 son RHEL 6.5.
  • No he medido la velocidad de bits, pero las aplicaciones X11 son significativamente más rápidas con el método pseudo-tty (hay retraso visible con el reenvío).

3


origen


¿Puedes probarlo con la versión nativa de Windows? Sé que Cygwin tiene la magia suficiente para emular varias cosas de Linux y creo que habrá algo de eso para el reenvío de X. - Jakuje
¿Has probado proxy automático también, que debería tener menos gastos generales que las otras dos opciones. No estoy seguro de por qué debería haber mucha diferencia entre los dos métodos mencionados. - eckes


Respuestas:


Creo que su primera línea de comando establecerá una conexión a server1 optimizado para la sesión interactiva (con respuesta lowdelay, pero con menor rendimiento), pero el método forwading abrirá una sesión con el bit ToS configurado en MaximizeTroughtput, con un tiempo de respuesta más alto. Por lo tanto, menos optimizado para sesiones interactivas.

Eso puede provenir del hecho de que ssh y sshd establecerán automáticamente los ToS según rfc1349. El valor predeterminado es lowdelay para sesiones interactivas y rendimiento no interactivo (generalmente sftp, scp, en el caso de reenvío de puertos).

Extraer de man ssh_config:

 IPQoS   Specifies the IPv4 type-of-service or DSCP class for connections.  Accepted values are af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, ef, lowdelay,
         throughput, reliability, or a numeric value.  This option may take one or two arguments, separated by whitespace.  If one argument is specified, it is used as the packet class unconditionally.  If two values are speci‐
         fied, the first is automatically selected for interactive sessions and the second for non-interactive sessions.  The default is lowdelay for interactive sessions and throughput for non-interactive sessions.

ps: puedes intentar:

ssh -o ‘ProxyCommand="ssh -A -X -W %h:%p -o IPQoS=lowdelay server1"’ -X server2


0